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-boun...@openjdk.java.net] On Behalf >Of Paul Sandoz >Sent: Friday, February 27, 2015 12:16 PM >Cc: core-libs-dev@openjdk.java.net >Subject: Re: JEP 238: Multi-Version JAR Files > >On Feb 27, 2015, at 4:47 PM, Florian Weimer <fwei...@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.