nice analysis :)
one question that arises in my mind: in the future, in 2, 3 or 4
years, with
all these features integrated in groovy or clojure which tends to be
more
efficient "syntaxically" or more "specialized" also, I really wonder
why we
should keep coding in Java in fact. The question of performance is not
really an issue since everything runs in the JVM at the end.
Anyway, this is not the subject here but I wonder :)
Have you seen last Java7 language evolution?
Pascal
On Wed, Nov 25, 2009 at 12:33 AM, Niels Mayer <nielsmayer(a)gmail.com>
wrote:
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org