JEP 238: Multi-Version JAR Files

[Paul Sandoz]

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.