Future of 'type-annotations/type-annotations' forest

[Werner Dietl]

The stack trace that caused me to look at this, with code from
February 7, 2014, is below.
When I changed the reordering code back to the way it is in
type-annotations now, this exception went away.
The Checker Framework isn't doing funny things with the class files
and it isn't on this stack trace.
So to me it seems like that code is used, as it had direct impact on
this exception.

java.lang.ClassCastException:
com.sun.tools.javac.code.Symbol$MethodSymbol cannot be cast to
com.sun.tools.javac.util.Name
at com.sun.tools.javac.jvm.ClassReader.readName(ClassReader.java:565)
at com.sun.tools.javac.jvm.ClassReader.readCompoundAnnotation(ClassReader.java:1458)
at com.sun.tools.javac.jvm.ClassReader.readTypeAnnotation(ClassReader.java:1467)
at com.sun.tools.javac.jvm.ClassReader.attachTypeAnnotations(ClassReader.java:1415)
at com.sun.tools.javac.jvm.ClassReader$23.read(ClassReader.java:1180)
at com.sun.tools.javac.jvm.ClassReader.readAttrs(ClassReader.java:1330)
at com.sun.tools.javac.jvm.ClassReader.readMemberAttrs(ClassReader.java:1320)
at com.sun.tools.javac.jvm.ClassReader.readCode(ClassReader.java:1357)
at com.sun.tools.javac.jvm.ClassReader$3.read(ClassReader.java:954)
at com.sun.tools.javac.jvm.ClassReader.readAttrs(ClassReader.java:1330)
at com.sun.tools.javac.jvm.ClassReader.readMemberAttrs(ClassReader.java:1320)
at com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2088)
at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2296)
at com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2368)
at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2484)
at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2415)
at com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76)
at com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:234)
at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560)
at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024)
at com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2597)
at com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1862)
at com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2101)
at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3366)
at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3265)
at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:595)
at com.sun.tools.javac.comp.Attr.attribType(Attr.java:657)
at com.sun.tools.javac.comp.Attr.attribType(Attr.java:650)
at com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:835)
at com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:555)
at com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571)
at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:434)
at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:446)
at com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:525)
at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518)
at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:434)
at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1035)
at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560)
at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024)
at com.sun.tools.javac.comp.Enter.complete(Enter.java:495)
at com.sun.tools.javac.comp.Enter.main(Enter.java:473)
at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:981)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
at com.sun.tools.javac.main.Main.compile(Main.java:521)
at com.sun.tools.javac.main.Main.compile(Main.java:381)
at com.sun.tools.javac.main.Main.compile(Main.java:370)
at com.sun.tools.javac.main.Main.compile(Main.java:361)
at com.sun.tools.javac.Main.compile(Main.java:56)
at com.sun.tools.javac.Main.main(Main.java:42)

cu, WMD.


On Fri, May 9, 2014 at 9:18 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
> Werner,
>
> Potentially, yes. We're investigating.
>
> -- Jon
>
>
> On 05/09/2014 06:15 PM, Werner Dietl wrote:
>>
>> Eric,
>>
>> are you saying that that part of ClassReader is dead code that will
>> never run? Shouldn't it be removed then?
>>
>> cu, WMD.
>>
>> On Fri, May 9, 2014 at 8:42 PM, Eric McCorkle <eric.mccorkle at oracle.com>
>> wrote:
>>>
>>> On 05/08/14 16:57, Eric McCorkle wrote:
>>>
>>>> I am aware of the fix that was pushed into the type annotations forest.
>>>>   As we discussed when you developed the fix, I cannot push it into
>>>> jdk9-dev as-is, because the development practices of the langtools team
>>>> require that any changeset that introduces behavioral changes be
>>>> accompanied by a test.
>>>>
>>>> I will take care of the test this time, so that you can run checkers on
>>>> the contents of jdk9.  However, in the future, we ask that patches
>>>> submitted against jdk9 conform to the langtools group's development
>>>> practices.
>>>
>>> I looked into this more.  I'm not at all certain how you even get this
>>> problem to show up.  The only type annotations with local variable info
>>> are LOCAL_VARIABLE or RESOURCE_VARIABLE type annotations, both of which
>>> javac only ever generates on code attributes.  Also, javac never *reads*
>>> annotations on code attributes.  Therefore, it is not really possible to
>>> write a test.  It also suggests you're running into funny class files in
>>> checkers somehow.
>>>
>>> On the other hand, all this means we can give the bug the noreg-hard
>>> tag, and send it through the review process.  So it should be in jdk9
>>> soon.
>>
>>
>>
>



-- 
http://www.google.com/profiles/wdietl