public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: ebb9@email.byu.edu To: gcc-gnats@gcc.gnu.org Subject: java/8830: Incorrect semantics for Foo.class Date: Thu, 05 Dec 2002 13:46:00 -0000 [thread overview] Message-ID: <20021205213737.15968.qmail@sources.redhat.com> (raw) >Number: 8830 >Category: java >Synopsis: Incorrect semantics for Foo.class >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Thu Dec 05 13:46:02 PST 2002 >Closed-Date: >Last-Modified: >Originator: Eric Blake >Release: 3.2 >Organization: >Environment: Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libgcj.spec rename spec lib to liborig Configured with: /netrel/src/gcc-3.2-3/configure --enable-languages=c,c++,f77,ja va --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --with out-included-gettext --enable-interpreter --disable-sjlj-exceptions --disable-ve rsion-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-pc -cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecd ir=/usr/sbin Thread model: posix gcc version 3.2 20020927 (prerelease) >Description: JLS 12.4.1 does not permit class literals to cause class initialization. GCJ, on the other hand, compiles them to initialize the underlying class, because of the specification of Class.forName(). Javac has always got this wrong, but it was recently corrected in jikes 1.17. This is also a test in the Jacks test suite. The sample program below should never initialize Sub, since the only use of Sub is via a class literal (and not a static field, method, or constructor). Therefore, i should still be 1, not 2, when the println is executed. Also, gcj does not cache the result when compiled to bytecode, when both javac and jikes do. Caching is useful, because the reflection overhead of Class.forName is expensive. (Note that any implementation of class literals that does not match Sun's will break serialization compatibility, since adding or removing cache variables, or changing parameters to class$(), will affect the UID. But I've already pointed this out as the reason why all classes in libgcj should explicitly state their serialVersionUID. Also note that Sun has proposed a VM extension in JDK 1.5, which will allow 'ldc CONSTANT_Class' to resolve a class literal, rather than the current hack of invisibly calling Class.forName()). >How-To-Repeat: $ cat Foo.java class Foo { static int i = 1; static void m(Class c) { System.out.println(i); } public static void main(String[] args) { m(Sub.class); } } class Sub extends Foo { static int j = i = 1; // should not execute } $ gcj -C Foo.java $ java Foo 2 $ jikes Foo.java $ java Foo 1 >Fix: Currently, gcj emits: private static Class class$(String s) { try { return Class.forName(s); } catch (ClassNotFoundException e) { throw new NoClassDefFoundError(e.getMessage()); } } and translates Sub.class to class$("Sub") Jikes emits this: static Class class$Sub; static Class class$(String s, boolean arraytype) { try { Class c = Class.forName(s); if (! arraytype) c = c.getComponentType(); } catch (ClassNotFoundException e) { throw (Error) new NoClassDefFoundError().initCause(e); } } and translates Sub.class to: (class$Sub == null ? class$Sub = class$("LSub;", false) : class$Sub) >Release-Note: >Audit-Trail: >Unformatted:
reply other threads:[~2002-12-05 21:46 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20021205213737.15968.qmail@sources.redhat.com \ --to=ebb9@email.byu.edu \ --cc=gcc-gnats@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).