A Java geek

My article from last week left me mildly depressed: my efforts trying to ease my Vaadin development was brutally stopped when I couldn’t inherit from a Java inner class in Scala. I wondered if it was an impossibility or mere lack of knowledge on my part. Fortunately, Robert Lally and Dale gave me the solution in their comments (many thanks to them). The operator used to access an inner class from Java in Scala is #. Simple, yet harder to google…​ This has an important conseque

People who are familiar with my articles know that I’m interested in Vaadin and also more recently in Scala since both can increase your productivity. Thus it is only natural that I tried to embed the best of both worlds, so to speak, as an experience. As an added challenge, I also tried to add Maven to the mix. It wasn’t as successful as I had wished, but the conclusions are interesting.

A year ago, a colleague of mine showed me a very interesting framework named Krank (latter renamed to Crank because the previous name means 'sick' in German, which does not bode well for any framework). Crank’s goal was to ease development on top of Java Persistence API 1.0. Two interesting features caught my attention at the time.

I’ve barely begun Scala and I learned plenty of facts on Java (see previous article on a javac compiler quirk). Now, I’ve come upon another interesting point, this time completely unrelated to the compiler. It’s strange because now that I’ve realized it exists, it makes me nervous on how I could have ignored it before. The core of the problem lies in mutable objects. IMHO, entities should be mutable because one can load one from the datastore, change it, then save change

Let me first say I was not at Devoxx 2010. Yet, I heard from Matt Raible’s Comparing JVM Web Frameworks. Like many, as I read the final results, I was very surprised that my favorite framework was not ranked first. I passed through all stages of grief, then finally came to realize the presentation itself was much more interesting than the matrix. The problem lies not in the matrix, but in the method used to create it.

How many times in the last couple of years have you seen an initialization servlet (a servlet which is used only once with the load-on-startup parameter) although a context listener could have been used in its place? How many times have you seen a JSP full of indecipherable scriplets though equivalent taglibs were available? How many times have you disagreed with someone who wanted to talk you into using DTO regardless of your application’s needs? I could go forever like that but the poin

CDI is part of JavaEE 6 and that’s a great move forward. Now, there’s a standard telling vendors and developers how to do DI. It can be refined, but it’s here nonetheless. Norms and standards are IMHO a good thing in any industry. Yet, I don’t subscribe to some people’s points of view that this means the end of Spring. There are multiple DI frameworks around here and Spring is number one. Why is that? Because it was the first? It wasn’t (look at Avalon). My o

The boys at Sun made really an amazing thing when designing Java. I mean, everyone is cursing it now, predicting Java is dead because of its verbosity and such but could those persons have done better?  I doubt it. Just consider Java 's penetration in the enterprise…​ Verbosity enforces readibility, a nice feature in the enterprise where people move from position to position, in and out. However, I have stumbled upon a troubling quirk. Most Java’s nuts and bolts are enforced a

With such a controversial title, I’m bound to be the target of heated comments. Although provocative, such is not my goal, however, I just want to initiate an educated debate between people that are interested into thinking about the problem. The origin of this post was a simple discussion between developers of different level of experience on Hibernate. The talk was about eager-, lazy-loading and the infamous LazyInitializationException. Since I imagine not everyone has the problem in hi