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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
