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 <nielsma...@gmail.com> wrote: > On Mon, Nov 23, 2009 at 9:32 PM, Asiri Rathnayake < > asiri.rathnay...@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;} aga...@tostring< > http://projectlombok.org/features/ToString.html>No > > need to start a debugger to see your fields: Just let lombok generate a > > toString for y...@equalsandhashcode< > http://projectlombok.org/features/EqualsAndHashCode.html>Equality > > made easy: Generates hashCode and equals implementations from the fields > > of your obje...@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 fiel...@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 loc...@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>), > 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@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
