[type-annos-observers] Type annotations don't look very Java-like

[Michael Ernst]

Timo-

It's possible to write ugly code in any programming language, including 
Java 7 -- just like it is possible to write ugly prose or specious 
arguments in any natural language.  That says nothing about the language 
or its design.

You are incorrect in claiming that fully-qualified names are required for 
type annotations.  If your argument is predicated on this incorrect 
assumption (or on a bug in some specific tool), then your arguments are 
invalid.  Would it be possible to base a discussion on the specification 
(or even to double-check against the reference implementation)?

If you have concerns about a NetBeans bug or about the syntax of lambda, 
please direct those elsewhere; they don't belong on this list.

Thanks!

                     -Mike



> Subject: Type annotations don't look very Java-like
> From: Timo Kinnunen <timo.kinnunen at gmail.com>
> To: type-annotations-spec-comments at openjdk.java.net
> Date: Wed, 18 Sep 2013 22:01:13 +0300
>
> This is a repost of a comment from Mark Reinhold’s blog with additional
> comments below.
>
> I have to agree, both Lambdas and Type Annotations that I've been looking
> forward to don't look very Java-like at all. Lambdas add ugly syntax and
> Type Annotations break the simplicity of nested scoping.
> I'd love to see a list of what other options the EG considered and why 
> they
> were rejected for what we have currently when Public Review phase starts.
>
> Here's Lambda with -> syntax:
>
> list.stream().map((Runnable runnable) -> { new Thread(runnable) }
> ).forEach(thread -> thread.start());
>
> Why "->" when "for" is just as many keys to press and no 
> key-combinations:
>
> list.stream().map(for(Runnable runnable) { new Thread(runnable) }
> ).forEach(for thread thread.start());
>
> And Type Annotations, just look at this method signature:
>
> void innerMethod(@Any Outer. at Backer Middle. at Counted Inner this, @Any
> Outer. at Backer Middle. at Nullable @Counted Inner other) { ... }
>
> How do you suppose a word-wrapping text-editor would think they are
> grouped? Care to guess if it matches how they group semantically? Yep, 
> the
> empty " " character is now more significant than the "." character, which
> is unbelievable.
>
> And if that wasn't enough, Type Annotations also lets you express the
> difference between annotations applied to a parameter and annotations
> applied to the type of the parameter. Here's how an annotation is applied
> to the parameter:
>
> void callingJava7Way(@Regarding Example oldOne) { ... }
>
> And to make the annotation apply to the type of the parameter, you do 
> this:
>
> callingJava8Way(com.somecompany.AnnotationTestBed. at Regarding Example
> newOne) { ... }
>
> That has got to be the most verbose modifier of another modifier I've 
> ever
> seen in any programming language ever and whoever came up with it 
> deserves
> some sort of a prize.
>
> Alex Buckley replied:
> “You don't have to use qualified names with type annotations. To write an
> annotation on the type of a formal parameter, as opposed to the 
> declaration
> of the formal parameter, you just add @Target(ElementType.TYPE_USE) to 
> the
> annotation's own type declaration. Then, "@Regarding Example oldOne" 
> means
> @Regarding applies to this particular use of the Example type, rather 
> than
> to the oldOne declaration.
>
> More comments on type annotations? Send them to the
> type-annotations-spec-comments at OpenJDK.”
>
> Alex, there might be bugs or unimplemented changes, but trying it out in
> the latest NetBeans IDE 4.7 Beta, JDK 1.8.0-ea-b106 and the annotation
> @Regarding defined like this:
>
> @Retention(value = RetentionPolicy.RUNTIME)
> @Target(value = {ElementType.TYPE_USE, ElementType.PARAMETER,
> ElementType.FIELD, ElementType.LOCAL_VARIABLE})
> @interface Regarding { }
>
> Then as seen in the Trees (NetBeans development) view, right now you do
> have to write “com.somecompany.AnnotationTestBed.” in front of the
> annotation to modify the modifier into becoming an annotated type 
> instead.
> Specifically, instead of 1xMODIFIER, 1xIDENTIFIER there will be 
> 0xMODIFIER,
> 1xANNOTATED_TYPE.
>
> I don’t know where this change in semantics comes from or what its 
> meaning
> is, but I can see that it’s there. And as long as it is there, it can
> become requirement for using some functionality in any tool that can 
> detect
> its presence.
>
>
>
> -- 
> Have a nice day,
> Timo Kinnunen