Default constructors in JAVA classes

[Suraj Khurana-2]

Hello team,

While checking codebase using QAPlug [1], it is suggesting to 'Make sure
that utility classes (classes that contain only static methods) do not have
a public constructor' as an efficiency enhancement.

According to it, all our services, events, helper, worker classes which are
mostly in JAVA should be having a private constructor and must be defined
as 'final' so that the JVM doesn't need to create a data object using that
default constructor everytime and supplies which is time taking.

Please let me know your thoughts on this.

[1]: https://qaplug.com/

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

[Daniel Watford]

Hi Suraj,

If the class author's intention was to create a utility class then I would
support demonstrating this by using the private constructor.

The Lombok project briefly describes the case they support with the
@UtilityClass [1].

Private constructors for utility classes also appears in Effective Java [2].

I'm not sure I would extend the definition of Utility Class to cover things
like PartyServices, though. I would prefer utility classes only contain
functional code - i.e. no side effects - which cannot be the case for
services.

Summary - if a class is a genuine utility class, then we should probably
treat it as such by implementing the private constructor and marking the
class final. I'm not sure about whether the same approach should be applied
to non-utility classes that happen to only have static methods.

Thanks,

Dan.


On Wed, 22 Apr 2020 at 16:02, Suraj Khurana <[hidden email]> wrote:

> Hello team,
>
> While checking codebase using QAPlug [1], it is suggesting to 'Make sure
> that utility classes (classes that contain only static methods) do not have
> a public constructor' as an efficiency enhancement.
>
> According to it, all our services, events, helper, worker classes which are
> mostly in JAVA should be having a private constructor and must be defined
> as 'final' so that the JVM doesn't need to create a data object using that
> default constructor everytime and supplies which is time taking.
>
> Please let me know your thoughts on this.
>
> [1]: https://qaplug.com/
>
> --
> Best Regards,
> Suraj Khurana
> Senior Technical Consultant
>

--
Daniel Watford

[Daniel Watford]

Hi again - I forgot the links!

[1] - https://projectlombok.org/features/experimental/UtilityClass
[2] - https://www.informit.com/articles/article.aspx?p=1216151&seqNum=4

On Wed, 22 Apr 2020 at 17:38, Daniel Watford <[hidden email]> wrote:

> Hi Suraj,
>
> If the class author's intention was to create a utility class then I would
> support demonstrating this by using the private constructor.
>
> The Lombok project briefly describes the case they support with the
> @UtilityClass [1].
>
> Private constructors for utility classes also appears in Effective Java
> [2].
>
> I'm not sure I would extend the definition of Utility Class to cover
> things like PartyServices, though. I would prefer utility classes only
> contain functional code - i.e. no side effects - which cannot be the case
> for services.
>
> Summary - if a class is a genuine utility class, then we should probably
> treat it as such by implementing the private constructor and marking the
> class final. I'm not sure about whether the same approach should be applied
> to non-utility classes that happen to only have static methods.
>
> Thanks,
>
> Dan.
>
>
> On Wed, 22 Apr 2020 at 16:02, Suraj Khurana <[hidden email]>
> wrote:
>
>> Hello team,
>>
>> While checking codebase using QAPlug [1], it is suggesting to 'Make sure
>> that utility classes (classes that contain only static methods) do not
>> have
>> a public constructor' as an efficiency enhancement.
>>
>> According to it, all our services, events, helper, worker classes which
>> are
>> mostly in JAVA should be having a private constructor and must be defined
>> as 'final' so that the JVM doesn't need to create a data object using that
>> default constructor everytime and supplies which is time taking.
>>
>> Please let me know your thoughts on this.
>>
>> [1]: https://qaplug.com/
>>
>> --
>> Best Regards,
>> Suraj Khurana
>> Senior Technical Consultant
>>
>
>
> --
> Daniel Watford
>

--
Daniel Watford

[Jacques Le Roux]

Hi,

I agree about changing only non idempotent classes in a 1st approach.

That's obviously service and events, but could be also few helper and worker classes.

We need to check the later and decide one by one. And if they are not idempotent then they should not be called helper or worker. Or rather we would
need to refactor them to extract non idempotent methods.

