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 |
> |