AW: Multi-Release JARs
Thanks. I installed jdk190-ea136 and added an additional test: ... ... running on Java9 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:bode...@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 and . > > Nice. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Multi-Release JARs
On 2016-09-21, Jan Matèrne (jhm) wrote: > I did a simple version using plain and . Nice. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Multi-Release JARs
On Wed, Sep 21, 2016 at 2:08 PM, Jan Matèrne (jhm) wrote: > I did a simple version using plain and . > Nice and simple. Great test. I like it! --DD
AW: Multi-Release JARs
I did a simple version using plain and . Jan > -Ursprüngliche Nachricht- > Von: Stefan Bodewig [mailto:bode...@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 > > 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. > > > > > ... > > > 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. > > > > > > > point > > to > > Java9 only > > > > point to Java10 only 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-unsubscr...@ant.apache.org For additional > commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
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 > 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. ... 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. > > > point to > Java9 only > point to > Java10 only > 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: Multi-Release JARs
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 that uses
> META-INF/versions/${version} as prefix to the stuff to be included in
> a jar. I.e.
>
>
>
>
>
> would package the content of java9-classes/** under
> META-INF/versions/9
>
> * provide a new kind of that mimics the selection logic
> when reading from a jar. I.e.
>
>
>
> 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
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.
point to
Java9 only
point to
Java10 only
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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
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 that uses
META-INF/versions/${version} as prefix to the stuff to be included in
a jar. I.e.
would package the content of java9-classes/** under
META-INF/versions/9
* provide a new kind of that mimics the selection logic
when reading from a jar. I.e.
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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
