I tested the new -release flag and it works like a charm: not only is it easier to use (1 flag instead of 3 = source/target/bootclasspath), but it avoids the famous covariance problem previously found [1] (and that happens with JDK 9 when not using this new -release flag)
Then I think it's important to add support for this flag in a future maven- compiler-plugin version. Striclty adding this option should not be a problem. But the problem I see is that once a build is configured with this flag, you *must* use a JDK 9+ to build: I don't see how to make the flag used only when available. Any idea? Regards, Hervé [1] https://gist.github.com/AlainODea/1375759b8720a3f9f094 Le vendredi 17 juillet 2015 19:39:22 Arnaud Héritier a écrit : > Hi all, > > > FYI Paul Sandoz forwarded us this email if you don't follow the jdk9-dev ML > > == > > Hi, > > In case you are not monitoring this alias. > > This is likely relevant to not just to MRJARs but also to maven java > compiler support and the sniffer/conformance plugins etc. > > Paul. > > Begin forwarded message: > > *From: *joe darcy <joe.da...@oracle.com> > *Subject: **New feature in JDK 9 builds: javac -release $VERSION* > *Date: *July 13, 2015 5:50:54 AM GMT+02:00 > *To: *"jdk9-...@openjdk.java.net" <jdk9-...@openjdk.java.net> > > Hello, > > As of JDK 9 b72 [1], a feature recently pushed by Jan Lahoda is now > available: the javac -release command line option. > > This feature was developed under JEP 247: Compile for Older Platform > Versions [2]. In brief, to use javac to cross-compile to an older release > of the platform it is not sufficient to just set the -source and -target > options to the older value; the bootclasspath must also be set to > correspond to the older release too. [3] Setting the bootclass was often > forgotten and acquiring the needed information could be inconvenient. > > The -release flag in javac addresses both of these shortcomings. Now only a > single flag (-release) needs to be set to cross compile compared to three > flags (-source, -target, -bootclasspath) and the needed information is > included in the JDK. The set of release values follows the same "one plus > three back" policy now used for the -source and -target options. [4] > Therefore, in JDK 9, the accepted argument values for -release are 6, 7, 8, > and 9. > > Feedback on the this feature can be sent to compiler-...@openjdk.java.net. > > Cheers, > > -Joe > > [1] https://jdk9.java.net/download/ > > [2] http://openjdk.java.net/jeps/247 > > [3] "How to cross-compile for older platform versions," > https://blogs.oracle.com/darcy/entry/how_to_cross_compile_for > > [4] JEP 182: Policy for Retiring javac -source and -target Options > http://openjdk.java.net/jeps/182 > > > On Fri, Jul 10, 2015 at 8:47 AM, Hervé BOUTEMY <herve.bout...@free.fr> > > wrote: > > Le jeudi 9 juillet 2015 09:48:13 Tibor Digana a écrit : > > > Nice project indeed. > > > Maybe only JRE has the benefit from multi-version JAR, but I cannot > > > > imaging > > > > > this feature in ordinal projects. > > > > +1 > > currently, there are not so much projects that produce a different > > artifact for > > different JREs, but there are, even if not the majority > > see the JEP [1] "Motivation" section > > > > > Who has benefit from writing the code > > > three times if API of module matters. Maybe performance will be > > > different > > > only. > > > > notice that one of the motivation, apart from the use case you are > > thinking > > to, is that with JDK modularization, there are intends to deprecate some > > APIs > > (internal or not): this MVjar will be useful to deal with such type of JDK > > evolution (and stop with current problem that any new JDK adds APIs but > > never > > ever removes anything) > > This is a long term goal: the feature has to be there, be successful and > > prove > > being usable for the most specific libraries before expecting using it > > more to > > support JDK cleanup (in Java 10 or more) > > > > > > What I'm satisfied now with the working example is that whatever one > > thinks > > about the feature, Maven is not in the way: there is now a proved recipe > > to > > create MVjars if the feature gets added into a JRE, and this base recipe > > does > > not require any change in any tool (be it Maven or IDE integration) > > > > There is IMHO still one issue in the recipe: there is a trick (written by > > Paul > > Sandoz, who gave me its initial work) to avoid installing intermediate > > artifacts (to limit the impact of multi-modules, since intermediate > > artifacts > > don't really have any meaning). I didn't try to deploy the current demo, > > but I > > fear it currently would fail: I suppose that's my next test now the the > > mvjar > > is great (thanks to Robert's help :) ) > > > > Regards, > > > > Hervé > > > > > > [1] http://openjdk.java.net/jeps/238 > > > > > On Thu, Jul 9, 2015 at 1:08 AM, Hervé BOUTEMY [via Maven] < > > > > > > ml-node+s40175n5839659...@n5.nabble.com> wrote: > > > > Hi, > > > > > > > > In april, we had a discussion about Multi-Version JAR Files. > > > > > > > > Since then, we worked to create a sample project built with Maven, to > > > > see > > > > > > how > > > > Maven configuration would currently look like, before trying to create > > > > new > > > > > > features to make more compact configuration and avoid multi-modules > > > > creation. > > > > > > > > Here is the result: > > > > https://github.com/hboutemy/maven-jep238 > > > > > > > > AFAIK, the result of this code is a valid MVJar, and this gives a good > > > > overview of a basic Maven recipe to make MVJars. > > > > > > > > There is one limitation I have with assembly in the last module: I > > > > can't > > > > > > exclude /META-INF content from every versioned content (ie avoid > > > > /META- > > > > INF/versions/*/META-INF in final MVJar). > > > > > > > > Is it me or excludes don't work as expected in assembly plugin? > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [hidden email] > > > > <http:///user/SendEmail.jtp?type=node&node=5839659&i=0> > > > > For additional commands, e-mail: [hidden email] > > > > <http:///user/SendEmail.jtp?type=node&node=5839659&i=1> > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > If you reply to this email, your message will be added to the > > > > discussion > > > > > > below: > > http://maven.40175.n5.nabble.com/DISCUSSION-JEP-238-Multi-Version-JAR-File > > > > > > s-tp5839659.html> > > > > > > > > To start a new topic under Maven Developers, email > > > > > > > > ml-node+s40175n142166...@n5.nabble.com > > > > To unsubscribe from Maven Developers, click here > > > > < > > > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscri > > > > be_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OT > > > > > > Q5MjEwMg==> . > > > > NAML > > > > < > > > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_vie > > > > wer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.Basi > > > > cNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.templa > > > > te.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-inst > > > > ant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > > > > > -- > > > > > View this message in context: > > http://maven.40175.n5.nabble.com/Re-DISCUSSION-JEP-238-Multi-Version-JAR-F > > i > > > > > les-tp5839680.html Sent from the Maven Developers mailing list archive > > > at > > > Nabble.com. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
