Yes net beans does support it, jesse Glick (who is a net beans fanboy... Because he used to be a net beans developer) foisted a JDK 6 for src/main and JDK 8 for src/test on us at work... Where we all are left cursing IntelliJ for not supporting same
On Tuesday, April 14, 2015, Milos Kleint <mkle...@gmail.com> wrote: > afaik netbeans does support it (having different source/target level for > test and main source) Not from the UI, but if you have your compiler plugin > setup properly, it will take it into account. > > Milos > > On Sat, Apr 11, 2015 at 11:35 PM, Kristian Rosenvold < > kristian.rosenv...@gmail.com <javascript:;>> wrote: > > > 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, but also like a great can of worms > > :) I assume minimum compiler requirement would be java-8 for a project > > with src/main/java-8 ? > > > > K > > > > > > 2015-04-11 15:11 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr > <javascript:;>>: > > > 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 > <javascript:;>>: > > >> > 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/jav > > >> > 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/031461 > > >> >> .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 > <javascript:;> > > >> >> For additional commands, e-mail: dev-h...@maven.apache.org > <javascript:;> > > >> > > > >> > > --------------------------------------------------------------------- > > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > <javascript:;> > > >> > For additional commands, e-mail: dev-h...@maven.apache.org > <javascript:;> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > <javascript:;> > > >> For additional commands, e-mail: dev-h...@maven.apache.org > <javascript:;> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > <javascript:;> > > > For additional commands, e-mail: dev-h...@maven.apache.org > <javascript:;> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> > > For additional commands, e-mail: dev-h...@maven.apache.org > <javascript:;> > > > > > -- Sent from my phone
