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

[andrea boriero]

+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
>