Re: jvm wishes and gripes

[Adam Megacz <gcj at lists dot megacz dot com>]

Cedric Berger <cedric@wireless-networks.com> writes:
> >I can't really be the only person who wants this stuff, can I?

> I believe it's too late to change java bytecode. For example, what would
> you do with all the microcontrollers that interprets the java bytecode 
> directly?

Fat binaries. They should have put in a
relitave-jump-if-jvm-version-less-than-x opcode, which would optimize
out in a half-intelligent JIT, and which the verifier could skip over
in old VM's.

But you're right, that's 20/20 hindsight. They're sort of screwed
now.

Actually, what about doing extensibility via special methods? For example:

   java.vmspecific.Foo.foo();

When you distribute your bytecodes, you include an implementation for
that method (which is executed on old VM's). Newer VM's know that
"java.vmspecific" is a "magic" package, and that method invocations in
it should be replaced with "new" bytecodes.

I could see doing generic types this way... put one of these calls
before each extraneous classcast check telling the JIT "hey, if you do
stronger type checking, you can skip the classcast check that follows
this method". The bytecode for old vm's to execute would be a NOP --
the invocation is just a marker.

It's a hack, alright.

Hrm, I wonder if you can do stackvars this way...


> your code above will be valid under the new specs.

Finally!

  - a