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

2016-03-30 Thread Chris Cranford
+1 Echo the same as others have said. On Mar 30, 2016 5:52 AM, "andrea boriero" 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 wrote: > > > +1 > > > > Same opinion. Hibernate

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

2016-03-30 Thread 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 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 s

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

2016-03-30 Thread Vlad Mihalcea
+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 wrot

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

2016-03-30 Thread Sanne Grinovero
+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

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

2016-03-29 Thread Steve Ebersole
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" an