增强Java 8库，同时保持向后兼容性

Question

I'm developing an open source library in Java and would like to ensure that it is convenient for Java 8 users, and takes advantage of new concepts in Java 8 wherever possible (lambdas etc.)

At the same time I absolutely need to maintain backwards compatibility (the library must still be usable for people using Java 6 or 7).

What useful features from Java 8 can I adopt that would be beneficial for library users without breaking library compatibility for users of older Java versions?

Answer 1

I don't know about your library, this advice might be slightly off .

Lambdas : Don't worry. Any functional interface can be implemented using a Lambda expression.

Method references : Same as lambdas, they should just be usable.

Streams : If this fits your library, you should use them, but keeping compatibility is harder here. The backwards compatibility could be achieved using a second library part, wrapping around the base library and hooking into the public API of it. It could therefore provide additional sugar/functionality without abandoning Java 6/7.

Default methods : By all means, use these! They are a quick/cheap/good way to enhance existing implementations without breaking them. All default methods you add will be automatically available for implementing classes. These will, however, also need the second library part, so you should provide the base interfaces in your base library, and extend the interfaces from the companion-library.

Don't fork the library, abandoning the old one, as there are still many developers who cannot use Java 8, or even Java 7. If your library is sensible to use on eg Android, please keep that compatibility.

Answer 2

If you want your code to be usable by Java 6 consuming VMs, you have to write using Java 6 language compatibility. Alas. The bytecode format critically changed from 6 to 7, so code for 7 and 8 won't load into 6. (I found this with my own code migrating to 7; even when all I was using was multi- catch — which should be writable in the 6 bytecode — I couldn't build it for a 6 target. The compiler refused.)

I've yet to experiment with 8, but you'll have to be careful because if you depend on any new Java packages or classes, you will still be unable to work with older versions; the old consuming VMs simply won't have access to the relevant classes and won't be able to load the code. In particular, lambdas definitely won't work .

Well, can we target a different classfile version? There's no combination of source and target that will actually make javac happy with this.

 kevin$ $JAVA8/bin/javac -source 1.8 -target 1.7 *.java javac: source release 1.8 requires target release 1.8 

So there's simply no way to compile Java source with lambdas into a pre-Java 8 classfile version.

My general take is that if you want to support old versions of Java, you have to use old versions of Java to do so. You can use a Java 8 toolchain, but you need Java 7 or Java 6 source. You can do it by forking the code, maintaining versions for all the versions of Java you want to support, but that's far more work than you could ever justify as a lone developer. Pick the minimum version and go with that (and kiss those juicy new features goodbye for now, alas).

Answer 3

If you use any new language features in Java 8, it requires also using Java 8 bytecode.

$ javac -source 1.8 -target 1.7
javac: source release 1.8 requires target release 1.8

That means your options are quite limited. You cannot use lambdas, method references, default methods, Streams, etc. and maintain backwards compatibility.

There are still two things you can do that users of Java 8 will benefit from. The first is using Functional Interfaces in your public API. If your methods take Runnables, Callables, Comparators, etc. as parameters, then users of Java 8 will be able to pass in lambdas. You may want to create your own Single-Abstract-Method interfaces as well. If you find you need Functions and Predicates, I'd suggest reusing the ones that ship with GS Collections or Guava instead of writing your own.

The second thing you can do is use a rich collections API that benefits from using Functional Interfaces. Again, that means using GS Collections or Guava. For example, if you have a method that would return List, return MutableList or ImmutableList instead. That way, callers of the method will be able to chain usages of the rich API exposed by these interfaces.

Answer 4

As said by others, providing and using interfaces with a single method such that they can be implemented using lambdas or method references when using Java 8 is a good way of supporting Java 8 without breaking Java 7 compatibility.

---

This can be complemented by providing methods by your library which fit into one of the standard function types of Java 8 (eg Supplier , (Bi)Consumer , (Bi)Function ) so that Java 8 developers can create method references to them for Java 8 API methods. This implies that their signature matches one of these functional interfaces and they don't throw checked exceptions. This often comes naturally, eg getFoo() may act as a Function and isBar() as a Predicate but sometimes it's possible to improve methods by thinking about possible Java 8 use scenarios.

For example, if you provide a method taking two parameters, it's useful to choose the order where the first parameter is the one that is more likely to be a key in a Map . So it is more likely to be useful for Map.forEach with a method reference.

And avoid method with ambiguous signatures. Eg if you have a class Foo with an instance method ReturnType bar() and a static method ReturnType bar(Foo) neither of them can be used as method reference anymore as Foo::bar would be ambiguous. Eliminate or rename one of these methods.

It's important that such methods do not have undocumented internal state that causes surprising behavior when used by multiple threads. Otherwise they can not be used by parallel streams.

---

Another opportunity that should not be underestimated is to use names for classes, interfaces and members conforming to patterns introduced by the Java 8 API. Eg if you have to introduce some sort of filter interface with a test method for your library that ought to work with Java 7 as well, you should name the interface Predicate and the method test to associate it with the similar named functional interface of Java 8.