My 2cts (I have still to read the articles an understand the Lombok project and how we could possibly use it)

Thanks

Jacques


Le 22/04/2020 à 18:39, Daniel Watford a écrit :

> Hi again - I forgot the links!
>
> [1] - https://projectlombok.org/features/experimental/UtilityClass
> [2] - https://www.informit.com/articles/article.aspx?p=1216151&seqNum=4
>
> On Wed, 22 Apr 2020 at 17:38, Daniel Watford <[hidden email]> wrote:
>
>> Hi Suraj,
>>
>> If the class author's intention was to create a utility class then I would
>> support demonstrating this by using the private constructor.
>>
>> The Lombok project briefly describes the case they support with the
>> @UtilityClass [1].
>>
>> Private constructors for utility classes also appears in Effective Java
>> [2].
>>
>> I'm not sure I would extend the definition of Utility Class to cover
>> things like PartyServices, though. I would prefer utility classes only
>> contain functional code - i.e. no side effects - which cannot be the case
>> for services.
>>
>> Summary - if a class is a genuine utility class, then we should probably
>> treat it as such by implementing the private constructor and marking the
>> class final. I'm not sure about whether the same approach should be applied
>> to non-utility classes that happen to only have static methods.
>>
>> Thanks,
>>
>> Dan.
>>
>>
>> On Wed, 22 Apr 2020 at 16:02, Suraj Khurana <[hidden email]>
>> wrote:
>>
>>> Hello team,
>>>
>>> While checking codebase using QAPlug [1], it is suggesting to 'Make sure
>>> that utility classes (classes that contain only static methods) do not
>>> have
>>> a public constructor' as an efficiency enhancement.
>>>
>>> According to it, all our services, events, helper, worker classes which
>>> are
>>> mostly in JAVA should be having a private constructor and must be defined
>>> as 'final' so that the JVM doesn't need to create a data object using that
>>> default constructor everytime and supplies which is time taking.
>>>
>>> Please let me know your thoughts on this.
>>>
>>> [1]: https://qaplug.com/
>>>
>>> --
>>> Best Regards,
>>> Suraj Khurana
>>> Senior Technical Consultant
>>>
>>
>> --
>> Daniel Watford
>>
>

[Jacques Le Roux]

Le 22/04/2020 à 19:58, Jacques Le Roux a écrit :
> I have still to read the articles an understand the Lombok project and how we could possibly use it
I'm thinking about https://projectlombok.org/setup/gradle but I have no ideas yet to what it entails, someone knows?

Jacques

[grv]

Hi

I am unsure if this needs to be extended or applied to the service classes
because even though the service classes do not appear to maintain state,
they conceptually relate to the business domain and hence are not a worthy
candidate. Moreover they are executed within a context and don't qualify as
typical helper or utility classes.

We should be all for this change but probably exempt service classes from
it and restrict this change to Helper/Utility classes. Also, it will be
helpful if we bring this about in phases.

+1 for helper/utility classes.

Best,
Girish




On Wed, Apr 22, 2020 at 11:55 PM Jacques Le Roux <
[hidden email]> wrote:

> Le 22/04/2020 à 19:58, Jacques Le Roux a écrit :
> > I have still to read the articles an understand the Lombok project and
> how we could possibly use it
> I'm thinking about https://projectlombok.org/setup/gradle but I have no
> ideas yet to what it entails, someone knows?
>
> Jacques
>
>

[Jacques Le Roux]

Hi,

It was mate, actually there was a missing word in my saying, I meant:

    I agree about changing only non idempotent classes in a 1st approach.
    That's obviously _NOT_ service and events, but could be also few helper and worker classes.

All the utility classes should be checked and non idempotent methods (if any) extracted

To be clear: an idempotent class is a class which does not change the state. For utilities That depends on its methods not on the class.

I agree about steps by steps approach

Jacques

Le 23/04/2020 à 06:46, Girish Vasmatkar a écrit :

> Hi
>
> I am unsure if this needs to be extended or applied to the service classes
> because even though the service classes do not appear to maintain state,
> they conceptually relate to the business domain and hence are not a worthy
> candidate. Moreover they are executed within a context and don't qualify as
> typical helper or utility classes.
>
> We should be all for this change but probably exempt service classes from
> it and restrict this change to Helper/Utility classes. Also, it will be
> helpful if we bring this about in phases.
>
> +1 for helper/utility classes.
>
> Best,
> Girish
>
>
>
>
> On Wed, Apr 22, 2020 at 11:55 PM Jacques Le Roux <
> [hidden email]> wrote:
>
>> Le 22/04/2020 à 19:58, Jacques Le Roux a écrit :
>>> I have still to read the articles an understand the Lombok project and
>> how we could possibly use it
>> I'm thinking about https://projectlombok.org/setup/gradle but I have no
>> ideas yet to what it entails, someone knows?
>>
>> Jacques
>>
>>

[Rishi Solanki]

An effort already done for this cleanup -
https://issues.apache.org/jira/browse/OFBIZ-7272

Agree with Girish, we should keep this change for Utility/Helper/Worker
classes. And exclude services for sure, and if any specific event class act
as utility then we can consider it.

Best Regards,
--
Rishi Solanki
*CTO, Mindpath Technology*
Intelligent Solutions
cell: [phone]
LinkedIn <https://www.linkedin.com/in/rishi-solanki-62271b7/>


On Thu, Apr 23, 2020 at 12:39 PM Jacques Le Roux <
[hidden email]> wrote:

> Hi,
>
> It was mate, actually there was a missing word in my saying, I meant:
>
>     I agree about changing only non idempotent classes in a 1st approach.
>     That's obviously _NOT_ service and events, but could be also few
> helper and worker classes.
>
> All the utility classes should be checked and non idempotent methods (if
> any) extracted
>
> To be clear: an idempotent class is a class which does not change the
> state. For utilities That depends on its methods not on the class.
>
> I agree about steps by steps approach
>
> Jacques
>
> Le 23/04/2020 à 06:46, Girish Vasmatkar a écrit :
> > Hi
> >
> > I am unsure if this needs to be extended or applied to the service
> classes
> > because even though the service classes do not appear to maintain state,
> > they conceptually relate to the business domain and hence are not a
> worthy
> > candidate. Moreover they are executed within a context and don't qualify
> as
> > typical helper or utility classes.
> >
> > We should be all for this change but probably exempt service classes from
> > it and restrict this change to Helper/Utility classes. Also, it will be
> > helpful if we bring this about in phases.
> >
> > +1 for helper/utility classes.
> >
> > Best,
> > Girish
> >
> >
> >
> >
> > On Wed, Apr 22, 2020 at 11:55 PM Jacques Le Roux <
> > [hidden email]> wrote:
> >
> >> Le 22/04/2020 à 19:58, Jacques Le Roux a écrit :
> >>> I have still to read the articles an understand the Lombok project and
> >> how we could possibly use it
> >> I'm thinking about https://projectlombok.org/setup/gradle but I have no
> >> ideas yet to what it entails, someone knows?
> >>
> >> Jacques
> >>
> >>
>

[Jacques Le Roux]

Oh indeed, completely forgot about that. So I guess there are not much changes to do?

Jacques

Le 24/04/2020 à 09:43, Rishi Solanki a écrit :

