JEP 238: Multi-Version JAR Files

[Paul Sandoz]

Hi Moh,

On Feb 27, 2015, at 7:23 PM, "Rezaei, Mohammad A." <Mohammad.Rezaei at gs.com> wrote:
> Why do you expect the new classes in the JDK not to be part of the API?

An MVJAR is one unit of release. Should it have two or more public APIs? if so what is it's version and set of dependencies? Can it be deployed to maven central? Are those APIs source and/or binary compatibility?

So far we have taken a strict approach in terms of compatibility as it simplifies certain things at the expense of restricting other things as you have noted. 

Perhaps it's possible to relax that approach to some degree of compatibility? In your use-case could CustomFunction be extended to support Function in a source and binary compatible manner?


In general, as i tried to allude in the design document, there is this tension between: 

1) supporting the same API across multiple versions of the Java platform; and 

2) creating a new major version of the API, breaking compatibility with the old API and starting with a newer base Java platform version. 

This tension is always going to exist, especially for popular libraries. MVJARs is focused on the first case for some definition of "same".

Paul.


> 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