Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lomboked the code. #581

Closed
wants to merge 3 commits into from
Closed

Lomboked the code. #581

wants to merge 3 commits into from

Conversation

wheredevel
Copy link

As discussed at https://gitter.im/JSQLParser/JSqlParser on Feb 5 2018 @wheredevel -> @wumpz .
Here's the "lomboked" code of JSQLParser.
All the 659 tests are green.

@coveralls
Copy link

coveralls commented Feb 6, 2018

Coverage Status

Coverage decreased (-1.3%) to 85.768% when pulling fb1fe99 on wheredevel:lombok into feaeaeb on JSQLParser:master.

@wumpz
Copy link
Member

wumpz commented Mar 2, 2018

The start of Lombok was fairly simple using Netbeans, which is my favourite IDE. The problems were comming while using it. That's why at the moment I have more objections in using it:

  • Somehow stacktraces are corrupted: sorry I don't know how to describe it better.
  • Netbeans "test file" does not work stable
  • Testng + Maven somehow instable (tests do not run every time) (without lombok no problems)
  • refactoring is problematic, due to Netbeans does not see all usages
  • no more "find usages" in Netbeans (dont know about eclipse)
  • debugging getter not possible anymore

Here is a discussion of pros and cons I found useful. There are a lot more I know.

https://stackoverflow.com/questions/3852091/is-it-safe-to-use-project-lombok

@wheredevel
Copy link
Author

wheredevel commented Mar 2, 2018

I can't comment on Netbeans vs. Lombok, because I never used it.
In the mentioned Stackoverflow discussion there're some tips, like cleaning cache - maybe those can help.

I'm an Eclipse user, and I never encountered any problem, due to Lombok generated constructors and methods. Stack traces, tests, Maven, finding reference or call hierarchies - everything works as expected.

I agree that Refactoring the generated constructors and methods is not straight-forward. But I think, this is the flaw in the Eclipse's implementation of the refactoring. In my opinion, Lombok here is the one that corrects the inherent problem. Here's an example:

Let's say I have a field named count. The generated boilerplate code would have get/setCount() methods. Now I decide to rename the field into total - there's no mechanism to force me to rename its getter and setter(!) Lombok enforces this by managing 3 references at 1 place.

So, I think, what Eclipse developers should do - is to add a checkbox (default) saying "when renaming field, modify getter/setter and their references as well". Currently, the workaround to this: override getter/setter, then rename 1.field, 2. getter 3. setter, then remove getter/setter - back to Lombok.

Same with Debugging getter/setter: if you do not override them, why debugging them at the first place? Their implementation isn't interesting. And if you do override - you can step into, as usual.

@wumpz wumpz closed this Jul 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants