A Java geek

Let’s face it, there are two kinds of developers: those that favor Spring autowiring because it alleviates them from writing XML (even though you can do autowiring with XML) and those that see autowiring as something risky. I must admit I’m of the second brand. In fact, I’d rather face a rabbied 800-pounds gorilla than use autowiring. Sure, it does all the job for you, doesn’t it? Maybe, but it’s a helluva job and I’d rather dirty my hands than let some cheap

Java XML Binding (aka JAXB) is part of many applications since it provides a convenient API to marshall/unmarshall Java to/from XML. Like so many area, the devil is in the detail, like when one has to unmarshall a JAXB-incompatible class. Such classes come across one’s code for a variety of reasons: design, legacy, third-party…​ Suffice to say that such a sand grain can be a blocker for any project.

As Dependency Injection frameworks go, the standard is currently CDI. When switching from Spring, one has to consider the following problem: how do you unit test your injected classes? In Spring, DI is achieved through either constructor injection or setter injection. Both allow for simple unit testing by providing the dependencies and calling either the constructor or the desired setter. Now, how do you unit test the following code, which uses field injection: public class MyMainClass { @

If you’ve got a professional attitude regarding your developer career, chances are you’re looking to improve your knowledge, whether it’s language-related or framework-related (or even process-related but it is more far-fetched). So far, I found the following ways to do so, each step bringing deeper knowledge than the former: The first strategy when you want to learn about something is to read about it. This is the easiest, since there are so many resources available online. Th

There are many subjects one has to know when working with Swing and one of them is window closing. A beginner pass through some steps (and yes, I consider myself a beginner in Swing) and here are those I experienced myself. Hiding is default In the first step, you realize that by clicking the cross in the title bar, the window only disappears. It’s not disposed of, and if it’s your main application’s window, that’s bad because it means you’ve lost any handle on t

During these (much deserved) vacations, I worked on a pet project of mine which uses CDI with the Weld implementation and SLF4J with the Logback implementation. The terms of the problem were very simple:  Iwanted the logs of my application to be displayed in a Swing table, i.e. a Logback appender had to write in a table. The table was managed in CDI but the appender was not: this was no surprise since many older-generation frameworks have a lifecycle management on their own. Prior-to-JEE6 Servl

This week saw another flame war from some of the Scala crowd. This time, it was toward Stephen Colebourne, the man behind Joda time. To be frank, I tend to agree to Stephen’s predicat but for very different reasons. Now, if you’re a Scala user, there are basically 2 options.

Dear readers, thanks for your participation in the 'Learning Vaadin' contest. It’s my pleasure to announce the winners.