Hi, Just wanted to give the community a heads up that we will need to make a decision about the future usage and support of Serp (byte code weaving utility). Recently, I have been experimenting with the use of Java 7. Application binaries compiled with Java 6 will run just fine in a Java 7 runtime. No problems there. And, if you limit the target version for the javac invocation to 1.6 (or 6) when using Java 7, still no problems. But, if you compile your JPA Entity classes with Java 7 (and use the default target level of 1.7 or 7), then the byte code enhancement step will fail. Actually, the enhancement process itself works most of the time (depending on the specific version of the Java 7 compiler). But, when those enhanced classes attempt to get loaded into the runtime, these classes will fail to be verified.
In Java 7, there is some new mandatory class verification that gets invoked on all classes that are loaded into the jvm. From what I have been able to determine, our enhanced Entity classes do not contain mandatory StackMapTables for methods that we introduce during our enhancement process. To help prove this, I have performed some post-enhancement processing with ASM (another byte code weaving utility) to create these missing StackMapTables and then these enhanced Entity classes are loaded just fine by the JVM. I have found no way to turn off this class verification step. Both the Oracle/Sun JDK and IBM JDK have similar results. The issue is that there is no formal support for Serp ( http://serp.sourceforge.net/). We do have access to the source code, so figuring and resolving the issue is doable. The question is whether we should limp along with Serp or bite the bullet and move to a supported byte code weaving library, such as ASM. To properly update Serp, we would need some expertise with the various class file formats and their requirements. I noticed in the code that this hasn't been updated since the Java 5 class file format. Like I said, figuring this StackMapTable requirement out and modifying the Serp code is doable. It's just a matter of time and experience. The most I have learned about the Java class file format has been in the last week... :-) And, since this StackMapTable may not be the last required update for Java 7, do we want to continue to use this library? The other alternative is to use a support byte code weaving utility such as ASM. Way back when we first kick-started this OpenJPA project, I brought this up as an alternative. But, since we had people that currently supported Serp and we have more pressing issues, we decided to stick with Serp. But, now that we're lacking those skilled resources, I'm wondering if the time is right to move away from Serp and use ASM. From an end-user viewpoint, there should no difference. We would just be using a different utility for doing the byte code weaving. The end result would be the same enhanced classes. And, we would have formal support. As an example, ASM had discovered this anomaly with Java 7 class files over a year ago and already resolved it in their released binaries. So, if we had already been using ASM, we would have just had to update our pom file and we'd be good to go. Anyway, something to think about. We don't have to make an immediate decision. Maybe there are some hidden Serp developers lurking on our mailing list and they might feel the urge to resolve this issue... :-) Later, Kevin
