Annotations for language features

[Adam Malter]

Joe - I apologize then, I read the tweaking of JSR 269 to be further
towards a new api than an evolution of the current. I did not mean to
spread mis-information.

I will admit I am a bit gun shy about this issue, having to support a
com.sun.apt Processor, JSR 269 processor and Eclipse PlugIn (using the
eclipse ast) to enable some of the neat 'features' we want for our
implementation developers.

Everything seems to work a bit differently depending on where and how
you compile. It's this lesson though that I wish to convey when I
express fear about core features enabled by code parsing and
generating in the JDK.

Reinier - Currently I'm working on an 11m LOC financial services
project. (Yes, I know, it needs to be broken up) - I'm doing a branch
right now to play with Lombok, but considering that Eclipse currently
has trouble processing the source tree whenever I do heirarchy view or
outline view, and I know what code is run by Eclipse plugins 'on every
keystroke', I have my worries.

The 'Huh?' shrug when we're discussing language features vs tooling
support is disingenuous at best. I know you wrote a language tool to
demonstrate features. So, you must understand that the language
features *must* be supportable by the toolchains. One of the great
features about Java is it's ability to be safely refactored (Tool
based). This comes from the strong type system built into the language
(Language Based). The language, and the tools it enables are strongly
intertwined. Ruby will never be able to have a (safe) refactor system
because of this interdependency.

I understand that one "can't" tell from the classfiles if the author
used Project Lombok or not. But, I'm only vaguely interested in the
class files, what I'm really interested in is the source code. The
primary reason we stay away from closed source projects is not because
of the cost (well, sometimes it is, but mostly not), but because
without access to the source code from my well tooled IDE, I often
cannot make reasoned implementation decisions.

Whether or not I under private @Property country or not, what if when
I do a search by reference on a piece of de-coupled code that says
'purchaseOrder.getCountry()'

If my IDE is not 'Lombok' blessed, I might be able to find the
referencing class, but certainly not the line of code executing. When
I debug it, I'll drop into either a synthetic method, or maybe the
.aptGenerated source.

I'm not arguing over using annotations vs keywords. I understand that
they both have pro's and con's when adding functionality. In this case
it's the functionality I'm specifically against. Using either of them
to 'generate' boilerplate code. This magic code becomes invisible and
just adds to the complexity budget of the language.

Don't believe me, come over to the dark side where I had to painfully
explain to an implementation developer that he didn't need to create a
static List of his enum values on construction. He did not understand
that every enum came off the Enum class, and even then, the values()
method is not even mentioned in the source. (Which I know, it's pretty
easy thing, but could we have not made like an abstract method or
something there, then you'd get a Javadoc, etc)

And I'm consistent about this, I hate that arrays have the magic
length property. At least your proposal includes instructions in the
source.

Hey, if it's just about @Property, well I suppose your right, because
it's so simple, because everyone can understand it, I'd give ground on
that. But, it's not. Lets slide down the imaginery slippery slope and
end up with @EqualsAndHashCode - Well, sure, get/set are easy,
boilerplate, never implented differently. But .equals() and
.hashCode()? Simple if all you have are a bunch of primitives, but
start throwing those around in a moderately complex project, and if
you've got a mess real quick. At least with Eclipse's autogenerate, I
can see what's going on, tweak it if I know that including a reference
to a giant string property would kill my hashcode when I've got a
perfectly good primary key generated by ORM. And @Data, well, I will
argue that many reasonable programmers will be baffled by what that
does.

And what happens if I take your source and compile with a different
version of Project Lombok (maybe you found a bug in .equals()
template, not impossible, apache commons certainly showed that).

Maybe I am too used to being able to checkout projects by source and
compile them. And then have a reasonable expectation that they will
work the same as the delivered binary. Sure, as things stand right now
all sorts of stuff can go wrong. I can have the wrong jdk version, or
dependencies or whatever, but the point is that adding auto-generation
magic, no matter how, makes the situation worse, not better.

-adam malter

On Sun, Aug 16, 2009 at 3:17 PM, Joseph D. Darcy<Joe.Darcy at sun.com> wrote:
> Adam Malter wrote:
>>
>> On Sun, Aug 16, 2009 at 2:23 PM, Artur Biesiadowski<abies at adres.pl> wrote:
>>
>>>
>>> Reinier Zwitserloot wrote:
>>>
>
> [snip]
>>
>> I think anybody who's worked with 'code generating' annotation
>> processors could enumerate a number of good reasons to stay away.
>>
>> They have been universally fragile, difficult to test, difficult to
>> code and difficult to debug. Additionally, they place a serious
>> complexity and runtime strain on development tools. The 'code' must be
>> generated realtime in order to preserve 'as your type' error hints
>> (aka, insure an accurate AST model with references back to true source
>> code).  Additionally, they introduce dependency graphs that are not
>> clearly resolved even by the current generation of annotation parsers
>> (See Joe Darcy's attempt to build a *third* Apt API in as many
>> versions of Java and then lookup the concept of generation rounds in
>> the Eclipse apt development documentation)
>>
>
> I don't know what attempt at a third API you are referring to.
>
> The apt tool and API was always planned to be "the one we throw away" in the
> "The Mythical Man-Month" sense, which is why it has been deprecated in JDK 7
> and is planned for removal in a future JDK release.
>
> The JSR 269 API (javax.annotation.processing, javax.lang.model.*) improves
> significantly on apt and JSR 269 was informed by experiences BEA engineers
> gained from implementing apt in an IDE.
>
> The JSR 269 API is being tweaked a bit in JDK 7 and can be expected to
> change further to support new language features.  Supporting language
> evolution smoothly was a key technical goal of JSR 269 specifically to
> *avoid* introducing yet another API in JDK 7.
>
> -Joe
>
>