Community
Participate
Working Groups
These structures exist to reduce the number of secondary errors, but they don't provide enough information. For example, if a type defines twice the same type variable, then the corresponding problem type won't be generic at all. The consequence is that code that is using this class as a generic class will also be broken.
Remaining generic is a must fix
I tried with latest and the following code works ok in Eclipse, but javac cannot use the Y.class we generate. I believe this is coming from the duplicate type variable in the generic signature. public class X { public static void main(String[] args) { System.out.println(new Y<String, String>()); } } public class Y<T, T> {} We report the error and we compile X without a secondary error. But javac cannot compile X using Y.class. An exception has occurred in the compiler (1.5.0_03). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking t port. Thank you. java.lang.NullPointerException at com.sun.tools.javac.code.Types$SubstFcn.subst(Types.java:2057) at com.sun.tools.javac.code.Types.subst(Types.java:2046) at com.sun.tools.javac.code.Types.substBound(Types.java:2195) at com.sun.tools.javac.comp.Check$Validator.visitTypeApply(Check.java:764) at com.sun.tools.javac.tree.Tree$TypeApply.accept(Tree.java:1064) at com.sun.tools.javac.comp.Check.validate(Check.java:719) at com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:1228) at com.sun.tools.javac.tree.Tree$NewClass.accept(Tree.java:845) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:280) at com.sun.tools.javac.comp.Attr.attribArgs(Attr.java:339) at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1105) at com.sun.tools.javac.tree.Tree$Apply.accept(Tree.java:819) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:280) at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:302) at com.sun.tools.javac.comp.Attr.visitExec(Attr.java:896) at com.sun.tools.javac.tree.Tree$Exec.accept(Tree.java:734) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:280) at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:315) at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:331) at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:599) at com.sun.tools.javac.tree.Tree$Block.accept(Tree.java:540) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:280) at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:315) at com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:532) at com.sun.tools.javac.tree.Tree$MethodDef.accept(Tree.java:482) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:280) at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:315) at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:2473) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2406) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2355) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:444) at com.sun.tools.javac.main.Main.compile(Main.java:592) at com.sun.tools.javac.main.Main.compile(Main.java:544) at com.sun.tools.javac.Main.compile(Main.java:67) at com.sun.tools.javac.Main.main(Main.java:52) I don't know how we can fix the generated class file and keep it ok to compile against.
This could be doable only if the generic information can be resolved.
I believe the current support is ok. We generate a signature attribute if the generic signature is available. There is no more we can do.
I concur
