openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Struberg (JIRA)" <>
Subject [jira] [Commented] (OPENJPA-2386) Support for JAVA 8
Date Thu, 30 May 2013 06:12:21 GMT


Mark Struberg commented on OPENJPA-2386:


I've just created a new shade of ASM4 in xbean-asm4-shaded which we will release shortly.
we can use this to prevent classpath clashes. The shade creates a package org.apache.xbean.asm4.*
which we will only use for ASM4 binary compatible releases.

Con: on an ASM upgrade we need to update our sources to the new import
Pro: we effectively prevent classpath clashes with other projects who need different versions
of ASM
> Support for JAVA 8
> ------------------
>                 Key: OPENJPA-2386
>                 URL:
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: build / infrastructure, Enhance, jpa
>    Affects Versions: 2.3.0
>            Reporter: Kevin Sutter
> A few different aspects exist for the support of Java 8.  The first being tolerance of
the Java 8 runtime.  If OpenJPA and the application are built and enhanced with Java 7 (or
Java 6), then will these class files execute in a Java 8 environment?  My assumption is "yes"
since this would be consistent with our initial experiences with Java 7.  But, some testing
will be required to verify this.
> The next aspect is the building of the application Entities with Java 8.  Building and
enhancing Java Entity class files with Java 8 looks to be hazardous...  The first indication
is that ASM doesn't seem to handle the Java 8 class file format.  And, if ASM doesn't handle
it, then I'm sure that Serp doesn't handle it either.  Now, whether our use of ASM as a post-processor
for Serp will suffice this time around, I have no idea.  
> This brings back the question of dropping Serp support altogether and going the ASM route
(  I know there's
been some interest in this in the past.
> A longer-term aspect is when do we actually build OpenJPA with Java 8 and take advantage
(exploit) of the new features.  I think we have a long ways before we have to cross that hurdle.
 When we start developing JPA 2.1, we'll probably have to upgrade our build process to use
Java 7.  So, we're probably on the same type of cycle for Java 8 for building OpenJPA (when
it's required by Java EE 8).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message