1 |
Jörg Schaible kirjoitti: |
2 |
> |
3 |
>> Also like I said - more and more things require 1.5, which means that all |
4 |
>> things depending on them also need to be >= 1.5. For example: new hessian |
5 |
>> requires >= 1.5, which means that mx4j needs also to be switched to 1.5, |
6 |
>> which means we have to switch anything depending on mx4j, and so on. |
7 |
> |
8 |
> So, and where can I define then my minimum supported JDK version |
9 |
> (setting -source and -target)? Can I define that my system should be JDK |
10 |
> 1.3 compatible - at least for all packages that support this (e.g. |
11 |
> commons-logging)? Will packages like mx4j slotted to have the last JDK 1.4 |
12 |
> compatible and the JDK 5 compatible version? ... No, I know. However, I |
13 |
> still have to provide JDK 1.3 (or at least 1.4) compatible software. And |
14 |
> this does not simply mean to compile code, it also means to run it! |
15 |
> |
16 |
> This will more or less lead to the situation, where I have to drop the |
17 |
> complete Gentoo Java packages (except the JDK's themselves) and install |
18 |
> everything else myself using the binaries. |
19 |
> |
20 |
> - Jörg |
21 |
> |
22 |
|
23 |
There is no pressing need to start building 1.5 bytecode as long as an |
24 |
application compiles with 1.4 but if an application uses 1.5 features we |
25 |
will not be backporting the code to work with 1.4 which would be |
26 |
required for you to be able to run applications with 1.4. If you want to |
27 |
maintain such ebuilds we can give you access to an overlay where you can |
28 |
keep 1.4 compatible ebuilds around. The Java team doesn't have that much |
29 |
man power and it's better used towards other things than keeping 1.4 |
30 |
functional with our hundreds of packages. |
31 |
|
32 |
Regards, |
33 |
Petteri |