+1 Echo the same as others have said. On Mar 30, 2016 5:52 AM, "andrea boriero" <drebor...@gmail.com> wrote:
> +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.v...@gmail.com> 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 <sa...@hibernate.org> > > 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 <st...@hibernate.org> 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@lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev@lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
