JDK-4787017 : REGRESSION:javac doesn't compile files generated by jaxb-1.0-beta
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2002-12-02
  • Updated: 2003-01-22
  • Resolved: 2003-01-22
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
1.4.2 b14Fixed
Related Reports
Relates :  
JDK-6541876 - "Enclosing Instance" error new in 1.6
Description
###@###.### 2002-12-02

J2SE Version (please include all output from java -version flag):
  java version "1.4.2-beta"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b08)
  Java HotSpot(TM) Client VM (build 1.4.2-beta-b08, mixed mode)

Does this problem occur on J2SE 1.3 or 1.4?  Yes / No (pick one)
  No; works fine with 1.4.1_01

Operating System Configuration Information (be specific):
  Linux *** 2.4.19-xfs #5 SMP i686 GNU/Linux

Bug Description:
 javac doesn't compile files generated by jaxb-1.0-beta (see below)

Steps to Reproduce (be specific):
  1. Get jaxb-1.0-beta
  2. Compile the XSD file (attached to this e-mail)
  3. Try to compile one of the generated files with J2SDK 1.4.2-beta-b08:
     javac -classpath xerces2/xercesImpl.jar:jaxb-1.0/lib/jaxp-api.jar:jaxb-1.0/lib/jaxb-api.jar:jaxb-1.0/lib/sax.jar:jaxb-1.0/lib/dom.jar:jaxb-1.0/lib/jax-qname.jar:jaxb-1.0/lib/jaxb-ri.jar:jaxb-1.0/lib/jaxb-xjc.jar:jaxb-1.0/lib/jaxb-libs.jar:jaxb-1.0/lib/xercesImpl.jar:jaxb-1.0/lib/ant.jar -d xsd -sourcepath xsd xsd/com/pironet/pbng/docstore/publicxsd/hierarchies/impl/FilesystemlikefoldersImpl.java

--> Fails with:
pl.java:110: an enclosing instance that contains com.pironet.pbng.docstore.publicxsd.hierarchies.impl.FilesystemlikefoldersTypeImpl.Unmarshaller is required                       
spawnSuperClassFromLeaveElement((new com.pironet.pbng.docstore.publicxsd.hierarchies.impl.FilesystemlikefoldersTypeImpl.Unmarshaller(context)), 2, ___uri, ___local);
                                                         ^
1 error


javac from J2SDK 1.4.1-01 works fine


Test program:(java-4787017.zip)
---------------
  The Java class files are generated by the Sun JAXB-1.0 Beta reference 
implementation's XML schema compiler(xjc) and can not be modified by
the CAP member to workaround the problem.

Steps to reproduce the problem:
--------------------------------
 - unzip java-4787017.zip
 - chmod 755 c.sh; rm -rf c/*
 - export JAVA_HOME=/usr/j2sdk1.4.1-01
 - export PATH=$JAVA_HOME/bin:$PATH
 - ./c.sh

By using 1.4.2 build08, you will get the following error message:

./jbug4787017/impl/TagmetaImpl.java:82: an enclosing instance that contains jbug4787017.impl.TagmetaTypeImpl.Unmarshaller is required
                        spawnSuperClassFromEnterElement((new jbug4787017.impl.TagmetaTypeImpl.Unmarshaller(context)), 2, ___uri, ___local, __atts);
                                                         ^
1 error
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis-beta FIXED IN: mantis-beta INTEGRATED IN: mantis-b14 mantis-beta
14-06-2004
EVALUATION Please attach a small, self-contained test case that illustrates the problem. In case it is the same as the following, I an enclosing a recent email exchange. We are currently reconsidering this compiler change, even though it was put in to make the compiler comply with the Java Language Specification. This is spec bug 4689050 and the relevant compiler changes are for bugs 4635044 and 4494653. ###@###.### 2002-12-02 > [...] we discovered what > appears to be a bug in the compiler on code that was supported in > earlier versions. Essentially, we can no longer create an inner > subclass of a parent's inner class with the same name. For example: > > > class A { > class Inner {} > } > > class B extends A { > class Inner extends A.Inner { > public Inner() { > super(); > } > } > } > > > Granted, this is not the best style (the inner classes should really > have different names), but it seems to be semantically correct. This > code compiles with the traditional JDK (through 1.4.1) [...] > but not with [1.4.2]. In [1.4.2], we get the following error: > > > jsr14-bug.java:22: an enclosing instance that contains A.Inner is required > super(); > ^ > 1 error > > > Note that B.Inner does have an enclosing instance of A (since B > extends A). Also, B.Inner itself is an instance of A.Inner, so > technically, the error message is incorrect-- there is an enclosing > instance (B) that contains A.Inner. You are seeing a compiler bug fix that will go into javac in 1.4.2. The code is in fact in error, but the reason is a bit subtle. The diagnositc is correct, and very carefully worded to describe the problem. The diagnositc doesn't say that you need an enclosing instance of type A (which you do have - well, you have an enclosing instance of a class derived from A), what it says is that you need an enclosing instance that contains A.Inner (which you don't have). While it's true that the enclosing instance (B) contains B.Inner, it does NOT contain A.Inner. According to JLS (second edition, page 195, about 1/3 of the way down the page) in this case It is a compile-time error if [the superclass] is not a member of a lexically enclosing class. The two lexically enclosing classes in your example are B.Inner and B. The superclass, A.Inner, isn't a member of B.Inner. A.Inner also isn't a member of B because it is HIDDEN in B by the declaration of B.Inner. That is a consequence of 6.4.2 ("The Members of a Class Type"). 6.4.2 states that The members of a class type are all of the following: * Members inherited from its direct superclass (?8.1.3), if it has one (the class Object has no direct superclass) * Members inherited from any direct superinterfaces (?8.1.4) * Members declared in the body of the class (?8.1.5) The first bullet is the one of interest, but the previous sentence says Members are either declared in the type, or inherited because they are accessible members of a superclass or superinterface which are neither private nor hidden nor overridden (?8.4.6). And 8.5 says If the class declares a member type with a certain name, then the declaration of that type is said to hide any and all accessible declarations of member types with the same name in superclasses and superinterfaces of the class. So, you see, your program is required to be diagnosed as an error! Perhaps the diagnostic should more precisely have been worded as "A.Inner must be a member of some enclosing instance". It was a bug that previous versions of javac failed to diagnose this. You can fix it as follows: class A { class Inner {} } class B extends A { class Inner extends A.Inner { public Inner() { ((A)B.this).super(); } } } This ugliness is the price you pay for hiding type names. ###@###.### 2002-12-02 Yes, I see the problem. The code generated by jaxb does not comply with the Java Language Specification in precisely the area where the compiler was fixed. The applicable text is on JLS2 page 333, second bullet from the bottom ("Otherwise, a compile-time error occurs."). ###@###.### 2002-12-03
03-12-2002