JEP 238: Multi-Version JAR Files

[Paul Sandoz]

Sorry for the late reply, getting through email backlogs...

On Mar 1, 2015, at 11:41 AM, Florian Weimer <fweimer at redhat.com> wrote:

> On 02/27/2015 06:16 PM, Paul Sandoz wrote:
>> 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?
> 
> Tool support for that is still worse than for separate branches of the
> same project.
> 

Separate branches and different library versions with most likely backwards incompatible APIs, right?


> In general, VCS support for branches is still quite poor because the
> sensible thing to do is to develop a feature on the master branch and
> then backport it to older release branches as needed.  But such
> selective backwards-merging very much lacks VCS support because the
> least common ancestor logic build into almost all current tools does not
> apply in this scenario.  From a tool perspective, developing the feature
> in the oldest relevant release and then merging forward is the only
> supported way.  But it's usually bad engineering because you want new
> features to use current facilities of the code base.  So the only thing
> you have left is to cherry-pick individual patches (I think thats what
> “hg transplant” does in Mercurial).
> 
> Anyway, you lose the tiny bit of tool support you have for backporting
> if you have everything in the same source repository.
> 

>> 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	
>>  }
> 
> This really screams preprocessor. :-(

That's another approach, generate the sources using a pre-processor, which of course has it's own issues w.r.t. IDEs. Note i am not trying to dictate a particular project approach here.


> 
>> 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).
> 
> If that's the goal, something like Retroweaver seems far more
> appropriate than forcing library authors to maintain separate sources.
> 

Consider the case of library code using Unsafe for lexicographical unsigned byte[] comparison. It might be quite tricky for a tool to automate without the library itself telling the tool what to do. We are not proposing something more sophisticated such as runtime code transformations (discussed further by Remi).


> Multi-version JAR files seem useful because they will eventually allow
> evolution of the class file format.

Sorry, you lost me on that point.

Paul.

>  But I think the current use case
> isn't really there, I'm afraid.
> 
> -- 
> Florian Weimer / Red Hat Product Security