Limited backporting of Java 8 libraries

[bisher3]

What would it take to support some of Java 8's libraries such as Stream, Collector, Collectors?

[luontola]

First would be needed a separately available library that has exactly the same APIs. The only difference would be that they would probably have to be in a different package, because IIRC the JVM has security features to prevent adding user classes in the java.* namespace. It would be relatively simple to rename the references in bytecode to use other classes. The maven-shade-plugin might even be able to do it already now, or at least with small modifications.

(I can't think of a way to fully backport all the stuff that was added as default methods to Iterable, Collection etc. because default methods are polymorphic.)

[luontola]

Or then just use a third-party library that does the same thing. Googling for java functional library finds multiple alternatives.

[naixx]

Guava works with retrolambda really well and has similar api

[mperry]

FunctionalJava is awesome for functional programming in Java (I contribute to the project). The 4.0 release supports Java 8 and 4.1 supports both Java 7 and 8. We use retrolambda to backport lambdas to do this. To be backwards compatible we moved all the concrete or default methods of the interface to static methods in another class.

Of course, this is still painful compared to more expressive languages.

[bisher3]

Thanks everyone, great insight. So how feasible would it be to "bridge" parts of Java 8 libs with third party libs while using retrolambda? I know it would probably be better to just use something like FunctionalJava, but for developers that have just started learning functional style using Java 8 and would like to apply it to their immediate projects ( such as Android development ) focusing on one set of libs would be desirable.

[luontola]

I don't want to include it in Retrolambda - it would increase the scope of this project too much, and anyways it can be implemented as a separate project.

Also I don't see a good use case for compiling the code against java.util.* classes and then running it against a different set of third party classes. Why not just directly compile it against those third party classes? The only difference from development point of view is that the imports are different (or else the automatic conversion would anyways not be possible).

Learning a new library takes only an hour or two. That amount of time is easily wasted in debugging bugs due to minor differences between the original classes and their replacements, because it would be very hard to make the library backport 100% compatible.

[bisher3]

Well yes when you put it that way I have to agree.

[jodastephen]

Just noting for anyone doing a backport that java.time (JSR-310) is available as ThreeTen-Backport on Java SE 6 and 7.