JDK-5035300 : Rmic reports error when switching to 1.4.2_03
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2004-04-21
  • Updated: 2004-06-02
  • Resolved: 2004-06-02
Related Reports
Duplicate :  
Relates :  
Description

Name: gm110360			Date: 04/21/2004


FULL PRODUCT VERSION :
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Using Ant version 1.3 compiled on March 2 2001

A DESCRIPTION OF THE PROBLEM :
Switched to the newest J2SDK and our project does not compile any longer with the instruction to bug report that problem (and a full stacktrace)

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A fully successful compilation, as in the 1.3 release
ACTUAL -
Stacktrace saying checkOverride() synthetic

ERROR MESSAGES/STACK TRACES THAT OCCUR :
sun.tools.java.CompilerError: checkOverride() synthetic
        at sun.tools.java.MemberDefinition.checkOverride(MemberDefinition.java:560)
        at sun.tools.java.MemberDefinition.checkOverride(MemberDefinition.java:526)
        at sun.tools.java.ClassDefinition.collectOneClass(ClassDefinition.java:1297)
        at sun.tools.java.ClassDefinition.collectInheritedMethods(ClassDefinition.java:1501)
        at sun.tools.java.BinaryClass.basicCheck(BinaryClass.java:73)
        at sun.tools.java.ClassDeclaration.getClassDefinition(ClassDeclaration.java:130)
        at sun.tools.java.BinaryClass.initInnerClasses(BinaryClass.java:344)
        at sun.tools.java.BinaryClass.loadNested(BinaryClass.java:221)
        at sun.tools.java.BinaryClass.loadNested(BinaryClass.java:203)
        at sun.tools.javac.BatchEnvironment.loadDefinition(BatchEnvironment.java:803)
        at sun.tools.java.ClassDeclaration.getClassDefinition(ClassDeclaration.java:120)
        at sun.tools.java.BinaryClass.initInnerClasses(BinaryClass.java:352)
        at sun.tools.java.BinaryClass.loadNested(BinaryClass.java:221)
        at sun.tools.java.BinaryClass.loadNested(BinaryClass.java:203)
        at sun.tools.javac.BatchEnvironment.loadDefinition(BatchEnvironment.java:803)
        at sun.tools.java.ClassDeclaration.getClassDefinition(ClassDeclaration.java:120)
        at sun.rmi.rmic.Main.doCompile(Main.java:523)
        at sun.rmi.rmic.Main.compile(Main.java:130)
        at org.apache.tools.ant.taskdefs.Rmic.execute(Rmic.java:295)
        at org.apache.tools.ant.Target.execute(Target.java:153)
        at org.apache.tools.ant.Project.runTarget(Project.java:898)
        at org.apache.tools.ant.Project.executeTarget(Project.java:536)
        at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:213)
        at org.apache.tools.ant.Target.execute(Target.java:153)
        at org.apache.tools.ant.Project.runTarget(Project.java:898)
        at org.apache.tools.ant.Project.executeTarget(Project.java:536)
        at org.apache.tools.ant.Project.executeTargets(Project.java:510)
        at org.apache.tools.ant.Main.runBuild(Main.java:421)
        at org.apache.tools.ant.Main.main(Main.java:149)
     [rmic] error: An error has occurred in the compiler; please file a bug report (http://java.sun.com/cgi-bin/bugreport.cgi).

REPRODUCIBILITY :
This bug can be reproduced always.
(Incident Review ID: 231185) 
======================================================================

Comments
WORK AROUND See Evaluation. ###@###.### 2004-06-02
02-06-2004

EVALUATION This exception seems very similar to that which occurred because of 4811083. The failure of 4811083, however, was exposed by the presence of "bridge methods", which get added according to JSR-14 (Generics) in Tiger (J2SE 1.5). I'm puzzled how this situation could occur with only classes generated by the J2SE 1.4.2 SDK javac, however-- causing this exception would seem to require classes generated by a Tiger Java language compiler or generated by some non-Java class file generator. Does the customer have a small test case that reproduces the failure? Can the customer confirm that no classes compiled by a Tiger version of javac (such as that from the 1.5.0-beta1 release) are being used when this failure occurs? Can the customer also say whether any classes are being used that were not complied by some valid (pre-Tiger) Java language compiler? (And if so, more details about such non-Java classes would be helpful.) [Given the fix for 4811083, I would presume that rmic in the Tiger SDK (such as in the 1.5.0-beta1 release) does not have this bug (although it would be useful if the customer could confirm this as well); therefore, the only question would be whether or not to do something about this in a 1.4.2_xx release.] ###@###.### 2004-04-21 Customer's test case requested. ###@###.### 2004-05-28 Given the customer's test case, I have reproduced this bug and identified the root cause. The assertion described in 4811083-- that a synthetic method must not override another method-- is indeed getting tripped up by a valid class file generated by the 1.4.2 javac (i.e. no generics). This situation occurs when the 1.4.2 javac is used with "-target 1.1". When "-target 1.1" is used, "miranda methods" are generated (more about them below) in order to work with buggy 1.1-era virtual machines. With the fix for 4175911 in 1.4.2, miranda methods are marked as synthetic (because they do not correspond to a declaration in the source file). By their nature, miranda methods always "override" (really, implement) a method delcared in an interface. Therefore, we have the possibilty of a synthetic method "overriding" another method, which trips up the assertion of 4811083. Miranda methods are added (with "-target 1.1") to an abstract class when that class inherits a method from a superinterface (but does not declare an overriding method or inherit such a method from a superclass). For example, wiht the following classes: interface I { void foo(); } abstract class C implements I { } With "-target 1.1", javac implicitly adds to C the declaration of a method public abstract void foo(); because certain old, 1.1-era VM implementations would not otherwise implement invocations on C.foo() correctly. ("If you don't have a method, one will be provided for you by the compiler...") A workaround for this bug, if "-target 1.1" must be used with javac in 1.4.2, would be to add explicit abstract method declarations to abstract classes where javac would otherwise implicitly add miranda methods. This bug essentially boils down to another reason why rmic's assertion that synthetic methods must not "override" other methods is an invalid assertion; hence, I am marking this bug as a duplicate of 4811083 (which is fixed in Tiger). ###@###.### 2004-06-02
02-06-2004