[sakai2-tcc] Discuss: should we be using lombok in Sakai?

[Steve Swinsburg]

Lets dispel a few myths that have been circulated around Lombok.

Firstly, the point isn't to have automatically generated getters and
setters. People can do that in Eclipse already. The point is that if you
have dozens of member variables with getters and setters, constructors, log
statements etc etc, ALL of those potentially hundreds of lines of
boilerplate junk can be eliminated into one line of Lombok (@Data), or if
you want to be more granular, into individual annotations (@Getter @Setter
@NoArgsConstructor et al).

Secondly, If you don't have Lombok installed, code will still compile
perfectly fine since the dependency is in the projects, from Maven central,
and Maven will use it.

Third, if you use an IDE, there is almost always configuration to make and
plugins to install - we list these in the developer environment guide.
Installing and upgrading Lombok is as simple as double clicking the jar and
it takes care of installing it into Eclipse. And if you are just doing
casual fixes, you don't even need to install Lombok.

Fourth, there is no extra Maven setup required. Its a dependency, that is
all. Like every other dependency. We use Maven, I dont think that adding an
extra dependency where its needed is even worth discussing since its a
given.

Fifth, there have been a sum total of ONE issue reported in the Sakai Jira
against Lombok since it was brought into use in 2009 (I incorrectly stated
I was using it since 2008 before - because Profile2 was the first project
it was used in, which was conceived in 2008). That issue is here:
https://jira.sakaiproject.org/browse/SAK-21642 and was as simple as
upgrading the version being used. Probably the simplest fix ever.

Sixth, this is a compile time annotation (with the exception of a couple of
annotations that are runtime that I dont think are even being used). The
annotations are expanded and discarded. There is no real reason for any
project in Sakai to stay lombok free just because of some ideological or
stubborn principle. What is the point of the kernel staying lombok free
when others are using lombok? Its developed using the same tools and
compiled using the same compiler as every other project, and we can reduce
probably thousands of lines of code.

I have read the posts you wrote years ago. Heres one that outlines the
process that lombok applies:
http://notatube.blogspot.com.au/2010/12/project-lombok-creating-custom.html

Note that one of the posts you linked said this:
"If the agreed project strategy is to use Lombok, then commiters who
gratuitously de-Lombok the code should be chastised, and if necessary have
their commit rights withdrawn."

There are plenty of other frameworks and libraries that are in a far worse
state than this, yet those are still being used in Sakai. So unless you
want to review and rewrite most of Sakai to not use the frameworks and
libraries that everyone knows are a problem and are causing real problems
for many people right now, then I think a little helper library that makes
code elegant and easy to read is acceptable.

thanks,
Steve


On Tue, Aug 13, 2013 at 11:09 PM, Aaron Zeckoski <azeckoski at unicon.net>wrote:

> lombok was released in 2009 and is not even at a 0.2 yet. Also, there
> is clearly debate about it in the java community:
> http://stackoverflow.com/questions/3852091/is-it-safe-to-use-project-lombok
>
> http://stackoverflow.com/questions/2866084/is-project-lombok-suitable-for-large-java-projects
>
> Should we be using this in Sakai?
> I have seen multiple new developers to Sakai confused by it. I
> understand using eclipse to generated getters takes a few clicks and
> makes the code a little longer but I don't think that is all that
> hard.
> Lombok saves a few lines of code but at the expense of requiring
> special eclipse (or other IDE) configuration, extra maven build, and
> special developer knowledge of what is happening (so they know why
> they don't see any get and set methods like... 99% of java projects.
> It also completely breaks compile time code scanning (around anything
> it affects anyway) but
> that is a lesser concern.
> If we decide to use it broadly as a community, I think it needs to be
> clearly documented and indicated as a requirement. If not, I think we
> should delombok the current handful of places it is used.
>
> I added this to the CLE team call as a discussion point for this week:
> http://etherpad.ctools.org/rmmt-2013-08-15
>
> -AZ
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130814/a5dadaea/attachment.html