Gentoo Archives: gentoo-java

From: Alistair Bush <ali_bush@g.o>
To: gentoo-java@l.g.o
Subject: Re: [gentoo-java] RFC: JDK version handling in the future
Date: Sat, 10 Oct 2009 19:04:08
Message-Id: 200910110804.19321.ali_bush@gentoo.org
In Reply to: [gentoo-java] RFC: JDK version handling in the future by "Petteri R├Ąty"
> Inspired by the recent ruby version handling post on gentoo-dev I came > up with this scheme to handle JDK versions in the future:
While we are at it, could we consider the implications of jigsaw? And possibly start working in the hooks to support that functionality. For anyone why doesn't know jigsaw is the modularisation of java. Read http://openjdk.java.net/projects/jigsaw/ It seems to be based off debians version policy. see http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
> > 1. Have a JAVA_VERSION USE_EXPAND variable containing: "java5 java6" or > any JDK versions supported at that time. > > 2. The minimum flag that is on is used for the JDK version to emerge > things. Just setting -source is not in reality making things run with > the target, it just makes the bytecode usable for older JDKs. > > 3. When depending on something java the eclasses will automatically pull > in libraries targeting the right JDK using EAPI 2 use dependencies. > > Benefits: > - You can compile everything to the highest byte code available > - Simpler maintenance and marginally faster emerges when build.xml files > don't always need to be rewritten. > - Solve bug 161622 (java-config should look into the deptree when > deciding wich vm to use) > > If this seem sane, it's best to rewrite the eclasses at the same time to > delete all the cruft that we have collected over time like the different > rewriter implementations. > > Regards, > Petteri >