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!)
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. Figuring out which classes will be loaded by
Class.forName() is provably equivalent to the halting problem, and
therefore impossible to implement with any computer currently
available to humans.
Now is it okay to include static linkage?
> > 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").
> 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.
Your argument that "X deviates from the JLS therefore we must not
offer X as an off-by-default option" is completely bogus.
- a