JEP 238: Multi-Version JAR Files

[Remi Forax]

On 04/15/2015 01:04 PM, Paul Sandoz wrote:
> Hi Markus,
>
> Sorry for the late reply i have been away for the last 3 weeks.
>
> You and your colleagues might be interested in discussion of JEP 238 on org.apache.maven.dev:
>
>    http://markmail.org/thread/v5ywgdpuprntrvfu#query:+page:1+mid:v5ywgdpuprntrvfu+state:results
>
> especially when it gets to the technical discussion of how maven could support the production of MVJARs.
>
>
> On Mar 31, 2015, at 1:44 PM, Markus Keller <markus_keller at ch.ibm.com> wrote:
>
>> I've discussed this with the Eclipse JDT team. We're very skeptic and we think that JEP 238 goes into a wrong direction. Eclipse JDT does not intend to add special support for it.
>>
>> Building such MVJARs will be quite complicated, since it requires having separate classpaths and compiling against multiple JDKs to produce the release-specific class files that should end up in the same MVJAR. That means you either need a preprocessor that would allow to keep JDK-release-specific code in the same *.java file, or you need to maintain and sync separate *.java files in separate source folders.
> Is it really quite so complicated? especially if it is anticipated that only a small number of sources files are likely to be affected?
>
>
>> Both options are completely counter Java's "write once, run anywhere" idea, whose foundation is to have only one set of source files and no platform-specific compilation switches. This is one of the greatest features of Java. It's what makes reliable code analysis, dependency tracking, and refactoring possible.
>>
> The trouble with such maxims is they can be easily co-opted to ones point of view :-) (my comment is in jest, but there is a point too) for example i can reasonably argue that MVJARs are actually increasing the ability to run anywhere, and that benefits all consumers of such JARs.
>
> Note that in terms of dependency tracking one is not proposing that the dependencies above the major platform would change. Nor would the API (there may be some form of backward compatible change, see the brief discussion between Moh and myself).
>
> I agree that changes would be required to both tooling and IDEs. I am interested in knowing how difficult such changes might be. Are there a series of smallish changes, each of which is not terribly difficult, or is there something fundamentally insurmountable?
>
>
>> Furthermore, the general problem is not specific to the JDK, but also occurs for other libraries. Therefore, a JDK-specific solution would be at the wrong level.
>>
> Just because it's JDK specific does not mean it is de-facto at the wrong level. It's attempting to solve a smaller and much simpler problem.
>
>
>> A better solution for such cases is to provide an adapter JAR that makes the new APIs available when running on an older JDK. That way, the problem is solved at the origin, and not again and again for each client. And with "the problem", I mean the problem that the old JDK release didn't offer an API for something that clients should use ASAP, even if they can't require the whole new JDK release right away.
>>
> That does not solve the problem of internal or deprecated APIs present in N going away in N+1.
>
> Layering JDK classes (in JARS) on top of the JDK platform is not very practical. Such classes often have special treatment, we don't want to recommend using the boot classpath, and i don't think developers will be very happy having using such options and manage additional dependencies associated with the platform.
>
> Of course we cannot feasibly backport every new API in N to N-1, N-2 etc. In selective cases that might be possible, but for the core of the JDK it's like pulling on a string of public dependencies, internal dependencies and perhaps more subtle dependencies between javac and hotspot (Unsafe replacements would be particularly tricky).

that why most of the tools like the retroweaver [1] rewrite bytecodes 
because you can replace a dependency to a JDK class to wire it to a 
class that will come with your code.

Note that in that case, you develop and maintain only one version of the 
code compatible with the newer version and backport the code to the old 
one, instead of selectively develop part of the code with the new 
version as you propose.

>
> Paul.

cheers,
Rémi

[1] http://retroweaver.sourceforge.net/