er... Caster, the bytecode does vary based on the compiler. And the class file format has varied a small amount from release to release with the 1.5 class file format being the most different.

This is, as I understand it, the crux of the problem you guys are seeing with adopting 1.5 ... yes?

- David

Caster wrote:

Actually, what I was asking was _would_ it work without the overlay? I
mean, if the ebuild is marked =virtual/jdk-1.4, then I could understand a
potential for trouble. But when it's just marked (whether by laziness or
whether it's correct) virtual/jdk, it'd be nice to know whether 1.5 could
work.


No idea, how much the dependencies correspond with "would/wouldn't
work". I wouldn't bet on that. The question, why would you so
desperately try to have 1.5 JDK as (generation-1 without migration
overlay) system vm? It can only break things, and gain you nothing.
Somebody correct me if I'm wrong, but the bytecode compiled will be the
same no matter which JDK you use. Any optimisations are done with
run-time JIT compiling, and depends on the VM running the bytecode
(which can be different from the VM used to compile). So, without
migration overlay, you should best follow the java 1.5 faq, have 1.4 as
sytem vm and use whatever vm as user vm.

Caster