You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2016/09/17 14:53:51 UTC
Multi-Release JARs
Hi all
Jan an I met at a local JUG last Thursday and quickly chatted about ways
Ant could support Multi-Release JARs.
For details see http://openjdk.java.net/jeps/238
In short the jar is a ZIP file as it has always been. It is possible to
bundle classes and resources targeting different Java versions in a
single archive. Classes and resources for Java 8 and before go where
they've always gone - as files inside the typical hierarchy. Files that
shall overlay those files (or additional files for Java 9+) go into a
similar shaped hierarchy in META-INF/versions/VERSION. I.e. if class
org.example.Foo has a new feature for Java9 but Java8 shall use the
"normal version" you'd have
org/example/Foo.class
META-INF/versions/9/org/example/Foo.class
The new jar implementation will first look into the META-INF/versions/X
directory for the current version X, then any lower version should one
exist and finally the "normal" place for a class or resource.
Things I see we could do (and I'm sure this list is not exhaustive):
* provide a new kind of <zipfileset> that uses
META-INF/versions/${version} as prefix to the stuff to be included in
a jar. I.e.
<jar ...>
<new-kind-of-zipfileset dir="java9-classes" version="9"/>
</jar>
would package the content of java9-classes/** under
META-INF/versions/9
* provide a new kind of <zipfileset> that mimics the selection logic
when reading from a jar. I.e.
<new-kind-of-zipfileset src="some.jar" version="9"/>
will include the contents and meta-data like timestamp of
META-INF/versions/9/org/example/Foo.class using the name
org/example/Foo.class
* Multi-Release JARs need a special manifest attribute, we should add an
attribute to the jar task that sets this.
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Multi-Release JARs
Posted by Dominique Devienne <dd...@gmail.com>.
On Wed, Sep 21, 2016 at 2:08 PM, Jan Matèrne (jhm) <ap...@materne.de>
wrote:
> I did a simple version using plain <jar> and <zipfileset>.
>
Nice and simple. Great test. I like it! --DD
AW: Multi-Release JARs
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
Thanks.
I installed jdk190-ea136 and added an additional test:
...
<loadresource property="valueFromJava">
<javaconstant name="org.apache.ant.test.MRJarTest.VERSION">
<classpath>
<pathelement location="${antunit.tmpdir}/mrjar.jar"/>
</classpath>
</javaconstant>
</loadresource>
...
<!-- If we are running on Java9, we could really try the MRJar -->
<sequential if:set="jdk9+" xmlns:if="ant:if">
<echo>running on Java9</echo>
<au:assertEquals
expected="Java9" actual="${valueFromJava}"
message="Running on Java9 we should have read the Java9-value jdk9=${jdk9+} value=${valueFromJava}"/>
</sequential>
But it loads only the Java8-value, not the Java9 from .../versions/9/...
Having a look with a hex editor the Java9 value is inside the class file.
Any idea?
Jan
> -----Ursprüngliche Nachricht-----
> Von: Stefan Bodewig [mailto:bodewig@apache.org]
> Gesendet: Mittwoch, 21. September 2016 19:03
> An: dev@ant.apache.org
> Betreff: Re: Multi-Release JARs
>
> On 2016-09-21, Jan Matèrne (jhm) wrote:
>
> > I did a simple version using plain <jar> and <zipfileset>.
>
> Nice.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional
> commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Multi-Release JARs
Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-09-21, Jan Matèrne (jhm) wrote:
> I did a simple version using plain <jar> and <zipfileset>.
Nice.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
AW: Multi-Release JARs
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
I did a simple version using plain <jar> and <zipfileset>.
Jan
> -----Ursprüngliche Nachricht-----
> Von: Stefan Bodewig [mailto:bodewig@apache.org]
> Gesendet: Sonntag, 18. September 2016 12:21
> An: dev@ant.apache.org
> Betreff: Re: Multi-Release JARs
>
> On 2016-09-17, Jan Matèrne (jhm) wrote:
>
> >> * Multi-Release JARs need a special manifest attribute, we should
> add an
> >> attribute to the jar task that sets this.
>
> > I dont think so. We could set this flag by ourself if the
> > <new-kind-of-zipfileset> is set.
>
> Agreed. People who want to manually put together the jar would have to
> set the attribute themselves, then.
>
> > We discussed also the possibility of merging different jars.
> > Say you have a Java8 jar, a Java9 jar and a Java10 jar, you could
> > merge these into a multirelease jar.
>
> > Because of the different classfile versions, the common files of
> these
> > jars arent identical, so we cant find them easily. So the easy, but
> > not smart, solution ends in having the common files in every version
> branch of the jar.
>
> <jar ....>
> <zipfileset src="java8.jar"/>
> <new-kind-of-zipfileset src="java9.jar" version="9"/>
> ...
> </jar>
>
> could work that way. Likely would need to perform some fiddling WRT
> manifest attributes.
>
> > Another idea I had (for few minutes) is combining the jar'ing with
> the
> > compiling.
> > <mrjar ...>
> > <default targetdir=""><src-resource-collection></default>
> > <version version="9" targetdir=""><src-resource-collection>
> point
> > to
> > Java9 only </version>
> > <version version="10" targetdir=""><src-resource-collection>
> > point to Java10 only </version> <mrjar> would do three compile runs
> > now
> > * default: Java8
> > * version=9: Java9, with classes from previous runs on classpath
> > (havent thought about the identical names yet ... ;)
> > * version=10: Java10, ...
> > Finally create the MRJar.
>
> I guess configuration of the task will be quite longish but I can see
> how this would streamline hte process.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional
> commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Multi-Release JARs
Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-09-17, Jan Matèrne (jhm) wrote:
>> * Multi-Release JARs need a special manifest attribute, we should add an
>> attribute to the jar task that sets this.
> I dont think so. We could set this flag by ourself if the
> <new-kind-of-zipfileset> is set.
Agreed. People who want to manually put together the jar would have to
set the attribute themselves, then.
> We discussed also the possibility of merging different jars.
> Say you have a Java8 jar, a Java9 jar and a Java10 jar, you could merge
> these into a multirelease jar.
> Because of the different classfile versions, the common files of these jars
> arent identical, so we cant find them easily. So the easy, but not smart,
> solution ends in having the common files in every version branch of the jar.
<jar ....>
<zipfileset src="java8.jar"/>
<new-kind-of-zipfileset src="java9.jar" version="9"/>
...
</jar>
could work that way. Likely would need to perform some fiddling WRT
manifest attributes.
> Another idea I had (for few minutes) is combining the jar'ing with the
> compiling.
> <mrjar ...>
> <default targetdir=""><src-resource-collection></default>
> <version version="9" targetdir=""><src-resource-collection> point to
> Java9 only </version>
> <version version="10" targetdir=""><src-resource-collection> point to
> Java10 only </version>
> <mrjar> would do three compile runs now
> * default: Java8
> * version=9: Java9, with classes from previous runs on classpath (havent
> thought about the identical names yet ... ;)
> * version=10: Java10, ...
> Finally create the MRJar.
I guess configuration of the task will be quite longish but I can see
how this would streamline hte process.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
AW: Multi-Release JARs
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
In the current "Java Spectrum" there is an article about some Java9 topics,
including the multi-release-jar.
They point to a Maven proof of concept. So we could (should) have a look
there, too.
https://github.com/hboutemy/maven-jep238
> Things I see we could do (and I'm sure this list is not exhaustive):
>
> * provide a new kind of <zipfileset> that uses
> META-INF/versions/${version} as prefix to the stuff to be included in
> a jar. I.e.
>
> <jar ...>
> <new-kind-of-zipfileset dir="java9-classes" version="9"/>
> </jar>
>
> would package the content of java9-classes/** under
> META-INF/versions/9
>
> * provide a new kind of <zipfileset> that mimics the selection logic
> when reading from a jar. I.e.
>
> <new-kind-of-zipfileset src="some.jar" version="9"/>
>
> will include the contents and meta-data like timestamp of
> META-INF/versions/9/org/example/Foo.class using the name
> org/example/Foo.class
>
> * Multi-Release JARs need a special manifest attribute, we should add an
> attribute to the jar task that sets this.
I dont think so. We could set this flag by ourself if the
<new-kind-of-zipfileset> is set.
We discussed also the possibility of merging different jars.
Say you have a Java8 jar, a Java9 jar and a Java10 jar, you could merge
these into a multirelease jar.
Because of the different classfile versions, the common files of these jars
arent identical, so we cant find them easily. So the easy, but not smart,
solution ends in having the common files in every version branch of the jar.
Another idea I had (for few minutes) is combining the jar'ing with the
compiling.
<mrjar ...>
<default targetdir=""><src-resource-collection></default>
<version version="9" targetdir=""><src-resource-collection> point to
Java9 only </version>
<version version="10" targetdir=""><src-resource-collection> point to
Java10 only </version>
<mrjar> would do three compile runs now
* default: Java8
* version=9: Java9, with classes from previous runs on classpath (havent
thought about the identical names yet ... ;)
* version=10: Java10, ...
Finally create the MRJar.
(just for bringing these ideas to the mailinglist)
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org