• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Insights on Java byte code verifier

 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,

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 and If I am wrong please rectify me.

Thanks in advance,
Abhisek
 
author
Posts: 23923
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Henry
 
Dash Abhisek
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Henry,
Can you please simplify a bit I am new to this that is why I am unable to get most part of it I got byte code verifiers were there from the very begining from your reply but I am still have the following doubts:-
1>Why earlier versions of java were not type safe.

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?

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

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.


Thanks for the help and sorry for the trouble . I really want to know this topic inside out.Please help.

 
author and iconoclast
Posts: 24204
44
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

 
Dash Abhisek
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for correcting me
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic