On March 12, 2014, Apache Lucene announced that Lucene 4.8 and Solr 4.8 will require Java 7, citing better file handling (from which Lucene will greatly benefit) and better comparators. This is, in itself, interesting and worthwhile news, but the impact and implication for downstream projects is far more relevant than Lucene itself.
Hibernate Search 5, for example, uses Lucene, but is based on Java 6. With Lucene requiring Java 7, Hibernate Search is faced with a choice: stay with the older (end-of-lifed) API (and the older version of Lucene as well), or update to Java 7.
Moving to Java 7 has many benefits; the update from the older language specifications will clean up quite a bit of modern code.
But there are two thought processes here.
One thought is that updating might affect downstream projects for Hibernate Search (since they will be forced to update to Java 7 themselves, if Hibernate Search does). This may or may not be a desirable effect for a core library, so such a step needs to be taken carefully, no matter what the final decision might be.
The other thought is based around the recent release of Java 8, which represents a significant update even from Java 7, with lambdas and the streaming APIs being massive changes for processing data. Should upstream libraries consider leveraging their considerable functionality to encourage downstream applications to migrate to Java 8, which will benefit everyone as soon as the burdens of migration are met?
It’s possible; after all, Scala (which offers some similar paradigms) has been able to gain traction through a number of projects, with Play and GridGain being two examples that occur easily to this writer.
If there’s a measurable benefit to moving to Java 8 - and there will be, beyond the APIs, as the heap management has changed as well - then why not consider moving to a language that represents what Java could have, and maybe should have, been for the last five years?
(Note: All opinions expressed are personal opinions and do not necessarily reflect the official positions of Red Hat.)