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: making static linkage useful (oh the horror!)


Adam Megacz writes:
 > 
 > Andrew Haley <aph@redhat.com> writes:
 > > > The -fno-bounds-check option "breaks" gcj by deviating from the JLS,
 > > > yet we still allow it.
 > 
 > > Uh, sure.  I don't think there is any way to implement
 > > -fno-bounds-check without deviating from the JLS.
 > 
 > I can prove that there is no way to implement static linkage without
 > deviating from the JLS.

We've already established that.

 > Now is it okay to include static linkage?

We already include it.

 > > > Why is -fno-bounds-check okay, but not-fully-JLS-compliant
 > > > static linkage isn't?
 > 
 > > Well, -fno-bounds-check doesn't disable any APIs.
 > 
 > Sure it does; any APIs that explicitly depend on
 > ArrayBoundsCheckException will break.  Specifically, JVM security
 > goes straight out the window, so java.lang.Security is completely
 > pointless (hence, "broken").

-fno-bounds-check breaks the JLS, but we already know that.  I don't
see the point of arguing about this, since we agree.

 > > Besides, -fno-bounds-check is IMO not okay: AFAIK it's really a
 > > kludge because we don't eliminate array bounds checks in the
 > > compiler.  We should fix that.
 > 
 > Huh?  How could you eliminate bounds checks without deviating from the
 > JLS?  The JLS *requires* bounds checks.

Not at all; it requires programs to behave _as if_ bounds checking
were done.  The better JITs around eliminate these bounds checks
whenever they can, but gcj doesn't and hence -fno-bounds-check is a
win.

 > Your argument that "X deviates from the JLS therefore we must not
 > offer X as an off-by-default option" is completely bogus.

I have never made any such argument.

My argument has never been that we must not provide static linkage,
because we already do.  However, the current "support" for static
linkage breaks a great deal of the API.  This is bad.

Also, it breaks the API in a bunch of places and we don't even have a
list of them.  

I've been thinking about a way to make things a little more sane.
What we might be able to do is, when linking, detect a reference to
any of the APIs that depend on dynamic libraries and issue a warning.
This would solve the support problem in most cases.  At the moment I'm
not quite sure how to do this.

Andrew.


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