JDK8 features backporting ?

[Jan Goyvaerts]

I think JDK8 is a big step in the right direction. Unfortunately I'm afraid many of us don't have the liberty to ask our customers to upgrade their JDK's. The eternal issue ...

Sure there are still lots of JDK6's out there ... EVEN if it's end of live. :-)

I'm asking just in case, but it's probably a negative: Is there a way to use JDK8 features on earlier JDK versions ? Or maybe just some of them ?

Thanks,

Jan

[Jaikiran Pai]

There's this plugin which claims to support Java 8 lambdas in previous versions of Java https://github.com/evant/gradle-retrolambda. I vaguely remember there was one another similar project. I can't seem to find that other one.

[Jaikiran Pai]

Jaikiran Pai wrote:I vaguely remember there was one another similar project. I can't seem to find that other one.

Here's that blog which I remembered as having read before http://blog.orfjackal.net/2013/07/lambda-expressions-backported-to-java-7.html. Turns out it's the same project.

[Rob Spoor]

What functionality do you need? You don't need lambdas; you can replace them quite easily with anonymous inner classes (although I would never do that in Java 8. Lambdas yay!).
What remains mostly is all the extra classes and interfaces.

The interfaces are easy; you can just write similar replacements (I've had Predicate, Function etc in my own code for months before Java 8 were released, only to replace them with the java.util.function versions after the release).

Default and static methods in interface can be mimicked by using utility classes. E.g., instead of Iterable.forEach(Consumer) you'd get Iterables.forEach(Iterator, Consumer).

For java.time there is a backport available at https://github.com/ThreeTen/threetenbp.

That leaves mostly streams etc but those too can be backported with a bit of effort.

[Jan Goyvaerts]

Is this backporting reliable ? I mean, there are no known inconveniences besides a bit of setup hacking ?

[Richard Warburton]

Jan Goyvaerts wrote:I think JDK8 is a big step in the right direction. Unfortunately I'm afraid many of us don't have the liberty to ask our customers to upgrade their JDK's. The eternal issue ...

Sure there are still lots of JDK6's out there ... EVEN if it's end of live. :-)

I'm asking just in case, but it's probably a negative: Is there a way to use JDK8 features on earlier JDK versions ? Or maybe just some of them ?

Thanks,

Jan

Hi Jan,

As a few other people in this thread have pointed out you can use retro-lambda in order to get Java 8 code to run on older Java versions. I don't know of anyone who is doing this for production code. if you're going to run this code in production I would extensively test it in Java 8. I've actually written about how you can use Jenkins' matrix-build system in order to test the same code in Java 7 & Java 8 (and even Java 6!) on my blog:

http://insightfullogic.com/blog/2013/jul/5/testing-java-8-3-easy-steps/

Leaving aside retro-lambda I would encourage you to update to the latest version of Java anyway. Even aside from lambdas you'll notice improvements in performance, the addition of Java Mission Control and a huge number of API improvements all over the core library. Its a really big update! Then question then becomes how to justify an upgrade to Java 8. Here's a few things to think about:

* Java 8 provides genuine productivity and performance to users of the platform. These will reduce the cost of your development time, providing a cost saving to the business, if your application is internally managed and you can request that your production environment be upgraded to Java 8.
* Even if you can't get to Java 8, security is a really important issue to people I talk to. You really don't want to be using a platform like Java 6 where you need to pay for security updates and things just don't get fixed as fast as Java 7 & Java 8. I wouldn't want to take the risk of these kind of issues cropping up and migrating to Java 7 will make the move to 8 less painful and easier to achieve.
* If you actually ship a JAR to customers then the situation may be difficult. It may need to run in their setup and I have no magic bullet to offer here. You might just have to stick with Java 6.
* You might find that talking to customers they are willing to run with Java 8. I've been working on a library recently which will ship to a client soon and the client has been willing to run with developing Java 8. They have seen the benefits for them of an upgrade and were reasonable - so its definitely possible.
* I also know of companies who have to ship code to clients on an environment they can't control, but also have internally hosted services which these libraries or applications connect to. They ship Java 6 code to their clients, but are able to develop their server-side components in whatever language they want. By ensuring that the communications protocol is clearly defined (eg a restful API) and not tied to any particular product you can decouple different services like this allowing a piece-meal migration and upgrade path. Their Java 6 using clients don't need to know that the hosted server-side application is developed using Java 8, just that the application continues to work and they are getting new features and bug fixes rapidly.

Best of luck with being able to upgrade, I hope that you're able to!

thanks,

Richard

[Rob Spoor]

Jan Goyvaerts wrote:Is this backporting reliable ? I mean, there are no known inconveniences besides a bit of setup hacking ?

No idea. Other than the interfaces (which I used in my own code and didn't want to create new interfaces with the exact same purposes) I haven't backported anything myself.

[Stefan Zobel]

Rob Spoor wrote: ...
That leaves mostly streams etc but those too can be backported with a bit of effort.

With respect to backporting streams "with a bit of effort", the streamsupport project http://sourceforge.net/projects/streamsupport/?source=directory does backport a part of the Java 8 API, namely the java.util.stream API and the functional interfaces from java.util.function.

It also uses Retrolambda internally to achieve this. However, it doesn't yet "natively" support the creation of a Stream from a standard Java collection.

Using both together in a Java 6/7 project might be a possible route.