Le samedi 11 avril 2015 15:35:02 Kristian Rosenvold a écrit :
> Technically we support "main" scoped sources in java6 and "test"
> scoped sources in java7 today, but the feature is largely unusable
> since IDE support is totally missing. Even IntelliJ does not support
> it (https://youtrack.jetbrains.com/issue/IDEA-85478 and other issues)
>
> :(
>
> There might be some hope of gaining some kind of traction to both
> source and main-level support of multi-language-level modules. Maybe
> something like (src/main/java and src/test/java = "default language"
> level) while src/[main|test]/java-8 would be a specific language
> level. This sounds infinitely cool,
yes, that's what I did in plexus-utils jdep-238 branch
https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main
> but also like a great can of worms
>
> :)
yes, I fear it's not so easy for IDEs...
> I assume minimum compiler requirement would be java-8 for a project
>
> with src/main/java-8 ?
yes, I think that's what makes such support hard at the moment: require the
highest JDK, and signature for every lower JDK to avoid newer APIs
unless JDK 9 can safely compile for any older target, checking the API
(without having to run Animal Sniffer after that)
Regards,
Hervé
>
> K
>
> 2015-04-11 15:11 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:
> > Le samedi 11 avril 2015 10:54:34 Kristian Rosenvold a écrit :
> >> IDE support for multiple source trees seems quite far off ?
> >
> > IDE support for current situation, where we mix multiple Java API versions
> > in one single source tree, is even more far off!
> >
> > With separate source trees, IDE support starts like we are at the moment =
> > no IDE support
> >
> > but IDEs that want to do something about it have a chance: that's the big
> > difference IMHO
> >
> > Regards,
> >
> > Hervé
> >
> >> Kristian
> >>
> >> 2015-04-11 8:51 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:
> >> > Hi,
> >> >
> >> > Yesterday at DevoxxFR, Carlos Sanchez, Arnaud Héritier, Nicolas de Loof
> >> > and me met Brian Goetz and discussed about the objective of JEP 238 and
> >> > what we could get from such a feature.
> >> >
> >> > Having a face to face explanation in front of a white board gave
> >> > interesting ideas: then, *as library maintainer*, I tried to modifiy
> >> > plexus-utils code to use MVJAR for Java 7 enhancement that are
> >> > currently
> >> > triggerred through reflection
> >> >
> >> >
> >> > Here is the result [1]:
> >> >
> >> > I extracted 2 little xxxMv classes containing only the few methods that
> >> > had to be enhanced when runing on Java 7, replacing the
> >> >
> >> > if (Java7Detector.isJava7()) {
> >> >
> >> > // java 7
> >> >
> >> > } else {
> >> >
> >> > // Java 5
> >> >
> >> > }
> >> >
> >> > stanza with the default Java 5 code in the main src/main/java source
> >> > tree
> >> > and Java 7 reimplementation in src/main/java-7 source tree
> >> >
> >> > and I did cleanup: removed Java7Detector and moved NioFiles to this
> >> > java-7
> >> > specific source tree
> >> >
> >> >
> >> > the result is a main src/main/java source tree that can be compiled
> >> > with
> >> > JDK 5 and a src/main/java-7 source tree that is minimal to be compiled
> >> > with JDK 7
> >> >
> >> >
> >> > I still didn't try to update pom.xml to see what maven-compiler-plugin
> >> > and
> >> > maven-jar-plugin configurations could look like.
> >> >
> >> > and I don't know if javac will be enhanced to do the 2 compilations in
> >> > 1
> >> > command like "javac -target 1.5 src/main/java -target 1.7
> >> > src/main/java-7"
> >> > or if it'l have to launch 2 javac one after the other
> >> >
> >> > I didn't look at maven-jar-plugin to see if it uses "jar" command that
> >> > will be enhanced to mix multiple target/classes or if it uses JarFile
> >> > class then will need to code the mix
> >> >
> >> > and I don't know if javac will have tru crossplatform compilation
> >> > option,
> >> > to avoid using 2 JDKs (ie JDK 5 for compiling java 5 code and being
> >> > sure
> >> > there is no Java 7 API reference, and JDK 7 for the java 7 part)
> >> >
> >> >
> >> > I see there will be impact on tooling, and if javac does a part of the
> >> > job,
> >> > this will be a lot easier to implement at Maven level
> >> >
> >> >
> >> > But at the moment, my objective was not from Maven point of view but
> >> > library developper point of view: show a real world case of how an
> >> > existing library could be refactored to use the feature, expecting that
> >> > the new source code would be easier to maintain
> >> >
> >> >
> >> > WDYT?
> >> >
> >> > Regards,
> >> >
> >> > Hervé
> >> >
> >> >
> >> >
> >> >
> >> > [1]
> >> > https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main/j
> >> > av
> >> > a-7/org/codehaus/plexus/util>
> >> >
> >> > Le jeudi 19 mars 2015 23:38:32 Robert Scholte a écrit :
> >> >> Hi,
> >> >>
> >> >> we've been asked to give our opinion on the JEP 238: Multi-Version JAR
> >> >> Files
> >> >>
> >> >> Here's a quote from Rory O'Donnels e-mail:
> >> >> ---
> >> >>
> >> >> It's goal is to extend the JAR file format to allow multiple, JDK
> >> >>
> >> >> release-specific versions of class
> >> >>
> >> >> files to coexist in a single file. An additional goal is to backport
> >> >> the
> >> >>
> >> >> run-time changes to
> >> >>
> >> >> JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For
> >> >> a
> >> >>
> >> >> detailed discussion,
> >> >>
> >> >> please see the corresponding thread on the core-libs-dev mailing
> >> >> list.
> >> >> [1]
> >> >>
> >> >> Please keep in mind that a JEP in the Candidate state is merely an
> >> >> idea
> >> >>
> >> >> worthy of consideration
> >> >>
> >> >> by JDK Release Projects and related efforts; there is no commitment
> >> >> that
> >> >>
> >> >> it will be delivered in
> >> >>
> >> >> any particular release.
> >> >>
> >> >> Comments, questions, and suggestions are welcome on the corelibs-dev
> >> >>
> >> >> mailing list. (If you
> >> >>
> >> >> haven’t already subscribed to that list then please do so first,
> >> >>
> >> >> otherwise your message will be
> >> >>
> >> >> discarded as spam.)
> >> >>
> >> >> [0] http://openjdk.java.net/jeps/238
> >> >> [1]
> >> >>
> >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031
> >> >> 461
> >> >> .ht ml
> >> >>
> >> >> ---
> >> >>
> >> >> IIUC the original request was to have different version of the same
> >> >> class
> >> >> within the same artifact. On the mailinglist I noticed a more
> >> >> interesting
> >> >> idea: you need a mechanism to map Classes, Methods or Fields from one
> >> >> version to the other.
> >> >>
> >> >> From a Maven perspective I don't see that much issues with the
> >> >> original
> >> >>
> >> >> idea. You should already be able to do it right now with a lot of
> >> >> execution-blocks.
> >> >> However, I don't see how users would maintain different version of the
> >> >> same class (within an IDE).
> >> >> To me this all looks quite complex for rare cases.
> >> >> If you really want multiple JDK versions of the same artifact, I would
> >> >> probably split them into classified artifacts.
> >> >>
> >> >> Any other comments?
> >> >>
> >> >> thanks,
> >> >> Robert
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> 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
>
> ---------------------------------------------------------------------
> 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
