I see, thanks very much dalibor, I understand what you mean. And you were correct in saying that my question was more around making sure code execution is maintained between JVM updates. Which, as you say, is trivial.
On Oct 7, 8:48 pm, robilad <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
