Insights on Java Byte Code Verifier

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?
Ask It in The Java Forum

Java Books
Java Certification, Programming, JavaBean and Object Oriented Reference Books

Return to : Java Programming Hints and Tips

All the site contents are Copyright © www.erpgreat.com and the content authors. All rights reserved.
All product names are trademarks of their respective companies.
The site www.erpgreat.com is not affiliated with or endorsed by any company listed at this site.
Every effort is made to ensure the content integrity.  Information used on this site is at your own risk.
 The content on this site may not be reproduced or redistributed without the express written permission of
www.erpgreat.com or the content authors.