On Mon, Apr 13, 2015 at 11:16 PM, Jörg Schaible <joerg.schai...@gmx.de> wrote:
> Hi Arnaud, > > Arnaud Héritier wrote: > > > In short/middle term the lack of IDE integration isn't a real problem for > > now. > > Like Brian said, they know that users won't use such feature before > > several years. > > The runtime part providing the compatibility for the JRE should be > > backported to Java 8 but only Java 9 JDK will provide required tools to > > create such jars. > > The goal to involve build tools ASAP is to validate the technical > > feasibility to integrate such new feature before J9 is out (and not to > > wait for its delivery to do it - and complain when it will be too late) > > You can already use several executions for the compiler plugin to create a > jar file with classes targeting different JDKs. That's what XStream does > for > years already. > yes exactly. But to be user friendly we'll have to provide something easy to setup. Not 100 lines of XML > > The challenge is that you have multiple class files with same name. > Yes. AFAIU for now it will be several call of javac with a new option for the targeted platform 1 call of javac with java 7 for example and then a call of javac with the result of J7 build + sources for 8 + option for the J8 platform target .... > > > What we need to do here is to imagine how it will be in 2/3? years when > > we'll start to have developers using a JDK9 who'll want to provide > > librairies compatible (and optimized) for previous JREs. > > > > For me (in my dreams) it should clearly be in only one module and thus > > probably with additional sources directories. The compiler plugin should > > hide (in one or several steps) the compilation of sources and the jar > > packaging should discover if it has to create a mvjar or not > > You have different use cases here. One time you have one Java source that > will behave different depending against which runtime libs you have > compiled > (e.g. a different overloaded method is used). In another scenario your Java > code actually differs. > > So, for Maven there might be several src folders ... or you have > annotations > at types, methods and/or fields indicating the target runtime. > > However, the result should be a jar file that allows a client to write code > that is indifferent of the multiple versions of a class. Wait ... maybe the > client will have to create a mvjar himself, because the different versions > also result in different versions of his own code (think about JDBC api) > ...? > I remember about the JDBC API breakage (it was in J5 ?) but what mvjar wants to cover is that case of an api which doesn't change across implemented platforms (only the implementation itself). If the API changes this is another problem. > > IMHO, mvjars will create a bigger maintenance mess than the current > solutions. > I don't know. I think it really depends if your are provider or consumer of mvjars. If you are consumer you may imagine to not have to manually switch anymore between several implementations (using classifiers ....) and it gives you the ability to do the selection at runtime and not at build time. As producer I agree that it won't be easy if tools (Build, IDE) aren't providing a good/simple support. That's why Oracle (Brian) is trying to involve us. > > - Jörg > > > --------------------------------------------------------------------- > 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
