Hi all, I have a story here. In Oct 2021, I upgraded Eclipse to the latest release (2021–09) and then found out that the Lombok dependency was added Drill repository, So I installed Lombok (as a new plugin) from Eclipse Marketplace as I used to. Finally, restarted the IDE and prepared to open the Drill project, but it is crushed cause by the issue #2956 <https://github.com/projectlombok/lombok/issues/2956>, Lombok was not available until I looked at a temporary solution..
I use both Eclipse and IDEA, but I use Eclipse more often. I have no objection to the use of Lombok, but suggest the following three points : 1. Could we use Lombok only in `drill-contrib` module? 2. Could we agree not to use Lombok in common module? 3. It is best to update the dev documentation to describe this results if we continue to use Lombok. In fact, I have the same idea as Paul, more about balancing choices. Thanks. > 2022年1月22日 下午5:34，Paul Rogers <par0...@gmail.com> 写道： > > Hi All, > > I look at any tool as a cost/benefit tradeoff. If Drill were a typical > business app, with lots of "data objects", then the hassle of Lomboc might > be a net win. However, the nature of Drill is that we have very few data > objects. We have lots of Protobuf objects, or Jackson-serialized objects, > but not too many data objects of the kind used with object-relational > mappers. > > On the other hand, I had to spend an hour or so trying to figure out why > things would not build in Eclipse. Then, more time to figure out how to > install the half-finished Lomboc plugin for Eclipse and various other > fiddling. > > So, I'd guess, on balance, Lombok has cost, and will continue to cost, more > time than it saved avoiding a few getter/setter methods. And, I agree with > Ted, Eclipse (and, I assume IntelliJ), is pretty quick at generating those > methods. > > Since Lomboc has a cost, and is not a huge win, KISS suggests we avoid > adding extra dependencies unnecessarily. > > That's my 2 cents... > > - Paul > > > > On Fri, Jan 21, 2022 at 8:51 AM Ted Dunning <ted.dunn...@gmail.com> wrote: > >> A couple of years ago, I had a dev introduce Lombok into some code without >> me knowing. That let me be a classic naive user. >> >> The result was total confusion on my part. Sooo much code was being >> automagically generated that I couldn't figure out the code and spent a lot >> of time chasing my tail and very little time looking at the crux of the >> code. >> >> My own personal preference is either >> >> - use a language like Julia if you want magic. It's fantastic and all to >> have amazing stuff and coders expect to see it. >> >> - use an IDE to generate the boiler plate and put it into its own little >> annex in the code with the interesting bits near the top of classes. That >> lets debuggers and IDEs that don't understand Lombok to function without >> impairing readability much. Concurrent with that, use discipline to not do >> strange things like changing the expected meaning of the boilerplate. >> >> That's my preference, but I wouldn't want to push that preference very >> hard. My own prioritization is on readability of the code by outsiders. >> >> >> >> >> On Fri, Jan 21, 2022 at 2:25 AM James Turton <dz...@apache.org> wrote: >> >>> Hi again Devs >>> >>> This one is simple to describe. Lombok entered the Drill code base this >>> year, but not everyone feels that Lombok is appropriate for every code >>> base. To my, fairly limited, understanding the advantage of Lombok is >>> that boilerplate code is reduced while the disadvantage is the >>> deployment of code generation magic that can have untoward effects on >>> build-time tools and IDEs. >>> >>> So here is a chance to opine on Lombok if you'd like to. My own opinion >>> is very near neutral and goes something like "It burned me a bit once, >>> but hasn't since, and less boilerplate is nice. I guess it can stay >>> <shrug>. I hope I don't regret this one day." >>> >>> Regards >>> James >>> >>
