On the impl of AnnotatedType
Joel Borggrén-Franck
joel.franck at oracle.com
Fri Jan 25 00:02:56 PST 2013
Hi,
On 25 jan 2013, at 04:25, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> My enthusiasm for the anon subtype approach is rapidly diminishing.
>
> A scan of the classes reveals 28 subtypes of Type, which either require a corresponding anon subtype or a sufficiently good analysis to determine why such a subtype is not required. Of these 28 types, 8 are already anon subtypes, dealing with const values, varargs etc.
>
> The following classes are all subtypes of com.sun.tools.javac.code.Type:
>
> build/classes/com/sun/tools/javac/code/Type$AnnotatedType.class
> build/classes/com/sun/tools/javac/code/Type$MethodType.class
> build/classes/com/sun/tools/javac/code/Type$ArrayType.class
> build/classes/com/sun/tools/javac/code/Symtab$3.class
> build/classes/com/sun/tools/javac/code/Type$IntersectionClassType.class
> build/classes/com/sun/tools/javac/code/Type$WildcardType.class
> build/classes/com/sun/tools/javac/code/Type$1.class
> build/classes/com/sun/tools/javac/code/Type$JCNoType.class
> build/classes/com/sun/tools/javac/code/Type$ErasedClassType.class
> build/classes/com/sun/tools/javac/code/Type$BottomType.class
> build/classes/com/sun/tools/javac/code/Type$UnionClassType.class
> build/classes/com/sun/tools/javac/code/Type$ForAll.class
> build/classes/com/sun/tools/javac/code/Type$ArrayType$1.class
> build/classes/com/sun/tools/javac/code/Type$UndetVar.class
> build/classes/com/sun/tools/javac/code/Type$PackageType.class
> build/classes/com/sun/tools/javac/code/Type$ErrorType.class
> build/classes/com/sun/tools/javac/code/Type$TypeVar.class
> build/classes/com/sun/tools/javac/code/Type$ClassType$1.class
> build/classes/com/sun/tools/javac/code/Type$DelegatedType.class
> build/classes/com/sun/tools/javac/code/Type$ClassType.class
> build/classes/com/sun/tools/javac/code/Type.class
> build/classes/com/sun/tools/javac/code/Type$CapturedType.class
> build/classes/com/sun/tools/javac/comp/MemberEnter$Synthesizer$2.class
> build/classes/com/sun/tools/javac/comp/MemberEnter$7.class
> build/classes/com/sun/tools/javac/comp/MemberEnter$Synthesizer$1.class
> build/classes/com/sun/tools/javac/comp/DeferredAttr$DeferredType.class
> build/classes/com/sun/tools/javac/jvm/ClassReader$1.class
> build/classes/com/sun/tools/javac/jvm/UninitializedType.class
>
> Yesterday, Joel wrote:
>> - The reason I want to move from the delegation model is that I need to further subdivide AnnotatedType into AnnotatedTypeVariable, AnnotatedWildcardType, AnnotatedParameterizedType and AnnotatedArrayType. While you can have AnnotatedType implement the union of all the functionality of the above and do dispatching this feels very brittle. If we move to a subtype model instead it should be easy and type-safe to provide the functionality in the subclasses where we know for a fact that the base type is for example a WildcardType.
> So, Joel, 4 named subtypes vs 28 anon subtypes …
>
Here is a count of "instanceof [A-Za-z]*Type" per file:
src/share/classes/com/sun/tools/classfile/TypeAnnotation.java:1
src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java:2
src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java:2
src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java:1
src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java:5
src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java:6
src/share/classes/com/sun/tools/javac/code/Symbol.java:2
src/share/classes/com/sun/tools/javac/code/Type.java:1
src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java:1
src/share/classes/com/sun/tools/javac/code/Types.java:2
src/share/classes/com/sun/tools/javac/comp/Check.java:2
src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java:1
src/share/classes/com/sun/tools/javac/jvm/ClassFile.java:1
src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java:3
src/share/classes/com/sun/tools/javac/jvm/Code.java:5
src/share/classes/com/sun/tools/javac/jvm/Pool.java:3
src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java:2
src/share/classes/com/sun/tools/javac/model/JavacTypes.java:1
src/share/classes/com/sun/tools/javac/parser/JavacParser.java:1
src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java:1
src/share/classes/com/sun/tools/javac/tree/Pretty.java:3
src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java:1
src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java:2
src/share/classes/com/sun/tools/javadoc/ParameterImpl.java:1
src/share/classes/com/sun/tools/javap/ClassWriter.java:1
So we have a non-trivial job of checking previous code either way i suppose. Don't get me wrong, I'm fine either way, my uninformed guess is/was that anon subtypes are "better" javac style but it isn't a strong preference.
In any case at least we should move as much as possible down from code.AnnotatedType and put in the 4 different code.Annotated*Type subclasses.
I'll follow up on the model design in a different mail.
cheers
/Joel
More information about the type-annotations-dev
mailing list