On Mon, Nov 23, 2009 at 9:32 PM, Asiri Rathnayake <
asiri.rathnayake(a)gmail.com> wrote:
As I understood this is not a change to java syntax or
anything. It's about
augmenting classes when they are compiled. So at source level they do not
have any getXXX() or setXXX() methods but when compiled lombok does it's
magic and add the methods. I think most of the IDEs use compiled .class
files to determine what a class is capable of (rather than analysing the
source code) but still, there will be a problem if you try to lookup those
methods in the source file.
Am I correct? Anyone who has tried out lombok?
Isn't the automatic creation of getters and setters one of the features of
groovy, which is already tightly integrated into Xwiki?
Looking at lombok feature list, every single feature is already provided by
Groovy, much more elegantly, and already part of Xwiki, except for perhaps
the @Synchronized, which is accomplished far more elegantly in clojure (
http://blip.tv/file/812787/ )
http://projectlombok.org/features/index.html
@Getter / @Setter <http://projectlombok.org/features/GetterSetter.html>Never
write public int getFoo() {return foo;}
again.@ToString<http://projectlombok.org/features/ToString.html>No
need to start a debugger to see your fields: Just let lombok generate a
toString for
you!@EqualsAndHashCode<http://projectlombok.org/features/EqualsAndHashCode.html>Equality
made easy: Generates hashCode and equals implementations from the fields
of your object.@Data <http://projectlombok.org/features/Data.html>All
together now: A shortcut for @ToString, @EqualsAndHashCode, @Getter on all
fields, and @Setter on all non-final fields. You even get a free
constructor to initialize your final
fields!@Cleanup<http://projectlombok.org/features/Cleanup.html>Automatic
resource management: Call your close() methods safely with no hassle.
@Synchronized <http://projectlombok.org/features/Synchronized.html>
synchronized done right: Don't expose your
locks.@SneakyThrows<http://projectlombok.org/features/SneakyThrows.html>To
boldly throw checked exceptions where no one has thrown them before!
Fabio Mancinelli said:
It is indeed cool and it is a nice way for embedding
in Eclipse a
rudimental macro processor, making Java look more LISPy :)
W/r/t adding macros or making "small custom languages" -- groovy has it's
meta-object protocol, and then there's the even nicer way of doing things --
clojure -- it's silly to try to emulate "lisp macros in java" because the
syntax is all wrong to begin with. There's solid
theoretical reasons for lisp looking like it does (e.g. Church's lambda
calculus and Quine's set
theory<http://www.rbjones.com/rbjpub/logic/cl/index.htm>)m>),
and the language-power you get from treating programs as 1st-class data and
vice-versa (where the first-classness, and the ability to create closures
that work transparently and correctly is the key to it all).
IMHO, adding an IDE to make Java look more Lispy is an odd use of precious
resources.
Why not make java look more lispy directly?
http://clojure.org/ -- a project
with far more buzz and traction than lombok, cool-looking-as-it-is; Lombok
would end up "microsofting" development efforts by forcing a single solution
on what should be an open-market. IDE-wars are even worse than language
wars, IMHO, which is why I'd hope effort is put into generally-useful
"platform" solutions that would provide equal benefit to all IDE users as
well as
regular Xwiki web-users.
Note that both clojure and groovy have IDE support in eclipse.
Should language level extensions be necessary, groovy's Meta-object protocol
support should obviate the need for further Xwiki extensions. See chapters
12 and onward in
http://www.pragprog.com/titles/vslg/programming-groovy
Part 3: “MOPping Groovy”
Metaprogramming is one of the biggest benefits of dynamic
languages
and Groovy; it has the ability to inspect classes at runtime and
dynam-
ically dispatch method calls. You’ll explore Groovy’s support for
meta-
programming in Chapter 12, Exploring Meta-Object Protocol (MOP),
on
page 186, beginning with the fundamentals of how Groovy handles
method calls to Groovy objects and Java objects.
Groovy allows you to perform AOP-like method interceptions using
GroovyInterceptable and ExpandoMetaClass, as you’ll see in Chapter
13,
Intercepting Methods Using MOP, on page 196.
In Chapter 14, MOP Method Injection and Synthesis, on page 204,
you’ll
dive into Groovy metaprogramming capabilities that allow you to
inject
and synthesize methods at runtime.
In Chapter 15, MOPping Up, on page 226, you will learn how to syn-
thesize classes dynamically, how to use metaprogramming to delegate
method calls, and how to choose between different metaprogramming
techniques you’ve learned in the previous three chapters.
Unit testing is not a luxury or a “if-we-have-time” practice in Groovy.
The dynamic nature of Groovy requires unit testing, and fortunately, at
the same time, it facilitates writing tests and creating mock objects, as
you’ll learn in Chapter 16, Unit Testing and Mocking, on page 236. You
will learn techniques that will help you use Groovy to unit test your
Java code and Groovy code.
Groovy builders are specialized classes that help you build internal
DSLs for a nested hierarchy. You can learn how to use them and to
create your own builders in Chapter 17, Groovy Builders, on page 262.
You can apply Groovy’s metaprogramming capabilities to build internal
DSLs using the techniques you’ll learn in Chapter 18, Creating DSLs
in Groovy, on page 279. You’ll start by learning about DSLs, including
their characteristics, and quickly jump in to build them in Groovy.
-- Niels.
http://nielsmayer.com