Sorry for the late reply, getting through email backlogs...
On Mar 1, 2015, at 11:41 AM, Florian Weimer <fwei...@redhat.com> wrote:
> On 02/27/2015 06:16 PM, Paul Sandoz wrote:
>> 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?
>
> 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
