in fact, it's sad to require JDK 9 to compile to Java 7 and not support compiling directly with JDK 7
Perhaps the most simple action will be to check that JDK 8 or 9 is not used for crosscompilation to Java 7 or less, since it is not reliable Regards, Hervé Le lundi 27 juillet 2015 20:07:10 Robert Scholte a écrit : > Hi Hervé, > > there's no such thing as version specific configuration. And I don't think > it is really an issue. > With almost every new major version come new javac arguments, such as -s > for JDK6, -profile for JDK8. > > IMHO it is up to the user to specify the release value and add an enforcer > rule to require JDK9. > However, when using toolchains, it is easy to get the version. > > thanks, > Robert > > Op Mon, 27 Jul 2015 13:23:44 +0200 schreef Hervé BOUTEMY > > <herve.bout...@free.fr>: > > 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-Fil > >> e > >> > >> > > > 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=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4O > >> T > >> > >> > > > 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.Bas > >> i > >> > >> > >> cNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.templ > >> a > >> > >> > >> te.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-ins > >> t > >> > >> > >> 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 > > --------------------------------------------------------------------- > 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
