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 Tue, 17 Mar 2015 19:19:44 GMT
Agreed. I'm just of the opinion that orm models are pure pojo. Not an iron rule, I'll concede.


My point is merely that it is a perfectly valid model of pure state with functions orthogonal.


But... Different tastes, colors ;)


> On Mar 16, 2015, at 4:15 PM, Charlie Mordant <cmordant1@gmail.com> wrote:
> 
> Hi Hal,
> 
> Has I said, I made an applicative framework (comparable to Wildfly,
> Glassfish, Fuse), I'm not responsible of what my framework user's will do,
> and I also can't tell them that it offers lambda/J8 BUT for the JPA service
> (flooded in a hundred pages of documentation...).
> 
> Regards,
> 
> 2015-03-16 14:27 GMT+01:00 Hal Hildebrand <hal.hildebrand@me.com>:
> 
>> I think my question was more of why you have to do it in that way, rather
>> than putting whatever logic that needs lambdas somewhere else.  Seems like
>> an easy thing to workaround.
>> 
>> 
>> 
>>>> On Mar 15, 2015, at 4:50 PM, Charlie Mordant <cmordant1@gmail.com>
>>> wrote:
>>> 
>>> class Person{
>>> @OneToMany
>>> private Address address;
>>> public getLocalisation() {
>>> //Do stuff with lambdas to retrieve derived feature
>>> }
>>> }
>>> class Address{
>>> @OneToMany
>>> private Localisation localisation;}
>>> class Localisation{...}
>>> 
>>> 
>>> 2015-03-15 22:34 GMT+01:00 Hal Hildebrand <hal.hildebrand@me.com>:
>>> 
>>>> 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
>>> 
>>> 
>>> 
>>> --
>>> 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