openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hal Hildebrand <hal.hildebr...@me.com>
Subject Re: Java 8/Java 7 end of life
Date Sun, 15 Mar 2015 21:34:25 GMT
Also, too, nothing about the 1.7 restrictions prevent anything from happening wrt criteria
queries and 1.8 I must say. 



> On Mar 15, 2015, at 4:28 PM, Hal Hildebrand <hal.hildebrand@me.com> wrote:
> 
> True. But I am curious. What would be an example of what you need to do. Not just being
flip ;)  genuinely curious. 
> 
>> On Mar 15, 2015, at 3:55 PM, Charlie Mordant <cmordant1@gmail.com> wrote:
>> 
>> It's also kinda nice to mix the JPA criteria API and J8 functions ;)
>> Also, I'm an applicative architect, how can I tell my product users to use
>> J8 everywhere but in the model module... This has a little bit of support
>> cost in a big company.
>> 
>> 2015-03-15 19:26 GMT+01:00 Hal Hildebrand <hal.hildebrand@me.com>:
>> 
>>> Heh. Really. Just modularize your code base. You can compile the orm
>>> portion with 1.7 and do the rest with 1.8. It's not hard at all and really.
>>> It's what you should be doing anyway. Works like a charm.
>>> 
>>> 1.8 is not an issue unless you pollute your domain model. Just treat them
>>> as pojos. Like God intended ;)
>>> 
>>>>> On Mar 15, 2015, at 12:22 PM, Charlie Mordant <cmordant1@gmail.com>
>>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> So the 2.2.x release is more advanced than the 2.3.x? Shouldn't be nice
>>> to
>>>> backport changes to 2.3 and make a new release?
>>>> J1.7 is near EOL and it should be nice to avoid loosing users because
>>>> they're thinking that they can use OpenJPA with J8...
>>>> 
>>>> Regards,
>>>> 
>>>> 2015-03-11 15:28 GMT+01:00 Hal Hildebrand <hal.hildebrand@me.com>:
>>>> 
>>>>> Eh, it’s fine for me.  My stuff is modularized so I can compile all
that
>>>>> with 1.7 and I don’t need 1.8 features in the database model anyway.
 No
