| 1 |
>>> The default choice is the highest version of the default vm set for the |
| 2 |
>>> arch. |
| 3 |
>> Hmm. And the code is also compiled against the newest class library? |
| 4 |
>> |
| 5 |
>> For the given reasons (see the example code) that's not a good idea. |
| 6 |
>> Code compiled with a too new JDK might actually throw |
| 7 |
>> NoSuchMethodErrors, for example. |
| 8 |
>> |
| 9 |
> |
| 10 |
> People committing ebuilds and marking them stable should make sure that |
| 11 |
> it works with the lowest atom specified by the dependencies. |
| 12 |
|
| 13 |
This is an undoable task, for two reasons: |
| 14 |
|
| 15 |
1) First, things can break, after recompiling with a newer JDK version. |
| 16 |
So adding a new JDK to the tree, would yield a HUGE wave of testing. |
| 17 |
2) Second, the Exceptions only get thrown at runtime - so especially, if |
| 18 |
such an issue is conditional (inside an if-statements) it maybe never |
| 19 |
discovered. |
| 20 |
|
| 21 |
|
| 22 |
Of course, as said in the other postings, the code always compiles fine. |
| 23 |
It just isn't sure to assume that it runs with JDK X when it is compiled |
| 24 |
against JDK Y - especially if or although Y is newer than X. |
Archives