Supporting Multiple Java Versions in OSS Libraries

Question

I am in the process of standing up my first OSS Java lib (GitHub/Maven) that an open source hardware community will be making fair/moderate use of.

I am writing this library with Java 8 and managing its build with Gradle 2.4. Later this year Java 9 will be unleashed and I'd like to actively maintain separate versions of the library (one for each JVM version) for several reasons:

• Supporting Java 9 features and language may lead to performance and API improvements
• But forcing the library to require Java 9 places undue hardship on large applications that aren't ready to upgrade to it
• So by supporting (that is, continuing to make periodic releases for) both in parallel makes everyone happy

I'm torn between making these Gradle subprojects underneath the same repo, or placing them in their own top-level projects. So:

• A single myawesomelib top-level project with java8/ and java9/ subprojects underneath it; or
• Two separate myawesomelib-java8 and myawesomelib-java9 top-level projects; or
• Something else?

My inclination is to go with 2 separate top-level projects for CI purposes (so that commits to one don't trigger builds to the other), but I've never had to deal with this problem before.

So all this to ask: what are some common techniques to managing multiple JVM version support in OSS libraries, and are their any facilities in Gradle that can help implement these techniques?

Answer 1

What benefits brings Java-9 over your current Java-8 version ?

I mean to the person using your library.

Deploying two concurrent version of the same library has a LOT of downsides. Do you need to keep the API compatible between the two ? you will also have to maintain the code twice, fix the bugs twice as inevitably the code will bear some difference. If there are none then just release it in V8 and rest assured it will work just as well under V9.

Generally when creating a library for larger use than your own projects one tend to be very conservative and support the lowest possible version of Java that is possible. Do you need closures ? do you use NIO ? no ? perhaps best stick with v6 even and reach a broader audience.

My personal view on this would be to try and have a single code base, released under the lowest possible version of JDK that still works and leave it at that. Using a library built under Java 6 under Java 8 works fine, when Java 9 comes along, it will still work without issues.

If your library is not to be used outside your project then you can use whatever version of JDK the project uses, again, don't maintain two separate version it's twice the work with very little benefits.

Now if you do have to support multiple version I would recommend branching the two versions and maintain them this way, it's a natural fit for the common VCS tools to support (git, svn etc). No funky project layout to maintain that supports multiple compilation environments or work around in your build scripts to see what to compile when. Still, for me to consider that the benefits would have to be rather substantial.