Some smallish comments on the current version of the spec.

[Reinier Zwitserloot]

A spec is posted for 3 months and it's too late for further commentary? I
feel like I'm in a Douglas Adams sketch.

I get the feeling 'too late' would have been the answer if I posted these
comments 5 minutes after this list was created; the very first post
explains how lots had already been done.

It's language design. Specs cannot change (easily). Surely "Do it right"
wins over "release quickly". This spec is riddled with concessions in the
interest of speed-of-release. It would be nice if the spec included a
section explaining what's on fire, because this spec does not strike me as
something that needs to be pushed out, half-baked.

Between this and my earlier commentary on how it is not neccessary to
burden the language with boilerplatey workarounds -forever- (containers),
'half-baked' seems appropriate.

 --Reinier Zwitserloot



On Tue, Nov 27, 2012 at 1:24 AM, Alex Buckley <alex.buckley at oracle.com>wrote:

> On 11/26/2012 1:55 PM, Reinier Zwitserloot wrote:
>
>> "@ContainerFor supports the java SE platform reflection…" - This paragraph
>> seems to make the point that it is important to differentiate
>> @FooContainer({@Foo(1), @Foo(2)}) from just @Foo(1) @Foo(2). Why is this
>> relevant? Also, later on, the examples of how JDK8 answers
>> .get(Declared)Annotation queries indicates that differentiating these two
>> cases in not actually important. That leaves the question of: Why is
>> @ContainerFor needed in the first place?
>>
>
> This was discussed in August in the list's very first thread.
>
>
>  "@ContainerFor" itself: While the stated aim is to be as compatible with
>> existing containers as possible, there are now 2 restrictions:
>>
>> * The container method must be "value()".
>> * All other methods must have a default.
>>
>> There are also many DRY violations: There's both @ContainerFor and
>> @ContainedBy, _AND_ in the container annotation, the base type is
>> repeated.
>> At the very least, it is possible to eliminate both the value()
>> restriction
>> and one repetition of the base type by getting rid of @ContainerFor and
>> introducing the @Container marker annotation.
>>
>
> This is a reasonable suggestion, though probably too late.
>
> Alex
>