Bytecode verifier

Tom Tromey
Tue Mar 30 15:09:00 GMT 2004

>>>>> "Ranjit" == Ranjit Mathew <> writes:

>> libiberty is GPL; libgcj is GPL+exception.  There's no reason to to
>> link GPL code with GPL+exception code.

Ranjit> If the front-end bits provide the API for the verifier
Ranjit> and libgcj uses it, it has to link to GPL-ed code, no?

Ranjit> If libgcj provides the API for the verifier and the
Ranjit> front-end uses it, the configury and the build process
Ranjit> should get really weird.

At the moment the API is just a single .h file declaring all the
functions and types used by the verifier that are provided by the
enclosing environment.  We can put the libgcj version of this file
under the same copyright as the rest of libgcj.  There's really no
problem here.

Ranjit> BTW, as has been pointed earlier, Sun's JVM doesn't
Ranjit> even bother verifying classes loaded locally unless
Ranjit> you use the "-verify" flag, so maybe even we ought
Ranjit> not to bother by default. A runtime flag/environment-
Ranjit> variable/property should at least help in not having
Ranjit> to comment out the verifier call and recompiling
Ranjit> libgcj in order to get an application working.

Yeah.  Could you file this in bugzilla as a feature request?
I thought we already had it in there, but I don't see it.


More information about the Java mailing list