+1 My personal opinion is that we should switch to Java8 for our next-gen platform. On top of the cool point on default methods you mention, it should also make it easier to start polishing our APIs to have end users take advantage of Java8 features. Not least, next version of Apache Lucene will require Java8, and some components of OGM require Java8 (like ORM's 2nd level cache where Infinispan is involved). I'm pretty sure that there will be Hibernate users stuck on Java7, 6, 5 .. for a while yet but I suspect that this is the same population still using Hibernate 2, 3, 4, .. maybe 5 now, but I doubt they will be willing to take ORM.next (6?) and yet be in the old-JVM category. -- Sanne On 29 March 2016 at 21:04, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > One question we have discussed but never really answered with regard to ORM > as we work on SQM has to do with the version of Java we would baseline on. > Currently ORM 5.0 and 5.1 continue the tradition of still running in Java 6 > runtimes. Java 8 has since come along and offered some JDK "goodies" and a > new update of JDBC. So the question was whether we stick with Java 6 > support or look to leverage and take advantage of these new Java 8 features? > > Another argument for switching to Java 8 on top of those we have already > discussed is that Java 8's "default methods" feature would allow us to > continue to develop major changes but in a possibly less disruptive way. > In a lot of cases anyway. Say I am adding a new method on a public API > interface (org.hibernate.type.Type, e.g.). That breaks all implementors of > that interface, until they provide an implementation of that new interface > method. We've seen this in the past with bootstrapping in ORM and OGM, > where ORM being able to define default implementations of the methods on > the interface.. tat just makes it easier for seamless updating of Hibernate > versions. We handled that in the ORM/OGM bootstrapping case by means of > introducing an implementation of that interface that OGM would then extend, > as opposed to just implementing the interface. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

+1 in my opinion at some point we will have to move to java8 and Hibernate 6.0 for me is a good candidate. On 30 March 2016 at 12:40, Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; wrote: > +1 > > Same opinion. Hibernate 6.0 should use Java 8 too. Most projects already > use Java 1.8, and most important the new ones that are started are using > Java 1.8 anyway. > Other frameworks are doing the move too, Spring 5.0 will use Java 1.8. > > Vlad > > On Wed, Mar 30, 2016 at 1:25 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; > wrote: > > > +1 > > My personal opinion is that we should switch to Java8 for our next-gen > > platform. > > > > On top of the cool point on default methods you mention, it should > > also make it easier to start polishing our APIs to have end users take > > advantage of Java8 features. > > > > Not least, next version of Apache Lucene will require Java8, and some > > components of OGM require Java8 (like ORM's 2nd level cache where > > Infinispan is involved). > > > > I'm pretty sure that there will be Hibernate users stuck on Java7, 6, > > 5 .. for a while yet but I suspect that this is the same population > > still using Hibernate 2, 3, 4, .. maybe 5 now, but I doubt they will > > be willing to take ORM.next (6?) and yet be in the old-JVM category. > > > > -- Sanne > > > > > > > > On 29 March 2016 at 21:04, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > > One question we have discussed but never really answered with regard to > > ORM > > > as we work on SQM has to do with the version of Java we would baseline > > on. > > > Currently ORM 5.0 and 5.1 continue the tradition of still running in > > Java 6 > > > runtimes. Java 8 has since come along and offered some JDK "goodies" > > and a > > > new update of JDBC. So the question was whether we stick with Java 6 > > > support or look to leverage and take advantage of these new Java 8 > > features? > > > > > > Another argument for switching to Java 8 on top of those we have > already > > > discussed is that Java 8's "default methods" feature would allow us to > > > continue to develop major changes but in a possibly less disruptive > way. > > > In a lot of cases anyway. Say I am adding a new method on a public API > > > interface (org.hibernate.type.Type, e.g.). That breaks all > implementors > > of > > > that interface, until they provide an implementation of that new > > interface > > > method. We've seen this in the past with bootstrapping in ORM and OGM, > > > where ORM being able to define default implementations of the methods > on > > > the interface.. tat just makes it easier for seamless updating of > > Hibernate > > > versions. We handled that in the ORM/OGM bootstrapping case by means > of > > > introducing an implementation of that interface that OGM would then > > extend, > > > as opposed to just implementing the interface. > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev