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

Tue Aug 13 13:28:53 PDT 2013

A getter and a setter aren't necessarily "too much effort". It's just that
if you have getters and setters for every member variable to support spring
then you have an extra few hundred lines of code to scroll though before
you get anywhere. This was really about the @Builder pattern (and other
lombok stuff), where 1 line of lombok = ~40 lines of java code (that's
always the same). The builder pattern is significantly better than our
"create new constructors with new parameters, deprecate the old ones, but
never remove them" pattern. :)

I'm also also fine with kernel staying lombok free. Linux kernel is C++
free. I just wouldn't be against it for use in tool development. Anymore
than I'd be against someone writing a new tool in a tool in Grails or jruby
either.

I can't even get most tools to compile completely in eclipse anyway, even
after adding all of the dependencies and doing full builds on the command
line.

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

> None of the frontend frameworks cause the IDE to report that code is
> broken.
>
> That said, I take it Matt or Noah are volunteering to update the docs
> to document the "easiest" process then which I think is excellent.
> Please do also send out a note to the dev list with the updated docs
> so that at least current dev list people are aware of this. Imagine
> yourself as a new dev who does not even know what lombok is and all
> they see is code which does not compile. Document from that approach
> and I think things will be fine.
>
> We should not use this in kernel until it hits at least a 1.0 release
> though. I am happy to spend the time generating the getters and
> setters for anyone who cannot be bothered to do it. Please just let me
> know when there is a case in kernel where generating a getter or
> setter is too much effort and I will jump in and take care of it.
>
> -AZ
>
>
> On Tue, Aug 13, 2013 at 3:11 PM, Matthew Jones <matthew at longsight.com>
> wrote:
> > I would agree with Noah, the variety of frameworks used in Sakai all
> require
> > special eclipse configuration. Velocity, JSF, Wicket, RSF don't work out
> of
> > the box and we don't have great documentation on how to develop with them
> > for Sakai. Getting Lombok integrated into eclipse (on Ubuntu) only takes
> > running "sudo java -jar lombok.jar", easiest I've ever seen.
> >
> > I understand what's happening and happier setting less code. I don't
> think
> > we should go adding it in a bunch of places or taking it out either, but
> I
> > think it will cause a lot less confusion than ClassCastExceptions with
> > duplicate jars (which I've seen way to many of already today).
> >
> > I also agree with Noah that I *usually* use vim over an IDE anyway for
> quick
> > fixes, so anything that requires less code is for sure easier to deal
> with
> > even if it is a right click in the IDE to add a bunch of junk.
> >
> >
> > On Tue, Aug 13, 2013 at 3:00 PM, Noah Botimer <botimer at umich.edu> wrote:
> >>
> >> 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
> >>
> >> _______________________________________________
> >> sakai2-tcc mailing list
> >> sakai2-tcc at collab.sakaiproject.org
> >> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> >
> >
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130813/b84a8c80/attachment-0001.html 