> An effort already done for this cleanup -
> https://issues.apache.org/jira/browse/OFBIZ-7272
>
> Agree with Girish, we should keep this change for Utility/Helper/Worker
> classes. And exclude services for sure, and if any specific event class act
> as utility then we can consider it.
>
> Best Regards,
> --
> Rishi Solanki
> *CTO, Mindpath Technology*
> Intelligent Solutions
> cell: [phone]
> LinkedIn <https://www.linkedin.com/in/rishi-solanki-62271b7/>
>
>
> On Thu, Apr 23, 2020 at 12:39 PM Jacques Le Roux <
> [hidden email]> wrote:
>
>> Hi,
>>
>> It was mate, actually there was a missing word in my saying, I meant:
>>
>>      I agree about changing only non idempotent classes in a 1st approach.
>>      That's obviously _NOT_ service and events, but could be also few
>> helper and worker classes.
>>
>> All the utility classes should be checked and non idempotent methods (if
>> any) extracted
>>
>> To be clear: an idempotent class is a class which does not change the
>> state. For utilities That depends on its methods not on the class.
>>
>> I agree about steps by steps approach
>>
>> Jacques
>>
>> Le 23/04/2020 à 06:46, Girish Vasmatkar a écrit :
>>> Hi
>>>
>>> I am unsure if this needs to be extended or applied to the service
>> classes
>>> because even though the service classes do not appear to maintain state,
>>> they conceptually relate to the business domain and hence are not a
>> worthy
>>> candidate. Moreover they are executed within a context and don't qualify
>> as
>>> typical helper or utility classes.
>>>
>>> We should be all for this change but probably exempt service classes from
>>> it and restrict this change to Helper/Utility classes. Also, it will be
>>> helpful if we bring this about in phases.
>>>
>>> +1 for helper/utility classes.
>>>
>>> Best,
>>> Girish
>>>
>>>
>>>
>>>
>>> On Wed, Apr 22, 2020 at 11:55 PM Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> Le 22/04/2020 à 19:58, Jacques Le Roux a écrit :
>>>>> I have still to read the articles an understand the Lombok project and
>>>> how we could possibly use it
>>>> I'm thinking about https://projectlombok.org/setup/gradle but I have no
>>>> ideas yet to what it entails, someone knows?
>>>>
>>>> Jacques
>>>>
>>>>

[Suraj Khurana-2]

Yes, not much changes to be done after this information from Rishi.

Thanks everyone.

--
Best Regards,
Suraj Khurana
SENIOR TECHNICAL CONSULTANT
mobile: [phone]
email: [hidden email]
*www.hotwax.co <http://www.hotwax.co/>*


On Fri, Apr 24, 2020 at 3:22 PM Jacques Le Roux <
[hidden email]> wrote:

> Oh indeed, completely forgot about that. So I guess there are not much
> changes to do?
>
> Jacques
>
> Le 24/04/2020 à 09:43, Rishi Solanki a écrit :
> > An effort already done for this cleanup -
> > https://issues.apache.org/jira/browse/OFBIZ-7272
> >
> > Agree with Girish, we should keep this change for Utility/Helper/Worker
> > classes. And exclude services for sure, and if any specific event class
> act
> > as utility then we can consider it.
> >
> > Best Regards,
> > --
> > Rishi Solanki
> > *CTO, Mindpath Technology*
> > Intelligent Solutions
> > cell: [phone]
> > LinkedIn <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> >
> >
> > On Thu, Apr 23, 2020 at 12:39 PM Jacques Le Roux <
> > [hidden email]> wrote:
> >
> >> Hi,
> >>
> >> It was mate, actually there was a missing word in my saying, I meant:
> >>
> >>      I agree about changing only non idempotent classes in a 1st
> approach.
> >>      That's obviously _NOT_ service and events, but could be also few
> >> helper and worker classes.
> >>
> >> All the utility classes should be checked and non idempotent methods (if
> >> any) extracted
> >>
> >> To be clear: an idempotent class is a class which does not change the
> >> state. For utilities That depends on its methods not on the class.
> >>
> >> I agree about steps by steps approach
> >>
> >> Jacques
> >>
> >> Le 23/04/2020 à 06:46, Girish Vasmatkar a écrit :
> >>> Hi
> >>>
> >>> I am unsure if this needs to be extended or applied to the service
> >> classes
> >>> because even though the service classes do not appear to maintain
> state,
> >>> they conceptually relate to the business domain and hence are not a
> >> worthy
> >>> candidate. Moreover they are executed within a context and don't
> qualify
> >> as
> >>> typical helper or utility classes.
> >>>
> >>> We should be all for this change but probably exempt service classes
> from
> >>> it and restrict this change to Helper/Utility classes. Also, it will be
> >>> helpful if we bring this about in phases.
> >>>
> >>> +1 for helper/utility classes.
> >>>
> >>> Best,
> >>> Girish
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Apr 22, 2020 at 11:55 PM Jacques Le Roux <
> >>> [hidden email]> wrote:
> >>>
> >>>> Le 22/04/2020 à 19:58, Jacques Le Roux a écrit :
> >>>>> I have still to read the articles an understand the Lombok project
> and
> >>>> how we could possibly use it
> >>>> I'm thinking about https://projectlombok.org/setup/gradle but I have
> no
> >>>> ideas yet to what it entails, someone knows?
> >>>>
> >>>> Jacques
> >>>>
> >>>>
>

[Jacques Le Roux]

Hi Suraj,

Has QAPlug given you information about the classes still to change (of course not services)?

If yes,

 1. we could reopen OFBIZ-7272;
 2. complete the work;
 3. and thought about Lombok integration in Gradle.

Thanks

Jacques

Le 25/04/2020 à 09:58, Suraj Khurana a écrit :

> Yes, not much changes to be done after this information from Rishi.
>
> Thanks everyone.
>
> --
> Best Regards,
> Suraj Khurana
> SENIOR TECHNICAL CONSULTANT
> mobile: [phone]
> email: [hidden email]
> *www.hotwax.co <http://www.hotwax.co/>*
>
>
> On Fri, Apr 24, 2020 at 3:22 PM Jacques Le Roux <
> [hidden email]> wrote:
>
>> Oh indeed, completely forgot about that. So I guess there are not much
>> changes to do?
>>
>> Jacques
>>
>> Le 24/04/2020 à 09:43, Rishi Solanki a écrit :
>>> An effort already done for this cleanup -
>>> https://issues.apache.org/jira/browse/OFBIZ-7272
>>>
>>> Agree with Girish, we should keep this change for Utility/Helper/Worker
>>> classes. And exclude services for sure, and if any specific event class
>> act
>>> as utility then we can consider it.
>>>
>>> Best Regards,
>>> --
>>> Rishi Solanki
>>> *CTO, Mindpath Technology*
>>> Intelligent Solutions
>>> cell: [phone]
>>> LinkedIn <https://www.linkedin.com/in/rishi-solanki-62271b7/>
>>>
>>>
>>> On Thu, Apr 23, 2020 at 12:39 PM Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> Hi,
>>>>
>>>> It was mate, actually there was a missing word in my saying, I meant:
>>>>
>>>>       I agree about changing only non idempotent classes in a 1st
>> approach.
>>>>       That's obviously _NOT_ service and events, but could be also few
>>>> helper and worker classes.
>>>>
>>>> All the utility classes should be checked and non idempotent methods (if
>>>> any) extracted
>>>>
>>>> To be clear: an idempotent class is a class which does not change the
>>>> state. For utilities That depends on its methods not on the class.
>>>>
>>>> I agree about steps by steps approach
>>>>
>>>> Jacques
>>>>
>>>> Le 23/04/2020 à 06:46, Girish Vasmatkar a écrit :
>>>>> Hi
>>>>>
>>>>> I am unsure if this needs to be extended or applied to the service
>>>> classes
>>>>> because even though the service classes do not appear to maintain
>> state,
>>>>> they conceptually relate to the business domain and hence are not a
>>>> worthy
>>>>> candidate. Moreover they are executed within a context and don't
>> qualify
>>>> as
>>>>> typical helper or utility classes.
>>>>>
>>>>> We should be all for this change but probably exempt service classes
>> from
>>>>> it and restrict this change to Helper/Utility classes. Also, it will be
>>>>> helpful if we bring this about in phases.
>>>>>
>>>>> +1 for helper/utility classes.
>>>>>
>>>>> Best,
>>>>> Girish
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 22, 2020 at 11:55 PM Jacques Le Roux <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>> Le 22/04/2020 à 19:58, Jacques Le Roux a écrit :
>>>>>>> I have still to read the articles an understand the Lombok project
>> and
>>>>>> how we could possibly use it
>>>>>> I'm thinking about https://projectlombok.org/setup/gradle but I have
>> no
>>>>>> ideas yet to what it entails, someone knows?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>

[Suraj Khurana-2]

Yes, there are few more classes are reported, they are:

- BillingAccountWorker
- FinAccountHelper
- ConfigXMLReader
- LoginWorker
- ExpressionUiHelper
- JobUtil
- ServiceGroupReader
- ExternalLoginKeysManager (Can be discussed)
- JWTManager (Can be discussed)

We can re-open and create tickets for these remaining classes, for sure we
should think about Lombok integration.

Some other usability issues reported by plugin are related to Constant
Name:
- Like 'resourceError' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$',
this is throughout the framework, in all java classes.
- Final Constants in all JAVA classes should be declared private instead of
public, like MODULE.

