On Nov 23, 2009, at 6:33 PM, Vincent Massol wrote:

...

Hi devs,

Project Lombok sounds cool: http://projectlombok.org/

WDYT?

It is indeed cool and it is a nice way for embedding in Eclipse a rudimental macro processor, making Java look more LISPy :)

Few words from outside: using 'not-plain' java for compilation and require download extra tool on top of Eclipse, will prevent outside developers (especially vi lowers) from touching xwiki code. Also entry barrier will be more hight than below. (decision partially use scala will not so destructive ;))

-Fabio _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Le 23-nov.-09 à 21:27, Jerome Velociter a écrit :

...

Few words from outside: using 'not-plain' java for compilation and require download extra tool on top of Eclipse, will prevent outside developers (especially vi lowers) from touching xwiki code.

The demo shows you can compile with standard javac just having lombok in the classpath.

Will I enjoy all the glories of the support that my IntelliJ is giving me? Changing syntax away from a widely supported syntax is a very dangerous move to me! If this is to change the xwiki sources, will I still be able to crawl through stack-traces? paul

...

Also entry barrier will be more hight than below. (decision partially use scala will not so destructive ;))

Exactly as I feared. Line numbers are not going to match I'm afraid. paul Le 24-nov.-09 à 06:32, Asiri Rathnayake a écrit :

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?

Groovy has good stacktraces' entries... they manage this in some way. Maybe Lombok does as well? Why yet another language? paul Le 24-nov.-09 à 09:17, Pascal Voitot a écrit :

I wonder why we still have to code getters/setters by default... as usual for Sun standards: someone has to do it by itself and when too many people use it, they are urged to introduce it somewhere as a JSR... and generally worse than the original... concerning line numbers, I have already forgot this IDE feature since I use groovy which also adds lots of things at compilation... our dev IDE are not prepared for this ;)... lets go back to vi!

On Mon, Nov 23, 2009 at 9:32 PM, Asiri Rathnayake < [email protected]> 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>), 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

Hi, On Wed, Nov 25, 2009 at 1:33 PM, Pascal Voitot <[email protected]>wrote:

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?

One point that bothers me is that Java is very easy to understand. I can write a java program, come back after 6 months and still be able to read and understand it in a couple of hours. Is the same true for clojure / groovy? And what about Remote debugging, IDE support (Syntax highlighting / intelisense), Learning curve ? I've done some serious programming in groovy (haven't touched clojure yet) and what I understood is that it makes me very tempting to hack in a solution (because it's very easy) and get it to work (very very rapid) but on the end it results in a bad design. This is only my opinion, I'm not against or favour of groovy / clojure. But I love java :) - Asiri

My current feeling is that Java has been professionally designed with very long-term view in mind, and that IDEs developers have done the same with fierce competition. That results in Java projects being very easy to exchange, very easy to read and, what I feel is the most important, very easy to navigate. The support for Groovy is somewhat there in IntelliJ for example, it's not too bad and you can tune it to add the predefined type so that you get some luxury. However, it is in no way near to the well-definedness of the java support. For example, IntelliJ has grey underlines for things "it's not sure of", the auto-completion is quite often too big... So please let us consider this from the point of view of the practicing developer, not that of the shortness of the code which is really just a tiny facet of programme management. (and everyone knows regexps are short but unreadable and horror to survive) paul Le 25-nov.-09 à 09:03, Pascal Voitot a écrit :

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 <[email protected]> wrote:

...

On Mon, Nov 23, 2009 at 9:32 PM, Asiri Rathnayake < [email protected]> 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>), 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs