Best practice for developing under multiple JDKs

Question

I have a library which I am currently developing with target compatibility to JDK 6. I like to take advantage of Java 8 feature, like lambdas. The code and APIs will greatly profit from Java 8.

I would like to offer versions of the library for Java 6 and Java 8, e.g., where a certain part is only available in the Java 8 version.

Now there are a few core classes which might have their different source version (the legacy Java 6 version and the new Java 8 version).

What is the best practice of doing this? In Objective-C or C++ I would consider using a preprocessor directive.

You can push your JDK specific code into a library and include the correct one at compile time. You should then use a continuous integration environment (like Jenkins) to compile the different versions against different JDKs. (And run all your tests, obviously). — Boris the Spider, Jun 22 '13 at 15:46

sigpwned · Answer 1 · 2013-06-22T16:59:39.563

I see a couple of options:

Package different versions of your library, one for JDK6 and one for JDK8. Users are responsible for including the right one for their application. This will be an interesting build to do. If you're using Maven, I think you'll just use 3 projects; a "commons" project with all common classes, a "JDK6" project that has the commons project as a dependency and builds the JDK6 jar, and then a "JDK8" project that has the commons project as a dependency and builds the JDK8 jar. One attractive bit of this approach is that it obviously works, and you have no hard maintenance to do.

Package both the JDK6 and the JDK8 version in the same JAR, and create a "Runtime"-type class that's responsible for creating the proper versions of your library's objects at runtime depending on the JDK it's running in. For example:

public abstract class Runtime {
    private static Runtime instance;

    public static Runtime getInstance() {
        if(instance == null) {
            try {
                if(System.getProperty("java.version").startsWith("8"))
                    instance = Class.forName("com.yourcompany.libname.runtime.Runtime8").newInstance();
                else
                    instance = Class.forName("com.yourcompany.libname.runtime.Runtime6").newInstance();
            }
            catch(Exception e) {
                throw new RuntimeException("Could not create runtime", e);
            }
        }
        return instance;
    }

    public abstract Framework getFramework();
}

Using this approach, you would only need to use reflection to load the initial "Runtime" object, and then you could use native Java for everything else. For example:

 Framework framework=Runtime.getInstance().getFramework();
 ModelObject1 m=framework.newModelObject1();
 // ...

Just be SURE your Runtime6 class doesn't refer to a JDK8 class, even transitively via imports. The main drawback to this approach is tracking that little tidbit over time.

I think what you're doing is interesting, and I'm very curious to hear how you choose to get it done. Please keep us posted!

This is a nice answer, but the emphasis in my question is on "Developing". It is OK to have two different JARs - one for JDK 6, one for JDK 8. I was more interested in the setup of the IDE. Maybe might question was not precise enough — Christian Fries, Oct 28 '13 at 20:55

score 0 · Answer 2 · answered Jun 22 '13 at 15:50

0

I think you can use System properties (http://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html) in order to discover which Java version is beind used, and then you could adapt your application to run accordingly.

answered Jun 22 '13 at 15:50

Crom

83
1
7

1

the issue is that compiled classes will contain a version header. If that version is too high the JDK will bail when loading the class. You would have to do everything with reflection to avoid this - a right pain. – Boris the Spider Jun 22 '13 at 15:52

Best practice for developing under multiple JDKs

2 Answers2

Linked