I'm happy to put this work on hold for now. As I mentioned there are other
benefits beyond just getters and setters -- but I guess the risk with JDK10
(I was unaware of the problems between Lombok and JDK10) may be unknown
enough for us to take pause. Thanks for all your input!
-Aditya
On Fri
I apologize, I was slightly wrong earlier with regards to the the IntelliJ
Lombok plugin -- people will not need the IntelliJ plugin for their code to
compile -- but they will need to enable compile-time annotation processing
as an option. The plugin is a nice-to-have.
On Fri, Nov 9, 2018 at 9
-1 Personally, I prefer to being able to see and manipulate ALL code. I
hate autogenerated code, and I don't mind boilerplate code. When I see a
class that has too many getters, then I see that as a sign that we need to
do some refactoring and correct the design of that class. Using Lombok
would
()
>> ?:emptyArray(), configuration.hostnameForSenders,
>> ifNotExists)
>>
>>
>> companion object {
>> @JvmStatic val serialVersionUID = -5158224572470173267L }
>> }
>>
>>
>> On 11/8/18 12:02, Aditya Anchuri wr
eForSenders,
> ifNotExists)
>
>
> companion object {
> @JvmStatic val serialVersionUID = -5158224572470173267L }
> }
>
>
> On 11/8/18 12:02, Aditya Anchuri wrote:
> > I've only touched a few classes in my PR, but I feel like there's a lot
> > more boile
ode I would find
Lombok pretty useful. Have included a link to the PR:
https://github.com/apache/geode/pull/2815
-Aditya
On Thu, Nov 8, 2018 at 11:24 AM Udo Kohlmeyer wrote:
The Spring world/community are heavy users of Lombok.
In essence it is "nice", BUT it does now add a n
Regarding is vs get, Lombok generates a getter as "isFoo" if foo is a
boolean type -- but a Boolean object type by default gets generated as
getFoo().
I personally like that, because I want to make sure I communicate in that
getter that the type is nullable.
On Thu, Nov 8, 2018
I’d prefer to keep lombok usage out of our public API’s. I’d like to be able
to write javadoc for all public methods. Also, I don’t want a user to have to
understand Lombok to read our API’s or do an extra step to setup their IDE.
For internal usage I’m agnostic with a small dose of concern
Note: If the PR gets accepted, people that use IntelliJ idea or Eclipse
will need to use the Lombok plugin for their respective IDEs -- for
IntelliJ people will also need to enable annotation processing in the
compiler settings if not already enabled.
On Thu, Nov 8, 2018 at 12:02 PM Aditya
I've only touched a few classes in my PR, but I feel like there's a lot
more boilerplate floating around that can be removed. Having said that, I
agree with your point regarding Kotlin, but for the Java code I would find
Lombok pretty useful. Have included a link to the PR:
https://github.com
The Spring world/community are heavy users of Lombok.
In essence it is "nice", BUT it does now add a new dependency on a
library that is to provide functionality that developers should provide.
IJ Idea does provide support for Lombok.
I have not yet seen any code bloat that Lo
Hi everyone,
I am considering adding Lombok as a compile-time dependency (
https://projectlombok.org/) so we can reduce the amount of boilerplate code
and reduce the size of some of our classes. I have a small proof of concept
PR ready to go. Before I do so, I want to find out if people have
12 matches
Mail list logo
