This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
java/2423: false reporting of "Final variable initialization error" in constructor
- To: gcc-gnats at gcc dot gnu dot org
- Subject: java/2423: false reporting of "Final variable initialization error" in constructor
- From: sdlee at csis dot hku dot hk
- Date: 30 Mar 2001 02:58:07 -0000
- Reply-To: sdlee at csis dot hku dot hk
>Number: 2423
>Category: java
>Synopsis: false reporting of "Final variable initialization error" in constructor
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: rejects-legal
>Submitter-Id: net
>Arrival-Date: Thu Mar 29 19:36:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: sdlee@csis.hku.hk
>Release: gcc-20010320 snapshot
>Organization:
>Environment:
bash$ ~/y/bin/gcj -dumpmachine
i686-pc-linux-gnu
bash$ ~/y/bin/gcj -dumpversion
3.0
>Description:
Sun's javac (JDK version 1.3 for Linux/x86) and
IBM's jikes (Version 1.11, 10 Jan 2000)
both accept a constructor that contains
an execution path that does not initialize
all final variables, but exits by throwing an exception.
'gcj' does not accept it. The behaviour is the same whether
the thrown exception is checked or unchecked (or is an Error
rather than an Exception).
Compiling such a class with jikes and javac and then
compiling the resulting .class file with gcj results
in a native binary executable that seems to work correctly,
though.
>How-To-Repeat:
public class A {
public static void main(String[] a) {
new A().go();
}
private final boolean b;
private A() {
//b = true; // without this line, GCJ chokes!
throw new RuntimeException("Haha");
}
private void go() {
System.out.println("Hello!");
}
}
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: