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

[Noah Botimer]

I personally don't think we should outlaw it any more than we should outlaw JSF, for example.

There is a case to be made for consistency, but there is also a case for free agency.

I have not taken to Lombok for my own code [1], and we should not add it to a bunch of existing areas for the sake of adding it [2], but I find it totally acceptable that new areas try it out so we can compare and decide within the community what our taste for it is.

Lombok may cause some confusion, but as exhibit A of somewhat confusing stuff you get over quickly, I offer our "components" and cross-app Spring context and dependency injection. I just don't think it's a big deal either way.

I will not argue strenuously in any direction except against a new, required practice.

Thanks,
-Noah


[1] I primarily use Vim over perpetually wrangling IDE project files, so magical annotations don't usually help or hurt me much. It's just that the base use case of avoiding getters and setters comprises approximately 0% of my life, so it hasn't been something I have prioritized.

[2] Respect the house of those who came before; refactor, but focus on quality and simplicity over brevity and preference.

On Aug 13, 2013, at 9:09 AM, Aaron Zeckoski 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