By: Gabriele Svelto (gabriele.svelto.delete@this.gmail.com), October 27, 2006 12:29 am
Room: Moderated Discussions
Tzvetan Mikov (tzvetanmi@yahoo.com) on 10/26/06 wrote:
---------------------------
>In the same way in a SAFE2 language, the language is the abstract "CPU instruction
>set" and nothing that isn't defined in the instruction set can ever occur, no matter
>what you do from within the language.
You hit the nail on the head. Java is SAFE2 language in the sense that nothing you can do can break the rules specified in the VM spec. You can write code that breaks the rules but then a conforming VM won't run it as the code won't pass the verification stage. Once the code has been verified by the VM you are 100% sure that nothing not intended in the spec will happen. That's why Java is becoming very popular in embedded environments, it guarantees that no matter what bugs you introduce in the code you won't be able to compromise the functionality of the VM or of the other applications or the OS. However Java doesn't prevents you from doing stupid things which conform with the spec. Accessing the same stuff from different threads without locking is certainly going to give you bizarre bugs or weird results but it will never ever crash the VM nor compromise its state. BTW not using synchronization in Java is extraordinarily stupid considering how easy it is compared to lower level languages.
BTW this thread made me think about the terminology that compiler/VM guys use and which is unnatural to other people (to say the least). For example did you know that the user application is known as the 'mutator' by garbage-collection people?
Gabriele
---------------------------
>In the same way in a SAFE2 language, the language is the abstract "CPU instruction
>set" and nothing that isn't defined in the instruction set can ever occur, no matter
>what you do from within the language.
You hit the nail on the head. Java is SAFE2 language in the sense that nothing you can do can break the rules specified in the VM spec. You can write code that breaks the rules but then a conforming VM won't run it as the code won't pass the verification stage. Once the code has been verified by the VM you are 100% sure that nothing not intended in the spec will happen. That's why Java is becoming very popular in embedded environments, it guarantees that no matter what bugs you introduce in the code you won't be able to compromise the functionality of the VM or of the other applications or the OS. However Java doesn't prevents you from doing stupid things which conform with the spec. Accessing the same stuff from different threads without locking is certainly going to give you bizarre bugs or weird results but it will never ever crash the VM nor compromise its state. BTW not using synchronization in Java is extraordinarily stupid considering how easy it is compared to lower level languages.
BTW this thread made me think about the terminology that compiler/VM guys use and which is unnatural to other people (to say the least). For example did you know that the user application is known as the 'mutator' by garbage-collection people?
Gabriele