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"
1 > Inspired by the recent ruby version handling post on gentoo-dev I came
2 > up with this scheme to handle JDK versions in the future:
3
4 While we are at it, could we consider the implications of jigsaw? And possibly
5 start working in the hooks to support that functionality.
6
7 For anyone why doesn't know jigsaw is the modularisation of java.
8 Read
9
10 http://openjdk.java.net/projects/jigsaw/
11
12 It seems to be based off debians version policy. see
13 http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
14
15 >
16 > 1. Have a JAVA_VERSION USE_EXPAND variable containing: "java5 java6" or
17 > any JDK versions supported at that time.
18 >
19 > 2. The minimum flag that is on is used for the JDK version to emerge
20 > things. Just setting -source is not in reality making things run with
21 > the target, it just makes the bytecode usable for older JDKs.
22 >
23 > 3. When depending on something java the eclasses will automatically pull
24 > in libraries targeting the right JDK using EAPI 2 use dependencies.
25 >
26 > Benefits:
27 > - You can compile everything to the highest byte code available
28 > - Simpler maintenance and marginally faster emerges when build.xml files
29 > don't always need to be rewritten.
30 > - Solve bug 161622 (java-config should look into the deptree when
31 > deciding wich vm to use)
32 >
33 > If this seem sane, it's best to rewrite the eclasses at the same time to
34 > delete all the cruft that we have collected over time like the different
35 > rewriter implementations.
36 >
37 > Regards,
38 > Petteri
39 >