Dash Abhisek wrote:
1>Why earlier versions of java were not type safe.
Where did you get this idea from? Java has the same level of "type safety" -- which really has nothing to do with class file versions -- that it's always had.
2>I have a concept [might be a misconcept also] that byte code verifier verifies the byte code which is loaded at run time with the byte code used while compile time to ensure same version of the class is loaded. Am I right?
No, not at all. You can upgrade some class files in an application, but not others, if that's what you want to do. Signed/sealed JAR files can be used to verify particular versions of classes, but this is very rarely used, and has nothing to do with the verifier. I think this is the big misunderstanding here.
3>If the bytecode were generated by the Java compiler, then the bytecode verifier is doing a job that is pretty useless. I didn't get this line
The verifier's job is basically to check that the bytecode isn't going to reference a nonexistent piece of data, or access an uninitialized variable, or perform some other illegal operation. A valid Java compiler won't generate code that does any of these things, so in general the verifier is just redundant. It's good for checking bytecode that comes from other places, though.
4>"And doing some complicated state checking thingy to make sure all possible paths are accounted for" please elabaorate a bit on "all possible paths are accounted for". What you mean by all possible paths.
All the possible execution paths through the code: i.e., what happens if each branch of an "if" is taken.
