Questions around Type Annotations for Inner Classes

[André Pankraz]

Hi,

yes thx for the hint. Didn't know this list and may be there are totally
different people in both lists. So bug reports here and conceptual
questions there.

Didn't find a discussion in the other list why "package. @Annotation
Typename" is used (I understand why "Outer. @Annotation Inner" is used).
And why the type path in bytecode is encoded left to right (outmost to
inner) and not the other way around.
After all...it's just something that appears strange to me and where I
wished for an explanation, but can sleep without it. ;)
If I'm the single person that has problems with this, it's not important.

Cheers,
André


2014-02-10 20:50 GMT+01:00 Alex Buckley <alex.buckley at oracle.com>:

> Andre,
>
> Just FYI, this is the -dev list, for discussing the implementation of type
> annotations. The syntax of annotations on qualified types is really a
> question for type-annotations-spec-comments (the EG comments list). Also,
> there were discussions on the EG list about the "left to right" type_path
> format for qualified types.
>
> Alex
>
>
> On 2/8/2014 11:37 AM, André Pankraz wrote:
>
>> Hi,
>>
>> hmmm, repost-try...disappeared somehow. My next remark is more a
>> question and not really a bug report. Sry it's quite complex.
>>
>>
>> I understand how Arrays Type Annotations in Java and Bytecode work and I
>> have now some interpretation that works fine for me. The other stuff is
>> also quite clear.
>>
>> What I find totally unintutive is that
>>    @Notnull java.lang.Map
>> is not allowed and that I have to write
>>    java.lang. at Notnull Map
>>
>> Shure, we will use imports in such cases anyway, but I'm interested why
>> this is necessary? Nobody would guess this syntax, even if I know that I
>> have to write
>>    Map. at Notnull Entry<String, String> test;
>> for the inner type.
>>
>> I think the last syntax for inner types (which is fine) doesn't really
>> imply the other (for outest type with package-prefixes).
>>  From my experience, I'm not really very unflexible with such stuff -
>> all other new Java-syntax like lambdas etc. are totally fine with me,
>> but this immediately was really strange to me and I did it wrong
>> multiple times.
>>
>> Is there some reason for language/parser consistency that I don't see?
>>
>>
>>
>> Also I have a question about the presentation in bytecode for this inner
>> types. I know it's really hard to describe / to follow here.
>>
>> For array types I know, the Type Path kind of means that for each ARRAY
>> step, I just go into the component type of the current type context.
>> If I annotate an array type T[][][] without an ARRAY step into the
>> components, I just imply that the full dimension type T[][][] is meant.
>> If I encounter 3 ARRAY steps, I imply that I want to annotate the
>> innermost element type T and the resulting Java code is @A T[][][]. This
>> is consistent.
>>
>>
>> For inner types, if I annotate an inner class like T0.T1.T2 without a
>> Type Path with INNER steps, this means according to the spec: @A T0.T1.T2
>> If I have 2 INNER steps, then I get: T0.T1. at A T2
>>
>> This looks very strange to me. I would expect it exactly the other way
>> around and would think that type systems are not very happy with this
>> byte code encoding?!
>>
>> For me it would be more clear that if I have no given Type Path with
>> INNER and I add type annotation info to T0.T1.T2, then I would think
>> that this information belongs to the outmost (the real) type T2. The
>> other parts are just context.
>> If I have one INNER Type Path step, I would expcect the outer type T0.T1
>> should get this annotation etc.
>>
>>
>> So this all is more a question or request to have some reasoning behind
>> this.
>> May be there is a form of an interpretation or some constraints that
>> make this decissions transparent to Java users and document it somewhere?
>>
>> Sry if my terminology isn't exact in all parts, it's not my daily
>> business.
>>
>> Cheers,
>> André
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20140210/4634e538/attachment.html