JEP 238: Multi-Version JAR Files

[Rezaei, Mohammad A.]

Why do you expect the new classes in the JDK not to be part of the API? Simple example:

I have a library that's 5 years old. The API needed the equivalent of java.util.Function (from Java 8), which obviously was not there when I wrote my library. Let's say I had defined CustomFunction and now I want the API to use Function. 

This sort of useful abstraction has been part and parcel with new JDK's for a long time (e.g. HashTable -> Map [1.2], String -> CharSequence [1.4], Generics [1.5], Deque [1.6], AutoClosable [1.7], a dozen useful functional interfaces [1.8]).

Currently, my choices are:
1) Abandon multi-jdk compatibility and release a new version of library for the new jdk. Keep the new version source compatible by making CustomFunction extend Function (possibly with a default delegating method).
2) Have two versions of the code base and release separate jars for each, porting new stuff between the two versions for a while.

How does an MV jar give me a third choice?

Thanks
Moh

>-----Original Message-----
>From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf
>Of Paul Sandoz
>Sent: Friday, February 27, 2015 12:16 PM
>Cc: core-libs-dev at openjdk.java.net
>Subject: Re: JEP 238: Multi-Version JAR Files
>
>On Feb 27, 2015, at 4:47 PM, Florian Weimer <fweimer at redhat.com> wrote:
>> I really don't think this tooling support will provide sufficient
>> enticement to developers to maintain separate 7/8/9 source branches of
>> their libraries.  Isn't that the main obstacle, and not the way the bits
>> are delivered?
>>
>
>What if all the source for 7/8/9 bits were under one project?
>
>Hypothetical project layout:
>
>  src/main/java
>  src/main/resources
>  src/test/java
>  src/test/resources
>  src/main-8/java
>  src/main-8/resources
>  src/test-8/java
>  src/test-8/resources
>  src/main-9/java
>  src/main-9/resources
>  src/test-9/java
>  src/test-9/resources
>
>(If this were a maven-kind of project there would be one pom.xml, one version
>and one set of dependencies, and one (MV) JAR produced when packaging.)
>
>I would anticipate most of the source would reside under src/main/java then
>there would be "overriding" source in the versioned areas for classes that use
>replace usage of say internal JDK features with public JDK features.
>
>For example, say there is a source file:
>
>  src/main/java/foo/Foo.java
>
>whose content is:
>
>  import sun.misc.BASE64Decoder;
>
>  public class Foo {
>    // does something with sun.misc.BASE64Decoder
>  }
>
>There might be another source file located in the 8 area that overrides that
>in the unversioned area:
>
>  src/main-8/java/foo/Foo.java
>
>whose content is:
>
>  import java.util.Base64;
>
>  public class Foo {
>    // does something equivalent with java.util.Base64
>  }
>
>The public contract of Foo should remain identical across the major Java
>platform dependent versions, in a more strict sense the public signatures in
>the byte code should be identical (the jar tool has been modified to check
>this).
>
>Paul.