True, I should have said 'use an annotation to trigger the rewriting'. That's my issue: you can only try out language features that are concerned with declarations, since that's all you can annotate. It's like being a sports car designer but insisting you can only work with an automatic transmission - your product will be easy to drive but incredibly frustrating.
Yes, prototyping is great. What you've implemented in Lombok is non- trivial. Getting the generated boilerplate 'just right' is important. But you claimed your goals are much more: "A java.next for the rest of us. Closures, more literals, probably extension methods and operator overloading, properties, lots of boilerplate elimination". The implication is that you can just hack up these features and blow away the ponderous inscrutable design-led Coin project. Sun has long experience with features that look simple but have horrible edge cases or deeply affect parts of the language one might characterize as 'tense' or 'brittle'. (See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6863462 for a recent discovery that manages to be impressive and depressive at the same time.) Hence Coin concentrated on deep discussion of proposals, *especially* when the author claims it's really easy. The irony of your cynical sniping at Joe when Lombok is driven by his annotation processing framework is rather hard to bear. I will also comment that you have a propensity for making sweeping incorrect statements about the Java platform. A couple of weeks ago it was the technical relationship of the Java language and the Java VM, and then Java compiler compliance with the JLS. Below it's the language evolution process itself. ("no central body that picks known cases with no issues and adds them to the language spec") Again, laughable. Alex On Aug 13, 7:34 pm, Reinier Zwitserloot <reini...@gmail.com> wrote: > Alex, you seem to misunderstand a thing or two about lombok and APs. > The two obvious mistakes: > > - An Annotation Processor that is registered to listener for > everything is called, both on initialization and for each class, even > if there are no annotations anywhere in the entire source code base. > You seem to think that they can't trigger unless there's an annotation > someplace. This is incorrect. > > - Lombok DOES in fact hack ecj directly. It just does so in a fashion > which does not require you to change any files in your eclipse > installation, other than eclipse.ini. It has to for the reasons you > stated: the AP API isn't even remotely close to complete enough to > serve as generic toolkit for IDEs; IDEs use all sorts of optimization > tricks (case in point: eclipse doesn't parse method bodies when it's > just rolling through a class to gather method signatures to e.g. fill > an auto-complete dialog. But a generated getter method should > obviously be listed, so lombok has to run even for a source file > that's being "diet parsed" like that). > > Onwards to the meat of your arguments: > > I don't see how the issues with rewriting 'a == b' to an equals call > are specific to lombok. Any programming language that wishes to be so > close to familiar java syntax that you can get started right away is > going to run into a problem if it wants to redefine the meaning of > code which, in java, has a perfectly valid but entirely different > meaning. > > Annotations, -where they fit well-, have few disadvantages (rather a > lot of at signs in your code, for one), and many advantages > (namespaced, and serve as a documentation pointer. Also by definition > trivially grammar compatible, and backwards/migration compatible as > well, at least as far as syntax is concerned). The things lombok can > manage today all seem to be a great fit for annotations, even @Cleanup > (lombok's variant on Automatic Resource Management), which when I > started out with project lombok wasn't something I thought would work > with just an annotation. It's not for every feature (I don't really > see how they'll be any help with a list comprehension or closures, to > name a few), but where they are a good fit, I'll gladly take em. > > As to your last paragraph, I presume that you did not intend to piss > all over somebody's hard work to build a prototype and provide a > (mostly) convenient framework for others to experiment as well. > > On Aug 13, 11:53 pm, Alex Buckley <alex.buck...@sun.com> wrote: > > > On Aug 13, 2:03 pm, Reinier Zwitserloot <reini...@gmail.com> wrote: > > > > About project lombok, in reply to: > > > > On Aug 13, 7:50 pm, Charles Oliver Nutter <head...@gmail.com> wrote: > > > > > Project Lombok seems to be mostly a set of annotations for common Java > > > > patterns, rather than a new language. What I'd like to see is someone > > > > take javac, hack all the missing features into it, and call it > > > > something new. > > > > Annotations for now because they are nice and namespaced, but there's > > > nothing in the lombok framework that _requires_ annotations. lombok > > > could rewrite every instance of 'a == b' where both a and b are > > > objects, to 'a == null ? b == null : a.equals(b)' if you wanted it to. > > > And then you wouldn't be able to use an annotation processor to > > trigger the rewriting. Charlie's point about hacking javac wasn't that > > you should eschew IDEs and push people back to notepad. It was that a > > language change is properly made in a compiler where the grammar can > > be tweaked without limit and where the change benefits from other > > parts of the compiler's pipeline, e.g. definite assignment analysis. > > By implementing Lombok as an annotation processor, it's constrained to > > a small part of the pipeline so has to reach out and basically > > vandalize the compiler's AST. Since both Eclipse and Netbeans > > ultimately call into ecj and javac directly, it would be much better > > if you just hacked that ecj or javac instance directly. > > > A related point is that your attacks on Coin (and Joe in particular) > > are tiresome and offensive, and your shilling for Lombok as the savior > > of the everyman Java programmer is laughable. > > > Alex --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
