Is it time to move to Java 8?

Home

News: Is it time to move to Java 8?

  1. Is it time to move to Java 8? (6 messages)

    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.)

    Threaded Messages (6)

  2. Not for a while[ Go to top ]

    I think it will be a while before the majority of businesses are ready to move to Java 8 - a few dot releases to become confident in Java 8, persuading the CTOs/IT managers, and lot of testing will have to happen first. I think any project that relies on Java 8 in 2014, and probably 2015, will see lower adoption than it might otherwise.

  3. Not for a while[ Go to top ]

    I think Java 8 will have more rapid adoption. The security work, the perm gen removal, and the improvements in GC alone will make it an easy operational sell. Developers actually have cause to want to move to Java 8. Tools already support it. This may be the fastest uptake we've seen since the 1.2 and 1.3 timeframe ....

    For what it's worth, the WebLogic dev team and most of the other core middleware groups have already been developing for and testing on Java 8 for several of the above reasons.

    Peace,

    Cameron Purdy | Oracle

  4. Agree[ Go to top ]

    I agree. I know I am. I am already thinking of how to get to 8 (i.e. i might need to move from AIX to Linux).

    I have only one product that i have moved to Java 7 and that was because the customer wanted to update his PCs to Java 7.  Much like v6, there are things in 8 that can really make a difference in development and support.

     

     

     

     

  5. Beyond web development[ Go to top ]

    For products like IntelliJ, which currently supports 1.6 and up, requiring each individual client to already have or move up to 7 or 8 is a risky decision.
  6. Beyond web development[ Go to top ]

    Fair enough, although it's worth pointing out that EVERY decision has risk associated with it. Even staying with 1.6: it's end-of-lifed, making longterm support more risky than it otherwise might have been.

  7. 1.6/1.7[ Go to top ]

    Fair enough, although it's worth pointing out that EVERY decision has risk associated with it. Even staying with 1.6: it's end-of-lifed, making longterm support more risky than it otherwise might have been.

    Right. Even staying at 1.7 has an associated risk: the longer you wait, the more difficult it will be to move on. Could be your next maintenance problem when 1.9 and 1.10 are around.

    In my case, risks have been quickly estimated. A proof-of-concept migration let me put facts on it. Mainly involved updating servers, for javassist/asm to be able to work on java 8 classes. As expected, no problem from running the code on a newer jvm. This was a quick win.