|
As far as my understanding goes (related to classloaders) in earlier versions of java, the programmer can load a different version of a class at run time which is different from the versions thay have used while compiling. That is why java was not type safe but in new versions java has included byte code verifiers which disallows this and hence java is type safe. If I am right in saying so, please give some insights on what all things are checked by the byte code verifier basically I want to know how the byte code verifier works. The bytecode verifier is not new. It was included since the beginning. Even before Java was called Java. The purpose of the bytecode verifier is to check it to see that it conforms. Treating datatypes correctly. Treating methods (parameters and return) correctly. Treading code as code, and data as data. And doing some complicated state checking thingy to make sure all possible paths are accounted for. If the bytecode were generated by the Java compiler, then
the bytecode verifier is doing a job that is pretty useless. The compiler
should generate bytecode that conforms. The bytecode verifier is important
if (1) a bytecode assembler is used, (2) bytecode instrumentation is used,
or (3) bytecodes are changed on the fly across the network. With the bytecode
verifier, it should be theoretically impossible to do many of the "tricks"
that viruses use to bypass security -- and get the application out of the
sandbox.
Can you please simplify a bit I am new to this that is why I am unable to get most part of it. 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.
Do you have a Java Problem?
Java Books
Return to : Java Programming Hints and Tips All the site contents are Copyright © www.erpgreat.com
and the content authors. All rights reserved.
|