On Oct 7, 2:44 am, Kram <[EMAIL PROTECTED]> wrote:
> Ok, so this is probably one of those "its just not that simple" type
> of questions, but why would it be far more difficult to change a spec
> and maintain backwards compatibility with the JVM?
I'm not sure what backwards compatibility is supposed to mean in the
context of JVMs -
if the question is about reading and executing code in the same way as
an earlier JVM,
that's pretty trivial to maintain in a spec: just introduce some kind
of flag that switches
between different modes of operation (lookup ACC_SUPER
and invokespecial for an example).
What makes radical changes in the VM spec unlikely is that the JVM is
extremely
successful, sort of the x86 of virtual machine designs, so even if it
changes massively
under the hood, as it does every couple of years, it doesn't make
sense to force the huge
ecosystem of tools generating bytecode to the JVM to have to get
updated all the time.
Accordingly, even more ambitious changes like invokedynamic support
are done in a way
that's easy to mesh into existing tooling, not to mention into the
existing security architecture.
To give you a current example: a separate invokedynamic bytecode as a
'goto $semi-random'
instruction would have been great fun for the verifier to deal with,
for example - the way it's done
in the Da Vinci VM now, is basically to introduce a 'flag' for the VM
to know when to treat an
invokeinterface instruction in a special way, without having to break
bytecode verification.
cheers,
dalibor topic
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
