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