openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <kwsut...@gmail.com>
Subject [DISCUSS] Java7 and Serp
Date Tue, 01 Nov 2011 13:33:39 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message