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

[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" 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.