[gentoo-java] RFC: JDK version handling in the future

[gentoo-java] RFC: JDK version handling in the future

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

Inspired by the recent ruby version handling post on gentoo-dev I came
up with this scheme to handle JDK versions in the future:

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-java] RFC: JDK version handling in the future

[Alistair Bush]

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