You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2014/10/26 14:05:26 UTC
Java 1.7 for 4.0 .. again
So quite a bit of time has passed since our last Java 7 discussion. Java 6 is even more distant memory now. Of which I was reminded today after I upgraded my laptop to Yosemite. My Modeler instance wouldn't start without installing "legacy Java SE 6 runtime" (of course I quickly switched to Java 7 modeler and all was good). So I suggest two things, both applying to Cayenne 4.0 (aka 3.2) :
1. Make Java 1.7 a minimal requirement.
2. If #1 meets any opposition, at least stop supporting Java 6 friendly Modeler assembly on the Mac, which existence has no reasonable excuse anymore.
Andrus
Re: Java 1.7 for 4.0 .. again
Posted by John Huss <jo...@gmail.com>.
I'm in favor of moving to 1.7
On Tue, Oct 28, 2014 at 2:28 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
>
> > On Oct 27, 2014, at 10:11 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
> >
> > While I'd love to start using diamond syntax and try-with-resources in
> our own code
>
> Also 1.7 AutoCloseable interface (used in try-with-resources) is something
> I'd like to make a part of our own API. E.g. ResultIterator should be
> AutoCloseable. Also have some ideas for transaction management improvements
> that can take advantage of that.
>
> With 1.6 our next best option is using java.io.Closeable. Too bad it
> declares IOException in the "close" method, and relevant JDBC classes (e.g.
> Connection) do not implement it. So there is an opportunity cost associated
> with 1.6 support (as well as with dropping 1.6 support :))
>
> Andrus
>
>
Re: Java 1.7 for 4.0 .. again
Posted by Andrus Adamchik <an...@objectstyle.org>.
> On Oct 27, 2014, at 10:11 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> While I'd love to start using diamond syntax and try-with-resources in our own code
Also 1.7 AutoCloseable interface (used in try-with-resources) is something I'd like to make a part of our own API. E.g. ResultIterator should be AutoCloseable. Also have some ideas for transaction management improvements that can take advantage of that.
With 1.6 our next best option is using java.io.Closeable. Too bad it declares IOException in the "close" method, and relevant JDBC classes (e.g. Connection) do not implement it. So there is an opportunity cost associated with 1.6 support (as well as with dropping 1.6 support :))
Andrus
Re: Java 1.7 for 4.0 .. again
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 27/10/2014 6:11pm, Andrus Adamchik wrote:
> Heh, so we are the pioneers of Java 7 on Mac with japp-maven-plugin [1] and CayenneModeler :)
We moved our project over to https://bitbucket.org/infinitekind/appbundler/overview since that solves a few issues for us compared to the stagnated oracle bundler. Note there is also this maven wrapper which is similar to the thing you wrote:
https://github.com/federkasten/appbundler-plugin
>> > Many (most?) Swing apps on OSX seem to have stuck with Java 6, perhaps because of the difficulty of explaining to users why they need to run a different bundle.
> While I am not familiar with full stats on this, it is actually quite easy to ship a JRE (7 or 8) with your Swing app and make it independent of the underlying system Java if you don't mind adding an extra 150MB to the download. Not saying *we* should do it, just a general observation.
Yes; it isn't quite as bad as 150Mb since you just need the JRE which is only a third of that. But it still seems clunky.
>> > As for the cayenne library itself... from a personal point of view I've moved everything to Java 7 so it doesn't affect me, but I don't think Cayenne is the type of library that should move too fast. What do we gain by moving? I can't think of anything in Java 7 that would help us. And it will disenfranchise some users.
> While I'd love to start using diamond syntax and try-with-resources in our own code, the reason I am advocating the switch is mainly testing and support costs. We are to start supporting Java 8 as a separate module soon (datetime classes for instance). This means dev environment will switch to Java 8, making it easier to mess things up in non-Java8 modules. Java 7 is somewhat closer to 8, making it somewhat more manageable.
>
> Also this is a bit of a projection based on our history, I'd say 4.0 beta is 1 year away, and 4.0 final is probably 2 years away. So there's hope that no one will remember Java 6 by then.
>
> Maybe while we continue this conversation here, I should cross-post to user and also start a poll on Twitter (?)
Sure, why not. Note that Hibernate (for comparison) only moved to Java 6 as a minimum with version 4.x (released 2012). Hibernate 3.x worked back to Java 4.
On the other hand, those users can always stay on Cayenne 3.x. Some of the new features are probably more compelling for someone starting a new project rather than someone refactoring all the queries in their application to the new syntax.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Java 1.7 for 4.0 .. again
Posted by Andrus Adamchik <an...@objectstyle.org>.
> On Oct 27, 2014, at 2:17 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
> It is worth noting that Intellij is still bound to Java 6. You can try running it in Java 7/8 but there are still quite a few bugs.
Heh, so we are the pioneers of Java 7 on Mac with japp-maven-plugin [1] and CayenneModeler :)
> Many (most?) Swing apps on OSX seem to have stuck with Java 6, perhaps because of the difficulty of explaining to users why they need to run a different bundle.
While I am not familiar with full stats on this, it is actually quite easy to ship a JRE (7 or 8) with your Swing app and make it independent of the underlying system Java if you don't mind adding an extra 150MB to the download. Not saying *we* should do it, just a general observation.
> As for the cayenne library itself... from a personal point of view I've moved everything to Java 7 so it doesn't affect me, but I don't think Cayenne is the type of library that should move too fast. What do we gain by moving? I can't think of anything in Java 7 that would help us. And it will disenfranchise some users.
While I'd love to start using diamond syntax and try-with-resources in our own code, the reason I am advocating the switch is mainly testing and support costs. We are to start supporting Java 8 as a separate module soon (datetime classes for instance). This means dev environment will switch to Java 8, making it easier to mess things up in non-Java8 modules. Java 7 is somewhat closer to 8, making it somewhat more manageable.
Also this is a bit of a projection based on our history, I'd say 4.0 beta is 1 year away, and 4.0 final is probably 2 years away. So there's hope that no one will remember Java 6 by then.
Maybe while we continue this conversation here, I should cross-post to user and also start a poll on Twitter (?)
Andrus
[1] https://github.com/andrus/japp-maven-plugin
Re: Java 1.7 for 4.0 .. again
Posted by Aristedes Maniatis <ar...@maniatis.org>.
Java on OSX is still a complete mess. I have to deal with it every day and I cannot tell you the pain it is.
Personally I have no objections to moving to Java 7 for the modeler since all our users are developers who will have no trouble coping with such an upgrade. What it gets us is having only one OSX app bundle to look after. And we don't really lose anything.
We could also offer a webstart version of modeler... that's actually simpler in some ways.
It is worth noting that Intellij is still bound to Java 6. You can try running it in Java 7/8 but there are still quite a few bugs. Many (most?) Swing apps on OSX seem to have stuck with Java 6, perhaps because of the difficulty of explaining to users why they need to run a different bundle.
As for the cayenne library itself... from a personal point of view I've moved everything to Java 7 so it doesn't affect me, but I don't think Cayenne is the type of library that should move too fast. What do we gain by moving? I can't think of anything in Java 7 that would help us. And it will disenfranchise some users.
Ari
On 27/10/2014 12:05am, Andrus Adamchik wrote:
> So quite a bit of time has passed since our last Java 7 discussion. Java 6 is even more distant memory now. Of which I was reminded today after I upgraded my laptop to Yosemite. My Modeler instance wouldn't start without installing "legacy Java SE 6 runtime" (of course I quickly switched to Java 7 modeler and all was good). So I suggest two things, both applying to Cayenne 4.0 (aka 3.2) :
>
> 1. Make Java 1.7 a minimal requirement.
> 2. If #1 meets any opposition, at least stop supporting Java 6 friendly Modeler assembly on the Mac, which existence has no reasonable excuse anymore.
>
> Andrus
>
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Java 1.7 for 4.0 .. again
Posted by Mike Kienenberger <mk...@gmail.com>.
On Mon, Oct 27, 2014 at 2:24 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>> J2EE 6 is still mainstream, and J2EE 7 is still relatively unsupported (J2EE 7 is also only a 1.5 years old).
>
> Does JEE version correlate with JDK/JRE versions? It never did in the past. And we are talking about JDK version here.
A google search turns up this, which shows a correlation.
http://stackoverflow.com/questions/2013958/correlation-between-java-ee-j2ee-to-j2se-jdk-versions
But in practical terms, Oracle's J2ee implementation ships with Java
1.6. Shops using Oracle j2ee software stacks are unlikely to
independently upgrade java. I don't know where other stacks stand.
Re: Java 1.7 for 4.0 .. again
Posted by Andrus Adamchik <an...@objectstyle.org>.
> J2EE 6 is still mainstream, and J2EE 7 is still relatively unsupported (J2EE 7 is also only a 1.5 years old).
Does JEE version correlate with JDK/JRE versions? It never did in the past. And we are talking about JDK version here.
Andrus
> On Oct 26, 2014, at 9:46 PM, Mike Kienenberger <mk...@gmail.com> wrote:
>
> J2EE 6 is still mainstream, and J2EE 7 is still relatively unsupported (J2EE 7 is also only a 1.5 years old).
>
> http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Certified_application_servers
>
> On Sun, Oct 26, 2014 at 9:05 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> So quite a bit of time has passed since our last Java 7 discussion. Java 6 is even more distant memory now. Of which I was reminded today after I upgraded my laptop to Yosemite. My Modeler instance wouldn't start without installing "legacy Java SE 6 runtime" (of course I quickly switched to Java 7 modeler and all was good). So I suggest two things, both applying to Cayenne 4.0 (aka 3.2) :
>
> 1. Make Java 1.7 a minimal requirement.
> 2. If #1 meets any opposition, at least stop supporting Java 6 friendly Modeler assembly on the Mac, which existence has no reasonable excuse anymore.
>
> Andrus
>
>
>
>
Re: Java 1.7 for 4.0 .. again
Posted by Mike Kienenberger <mk...@gmail.com>.
J2EE 6 is still mainstream, and J2EE 7 is still relatively unsupported
(J2EE 7 is also only a 1.5 years old).
http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Certified_application_servers
On Sun, Oct 26, 2014 at 9:05 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> So quite a bit of time has passed since our last Java 7 discussion. Java 6
> is even more distant memory now. Of which I was reminded today after I
> upgraded my laptop to Yosemite. My Modeler instance wouldn't start without
> installing "legacy Java SE 6 runtime" (of course I quickly switched to Java
> 7 modeler and all was good). So I suggest two things, both applying to
> Cayenne 4.0 (aka 3.2) :
>
> 1. Make Java 1.7 a minimal requirement.
> 2. If #1 meets any opposition, at least stop supporting Java 6 friendly
> Modeler assembly on the Mac, which existence has no reasonable excuse
> anymore.
>
> Andrus
>
>
>