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

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