JDK-4302890 : declared/synthetic class name conflict undetected
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.3.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_7
  • CPU: generic,sparc
  • Submitted: 2000-01-06
  • Updated: 2001-10-15
  • Resolved: 2000-12-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other
1.3.1 ladybirdFixed 1.4.0Fixed
Related Reports
Duplicate :  
Relates :  
Description
If you declare the classes in this order:

class HiddenFieldBug$Inner {
    int j = 2;
}

class HiddenFieldBug {
    class Inner {
	int i = 1;
    }
}

only one class file for HiddenFieldBug$Inner is generated, corresponding to the
second declaration of HiddenFieldBug$Inner. 

If you declare the classes in the reverse order, a duplicate class declaration
is reported.

$ javac -verbose HiddenFieldBug.java
HiddenFieldBug.java:11: duplicate class: HiddenFieldBug.Inner
class HiddenFieldBug$Inner {
^
1 error

iris.garcia@eng 2000-01-05

A similar problem ocurs in this example:

public class Example {

  Example() {
    class Inner{}
  }

  Object anon = new Object() {
    class Inner{}
  };

}

The classfiles Example.class, Example$1.class, and Example$1$Inner.class
are generated, with the latter corresponding to the inner class of the
anonymous class Example$1.  No code is generated for the inner class of
Example itself.  Reversing the order of the declarations of anon and the
constructor Example, however, produces an additional class file Example$2$Inner.class as expected.  It looks as if the name for the inner
class of the anonymous class is chosen without checking first for an
exisiting class.

This example is taken from 4196251, however, this is a different issue.

william.maddox@Eng 2000-01-13

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: ladybird merlin FIXED IN: ladybird merlin INTEGRATED IN: ladybird merlin VERIFIED IN: merlin-beta3
14-06-2004

SUGGESTED FIX The following fix to src/share/javac/com/sun/tools/javac/v8/comp/Enter.java only detects the conflict. There is the underlying language problem that it is allowed by the language but disallowed by the class file spec. ------- Enter.java ------- *** /tmp/diVaGCY Thu Nov 9 10:00:07 2000 --- Enter.java Thu Nov 9 08:33:25 2000 *************** *** 495,505 **** log.error(tree.pos, "class.public.should.be.in.file", tree.name.toJava()); } - if (chk.compiled.get(c.flatname) != null) { - log.error(tree.pos, "duplicate.class", c.fullname.toJava()); - result = null; - return; - } } else { if (tree.name.len != 0 && !checkUniqueClassName(tree.pos, tree.name, enclScope)) { --- 495,500 ---- *************** *** 522,527 **** --- 517,527 ---- //if (c.name.len != 0) checkTransparent(tree.pos, c, env); } // Enter class into `compiled' table and enclosing scope. + if (chk.compiled.get(c.flatname) != null) { + log.error(tree.pos, "duplicate.class", c.fullname.toJava()); + result = null; + return; + } chk.compiled.put(c.flatname, c); enclScope.enter(c); tree.sym = c;
11-06-2004

PUBLIC COMMENTS ..
10-06-2004

EVALUATION There is a tension between the requirement that synthetic names should not appear in the Java namespace (see 4030356) and the fact that certain naming conventions for the underlying class files and their flat class names are fixed by the specification. We need to come up with some reasonably sensible story here and implement it correctly. william.maddox@eng 2000-01-05 These cases are now rejected, which is preferable to generating incorrect code, but is still not correct. (1.4.0beta-b20) william.maddox@Eng 2000-06-26 I am restricting action on this bug to detecting and reporting the conflict. I have created a separate bug, 4387679, to represent the problem that something allowed in the langiage is disallowed in the VM spec. neal.gafter@Eng 2000-11-09
09-11-2000