Bytecode verifier

Andrew Haley aph@redhat.com
Mon Mar 29 19:21:00 GMT 2004


Ranjit Mathew writes:
 > >  > It is a Good Thing, IMHO, but I'm just confused by
 > >  > how you did it, especially after I remember us being
 > >  > reticent to even use libiberty in libgcj and by the
 > >  > order in which I see different parts of the GCC tree being
 > >  > configured and built (libiberty, front-ends, libraries).
 > > 
 > > libiberty is GPL; libgcj is GPL+exception.  There's no reason to to
 > > link GPL code with GPL+exception code.
 > 
 > If the front-end bits provide the API for the verifier
 > and libgcj uses it, it has to link to GPL-ed code, no?

That's a big "if".

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

I don't see the problem.  How we organize our configury is a disjoint
problem from the licence applied to a given file.  Some of the files
in the gcc directory are GPL + exception.  I can see no overwhelming
reason why an interface to a verifier should not be GPL + exception,
no matter where it is.

 > BTW, as has been pointed earlier, Sun's JVM doesn't
 > even bother verifying classes loaded locally unless
 > you use the "-verify" flag, so maybe even we ought
 > not to bother by default.

Interesting.

Andrew.



More information about the Java mailing list