This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
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.