| 1 |
er... Caster, the bytecode does vary based on the compiler. And the |
| 2 |
class file format has varied a small amount from release to release with |
| 3 |
the 1.5 class file format being the most different. |
| 4 |
|
| 5 |
This is, as I understand it, the crux of the problem you guys are seeing |
| 6 |
with adopting 1.5 ... yes? |
| 7 |
|
| 8 |
- David |
| 9 |
|
| 10 |
|
| 11 |
Caster wrote: |
| 12 |
>> Actually, what I was asking was _would_ it work without the overlay? I |
| 13 |
>> mean, if the ebuild is marked =virtual/jdk-1.4, then I could understand a |
| 14 |
>> potential for trouble. But when it's just marked (whether by laziness or |
| 15 |
>> whether it's correct) virtual/jdk, it'd be nice to know whether 1.5 could |
| 16 |
>> work. |
| 17 |
>> |
| 18 |
> |
| 19 |
> No idea, how much the dependencies correspond with "would/wouldn't |
| 20 |
> work". I wouldn't bet on that. The question, why would you so |
| 21 |
> desperately try to have 1.5 JDK as (generation-1 without migration |
| 22 |
> overlay) system vm? It can only break things, and gain you nothing. |
| 23 |
> Somebody correct me if I'm wrong, but the bytecode compiled will be the |
| 24 |
> same no matter which JDK you use. Any optimisations are done with |
| 25 |
> run-time JIT compiling, and depends on the VM running the bytecode |
| 26 |
> (which can be different from the VM used to compile). So, without |
| 27 |
> migration overlay, you should best follow the java 1.5 faq, have 1.4 as |
| 28 |
> sytem vm and use whatever vm as user vm. |
| 29 |
> |
| 30 |
> Caster |
| 31 |
> |
Archives