[hibernate-dev] Java 8 default methods as a refactoring tool

[Chris Cranford]

+1

Echo the same as others have said.
On Mar 30, 2016 5:52 AM, "andrea boriero" <dreborier at 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.vlad at 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 <sanne at 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 <steve at 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 at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>