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
>