This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bytecode verifier


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]