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-Fi > > 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 > > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
