By default, the Verifier is disabled on .Net and Java

[michaelslists at gmail.com (Michael Silk)]

On 5/4/06, Dinis Cruz <dinis at ddplus.net> wrote:
> Wall, Kevin wrote:
>
> > Also, from the results of your test, it seems to indicate that SOME TYPE
> > of verification is taking place, but if all you did was change a few
> > ARBITRARY bytes in the .class file, I don't think that proves the
> > byte code verifier is being being run in it's entirety.
> I agree with this analysis and think that the error on David's test was
> caused by a malformed bytecode instruction
> > It's entirely possibly that the (new 1.5) default just does some
> > surface level of byte code verification (e.g., verify that everything
> > is legal "op codes" / byte code)
> Well, some level of verification (or bytecode check) must always occur
> during the conversion from bytecode to native code (but this has nothing
> to do with type safety)
> > before HotSpot starts crunching
> > on it and that this works differently if either the '-verify' or
> > '-noverify' flags are used. E.g., suppose that '-verify' flag, does
> > some deeper-level analysis, such as checks to ensure type safety, etc,
> > whereas the '-noverify' doesn't even validate the byte codes are
> > legal op codes or that the .class file has a legal format. This might
> > even make sense because checking for valid file format and valid
> > Java "op codes" ought to be fairly "cheap" checks compared to the
> > deeper analysis required for things like type safety.
> I am a little bit confused here, isn't Java an open platform and almost
> Open Source?

The source for the j2se sdk is available (i.e. all the classes) and
the source for the runtime is available as well, but under a
different, special license.


> If so, shouldn't issues like this be quite well documented?

Actually, the verification process is documented here:
 http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#88597

-- Michael