People often ask me if we should upgrade to the latest Java version and I always answer the same thing. Of course we should, what could be wrong about better performance and the latest security updates? I always amend something about trying it in a test environment first, though. Over the years I have seldom seen any problems with a Java SE update, the platform is remarkably backwards compatible. But then magic entered the stage.
The magic in this case is the build time byte code enhancement performed by OpenJPA. Apparently the byte code verifier was changed a bit in Java SE 7, so the classes are no longer valid. Oracle’s JVM complains. IBM’s Java 7 implementation crashes spectacularly. With Java 6 it just works.
OpenJPA has always been my least favourite JPA implementation and this did nothing to change that. Oh, they have fixed the byte code enhancer in newer versions (but if you are stuck with an old application server that might not help), but a similar problem exists for Java SE 8 and who wants to bet on everything playing out with Java 9 and 10? Not me.
It also says something about IBM’s JDK. It really shouldn’t crash on an invalid class, simply reject it and move on.
Nevertheless, my recommendation is still to use the latest Java version, but again – test it first and if you are using OpenJPA and/or anything but Oracle’s mainstream JVM, test it well!
WebSphere 8.5.5 normally uses LTPA tokens for authentication and session cookies for tracking HTTP sessions. The two are not connected and they interact in a sometimes very frustrating way. The HTTP session expires when the user has been inactive (i.e. no requests have been received by the server) for a given time. The LTPA token on the other hand has a fixed expiration time regardless of user activity. This means that a user can be logged out while active and while still having a session. Furthermore it is tricky to handle this as any attempt to access the session for a logged out user fails with an UnauthorizedSessionRequestException, complaining that an anonymous user has attempted to access a session owned by someone else. What to do?
There is a configuration option described here and here that makes the session manager invalidate the session and return null instead. This works well as that is what web applications normally do when a user has been logged out, so it plays nicely with other security frameworks.
To enable the option pick Servers-Server Types-WebSphere application servers-servier name-Session management, find Additional Properties and select Custom Properties, then set InvalidateOnUnauthorizedSessionRequestException=true. Save the changes and restart the server. The UnauthorizedSessionRequestException is history!
If you haven’t already, check out JBoss Forge. I attended a session at JavaOne where it was used to build a Java EE application with JPA database access, a REST interface and a JSF web interface in less than 50 minutes. Sure, the speaker used prepared scripts for many tasks, but even so it was impressive – like Rails but for Java. And there are no JBoss dependencies in the generated code.