In the past two weeks or so I have been fighting with different IDEs such as Netbeans, Eclipse, and IntelliJ. Though Eclipse is highly customizable, it can give you a very hard time. In particular when you have a J2EE package and validation is turned on. Then you get hundreds of errors and warnings. Lucky me, I was able to change the settings for my webapp project and to ignore many of the issues.

However, I came across a serialVersionUID warning which has been annoying several times before. In principle, you have to set a public, static, and final field of type Long for each class that implements the Serializable interface. I never knew how to come up with a suitable value, but a strength of Eclipse is to provide QuickFixes for many issues. In my case, I just pressed the almighty Ctrl+1 combination which offered to add a serialVersionUID field including a pre-calculated Long value. Cool.

By the way, a good online resource is here.

On March 18 i tuned on my Laptop in the office ran a Maven build command on my project and it suddenly stopped with exceptions that pointed to Spring’s Beanfactory which was unable to load a bunch of beans. This was strange, because the evening before everything passed my JUnit tests. What happened?

I consulted AppFuse’s User group and found a thread which described my problem. Unfortunately, no good solution has been proposed. The author pointed to a Jira Issue in which a work around is described, but well, it’s not a good solution. A few other guys joined in the discussion, but none was able to solve the problem.

Today morning, I digged a bit deeper in it. I recalled March 18. One thing you have to know about Maven is, that by default, prior to compiling, it checks for new jar versions every day and downloads them. So I looked into my local m2 repository and found out that Maven downloaded the latest surefire plugin. I went to its web site and found a Jira bug report describing exactly the problem. However, the problem is still unresolved. But now that I know which version of the plugin caused the problem, I told my Maven project description not to use it and to use a previous version instead. Just add the follwing snippet to your build plugins section:

Guess what, it solved my problem. And that makes my day.

It’s time to write a few words about some things I have learned in the past week. The first thing I want to mention is versioning. So far, whenever I updated and persisted objects to the database, I calculated the modified time myself which is not that bad. But persistence layers such as Hibernate actually can do that for you. To prevent two users from writing to the database at the same time, locking techniques are provided. One such technique is called optimistic locking which is implemented by using versioning either with integers or with timestamps. If you select timestamps, the only thing you have to do is to specify which of the entity fields is supposed to be in charge of the version. Add a @Version JPA annotation to the field. Any persistence framework that is compliant to JPA will calculate the modified data for you and persist it to the database.

Find more explanations here and here.For Hibernate users the Java Persistence with Hibernate Book is the best choice.

The drawback of this approach is that once you edit an object, Hibernate creates a new revised object instead of altering the actual one. That’s a pity and does not serve my purpose in a current project. I am confused, because the book Hibernate in Action describes the versioning process differently: alterations are updates and no inserts. I am not able to resolve this issue.