I think we can create improvement type tickets for these constant usability
enhancements, if noone has any further concerns and we can improve them
component wise.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Sun, Apr 26, 2020 at 6:01 PM Jacques Le Roux <
[hidden email]> wrote:

> Hi Suraj,
>
> Has QAPlug given you information about the classes still to change (of
> course not services)?
>
> If yes,
>
>  1. we could reopen OFBIZ-7272;
>  2. complete the work;
>  3. and thought about Lombok integration in Gradle.
>
> Thanks
>
> Jacques
>
> Le 25/04/2020 à 09:58, Suraj Khurana a écrit :
> > Yes, not much changes to be done after this information from Rishi.
> >
> > Thanks everyone.
> >
> > --
> > Best Regards,
> > Suraj Khurana
> > SENIOR TECHNICAL CONSULTANT
> > mobile: [phone]
> > email: [hidden email]
> > *www.hotwax.co <http://www.hotwax.co/>*
> >
> >
> > On Fri, Apr 24, 2020 at 3:22 PM Jacques Le Roux <
> > [hidden email]> wrote:
> >
> >> Oh indeed, completely forgot about that. So I guess there are not much
> >> changes to do?
> >>
> >> Jacques
> >>
> >> Le 24/04/2020 à 09:43, Rishi Solanki a écrit :
> >>> An effort already done for this cleanup -
> >>> https://issues.apache.org/jira/browse/OFBIZ-7272
> >>>
> >>> Agree with Girish, we should keep this change for Utility/Helper/Worker
> >>> classes. And exclude services for sure, and if any specific event class
> >> act
> >>> as utility then we can consider it.
> >>>
> >>> Best Regards,
> >>> --
> >>> Rishi Solanki
> >>> *CTO, Mindpath Technology*
> >>> Intelligent Solutions
> >>> cell: [phone]
> >>> LinkedIn <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> >>>
> >>>
> >>> On Thu, Apr 23, 2020 at 12:39 PM Jacques Le Roux <
> >>> [hidden email]> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> It was mate, actually there was a missing word in my saying, I meant:
> >>>>
> >>>>       I agree about changing only non idempotent classes in a 1st
> >> approach.
> >>>>       That's obviously _NOT_ service and events, but could be also few
> >>>> helper and worker classes.
> >>>>
> >>>> All the utility classes should be checked and non idempotent methods
> (if
> >>>> any) extracted
> >>>>
> >>>> To be clear: an idempotent class is a class which does not change the
> >>>> state. For utilities That depends on its methods not on the class.
> >>>>
> >>>> I agree about steps by steps approach
> >>>>
> >>>> Jacques
> >>>>
> >>>> Le 23/04/2020 à 06:46, Girish Vasmatkar a écrit :
> >>>>> Hi
> >>>>>
> >>>>> I am unsure if this needs to be extended or applied to the service
> >>>> classes
> >>>>> because even though the service classes do not appear to maintain
> >> state,
> >>>>> they conceptually relate to the business domain and hence are not a
> >>>> worthy
> >>>>> candidate. Moreover they are executed within a context and don't
> >> qualify
> >>>> as
> >>>>> typical helper or utility classes.
> >>>>>
> >>>>> We should be all for this change but probably exempt service classes
> >> from
> >>>>> it and restrict this change to Helper/Utility classes. Also, it will
> be
> >>>>> helpful if we bring this about in phases.
> >>>>>
> >>>>> +1 for helper/utility classes.
> >>>>>
> >>>>> Best,
> >>>>> Girish
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Apr 22, 2020 at 11:55 PM Jacques Le Roux <
> >>>>> [hidden email]> wrote:
> >>>>>
> >>>>>> Le 22/04/2020 à 19:58, Jacques Le Roux a écrit :
> >>>>>>> I have still to read the articles an understand the Lombok project
> >> and
> >>>>>> how we could possibly use it
> >>>>>> I'm thinking about https://projectlombok.org/setup/gradle but I
> have
> >> no
> >>>>>> ideas yet to what it entails, someone knows?
> >>>>>>
> >>>>>> Jacques
> >>>>>>
> >>>>>>
>