>>>>> worries.
>>>>> 
>>>>>> On Mar 11, 2015, at 7:21 AM, Rick Curtis <curtisr7@gmail.com>
wrote:
>>>>>> 
>>>>>> Yes, supported wasn't added to 2.3.x. Try trunk or 2.2.x
>>>>>> 
>>>>>> On Wed, Mar 11, 2015 at 8:44 AM, Hal Hildebrand <hal.hildebrand@me.com
>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> Sorry, this fell out of my inbox.
>>>>>>> 
>>>>>>> I'm using 2.3.0 and JDK 1.8 and maven.  If I change the target
to 1.8
>>>>> from
>>>>>>> 1.7, I get:
>>>>>>> 
>>>>>>> java.lang.IllegalArgumentException
>>>>>>>     at org.apache.xbean.asm4.ClassReader.<init>(Unknown
Source)
>>>>>>>     at org.apache.xbean.asm4.ClassReader.<init>(Unknown
Source)
>>>>>>>     at org.apache.xbean.asm4.ClassReader.<init>(Unknown
Source)
>>>>>>>     at
>>> org.apache.openjpa.enhance.AsmAdaptor.toJava7ByteArray(AsmAdaptor.java:93)
>>>>>>>     at
>>>>>>> org.apache.openjpa.enhance.AsmAdaptor.writeJava7(AsmAdaptor.java:84)
>>>>>>>     at
>>>>> org.apache.openjpa.enhance.AsmAdaptor.write(AsmAdaptor.java:54)
>>>>>>>     at
>>>>>>> org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:633)
>>>>>>>     at
>>>>>>> org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:619)
>>>>>>>     at
>>>>> org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4900)
>>>>>>>     at
>>> org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java:89)
>>>>>>>     at
>>>>>>> org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:184)
>>>>>>>     at
>>>>>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
>>>>>>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>     at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>     at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>     at java.lang.reflect.Method.invoke(Method.java:497)
>>>>>>>     at
>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>>>>>>>     at org.apache.tools.ant.Task.perform(Task.java:348)
>>>>>>>     at org.apache.tools.ant.Target.execute(Target.java:390)
>>>>>>>     at org.apache.tools.ant.Target.performTasks(Target.java:411)
>>>>>>>     at
>>>>>>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
>>>>>>>     at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
>>>>>>>     at
>>>>>>> org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:327)
>>>>>>>     at
>>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
>>>>>>>     at
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>>>>>>>     at
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>>>>>>>     at
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>>>>>>>     at
>>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
>>>>>>>     at
>>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
>>>>>>>     at
>>> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>>>>>>>     at
>>> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
>>>>>>>     at
>>> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
>>>>>>>     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
>>>>>>>     at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
>>>>>>>     at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
>>>>>>>     at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
>>>>>>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>     at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>     at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>     at java.lang.reflect.Method.invoke(Method.java:497)
>>>>>>>     at
>>> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>>>>>>>     at
>>> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>>>>>>>     at
>>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>>>>>>>     at
>>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
>>>>>>> 
>>>>>>>> On Mar 9, 2015, at 11:30 AM, Rick Curtis <curtisr7@gmail.com>
wrote:
>>>>>>>> 
>>>>>>>> Hal -
>>>>>>>> 
>>>>>>>> What are you seeing for problems? We've done some amount
of testing
>>>>>>> Entity
>>>>>>>> enhancement when using java 8 language features.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Rick
>>>>>>>> 
>>>>>>>> On Mon, Mar 9, 2015 at 10:46 AM, Hal Hildebrand <
>>> hal.hildebrand@me.com
>>>>>> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> No.
>>>>>>>>> 
>>>>>>>>>>> On Mar 9, 2015, at 8:44 AM, Boblitz John <
>>> john.boblitz@bertschi.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hello,
>>>>>>>>>> 
>>>>>>>>>> Does the Byte Code Enhancement work when compiled
for 1.8?
>>>>>>>>>> 
>>>>>>>>>> Thanks & Regards,
>>>>>>>>>> 
>>>>>>>>>> John Boblitz
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Hal Hildebrand [mailto:hal.hildebrand@me.com]
>>>>>>>>>>> Sent: Montag, 9. März 2015 16:21
>>>>>>>>>>> To: users@openjpa.apache.org
>>>>>>>>>>> Subject: Re: Java 8/Java 7 end of life
>>>>>>>>>>> 
>>>>>>>>>>> I can certainly confirm that OpenJPA runs on
java 8.  And even
>>>>>>> compiles
>>>>>>>>>>> when using source 1.7, target 1.7.  Byte code
enhancement works
>>> fine
>>>>>>> on
>>>>>>>>> the
>>>>>>>>>>> code when compiled in that fashion.
>>>>>>>>>>> 
>>>>>>>>>>>> On Mar 9, 2015, at 6:06 AM, Rick Curtis <curtisr7@gmail.com>
>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> OpenJPA 2.3.x and trunk should be functional
with java8, but I
>>>>> don't
>>>>>>>>>>>> think you can build OpenJPA with java8.
>>>>>>>>>>>> 
>>>>>>>>>>>> On Mon, Mar 9, 2015 at 3:52 AM, Henno Vermeulen
>>>>>>>>>>>> <henno@huizemolenaar.nl>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> AFAIK, OpenJPA still doesn't work with
Java 8. Are there any
>>> plans
>>>>>>> of
>>>>>>>>>>>>> fixing this soon? Perhaps OpenJPA committers
could give this
>>> some
>>>>>>>>>>>>> more priority?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Oracle public support for Java 7 will
end after April this year,
>>>>> see
>>>>>>>>>>>>> http://www.oracle.com/technetwork/java/javase/eol-135779.html
>>>>>>>>>>>>> If I understand well, this means that
security issues in
>>> Oracle's
>>>>>>>>>>>>> Java 7 runtime will no longer be fixed
so that an application
>>>>> using
>>>>>>>>>>>>> OpenJPA on Java 7 will become more and
more vulnerable over
>>> time.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The ticket for Java 8 was last updated
in October 2014:
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/OPENJPA-2386
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Henno Vermeulen
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> *Rick Curtis*
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> *Rick Curtis*
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> *Rick Curtis*
>>>> 
>>>> 
>>>> --
>>>> Charlie Mordant
>>>> 
>>>> Full OSGI/EE stack made with Karaf:
>>>> https://github.com/OsgiliathEnterprise/net.osgiliath.parent
>> 
>> 
>> 
>> -- 
>> Charlie Mordant
>> 
>> Full OSGI/EE stack made with Karaf:
>> https://github.com/OsgiliathEnterprise/net.osgiliath.parent

Mime
View raw message