Annotations for language features

Sun Aug 16 16:55:03 PDT 2009

Now you're attacking lombok itself. That's all fine, but how this is  
relevant to project coin? I've taken the rest of this discussion to  
email. If anyone else is interested, please email me and I'll post our  
emails (with the fiat of Adam, of course!) to the project lombok  
newsgroup.

On 2009/16/08, at 22:11, Adam Malter wrote:

> 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
>>
>>