• 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:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • 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: 23949
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: 24207
46
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
 
Won't you be my neighbor? - Fred Rogers. tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic