Re: Default constructors in JAVA classes

2020-04-26 Thread Suraj Khurana 
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 <
jacques.le.r...@les7arts.com> 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: +91 9669750002
> > email: suraj.khur...@hotwax.co
> > *www.hotwax.co *
> >
> >
> > On Fri, Apr 24, 2020 at 3:22 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> 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: +91-98932-87847
> >>> LinkedIn 
> >>>
> >>>
> >>> On Thu, Apr 23, 2020 at 12:39 PM Jacques Le Roux <
> >>> jacques.le.r...@les7arts.com> 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 <
> > jacques.le.r...@les7arts.com> 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
> >>
> >>
>

Re: Default constructors in JAVA classes

2020-04-26 Thread 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: +91 9669750002
email: suraj.khur...@hotwax.co
*www.hotwax.co *


On Fri, Apr 24, 2020 at 3:22 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> 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: +91-98932-87847
LinkedIn 


On Thu, Apr 23, 2020 at 12:39 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> 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 <
jacques.le.r...@les7arts.com> 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

Re: Default constructors in JAVA classes

2020-04-25 Thread Suraj Khurana 
Yes, not much changes to be done after this information from Rishi.

Thanks everyone.

--
Best Regards,
Suraj Khurana
SENIOR TECHNICAL CONSULTANT
mobile: +91 9669750002
email: suraj.khur...@hotwax.co
*www.hotwax.co *


On Fri, Apr 24, 2020 at 3:22 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> 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: +91-98932-87847
> > LinkedIn 
> >
> >
> > On Thu, Apr 23, 2020 at 12:39 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> 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 <
> >>> jacques.le.r...@les7arts.com> 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
> 
> 
>

Re: Default constructors in JAVA classes

2020-04-24 Thread 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: +91-98932-87847
LinkedIn 


On Thu, Apr 23, 2020 at 12:39 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> 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 <
jacques.le.r...@les7arts.com> 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

Re: Default constructors in JAVA classes

2020-04-24 Thread 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: +91-98932-87847
LinkedIn 


On Thu, Apr 23, 2020 at 12:39 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> 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 <
> > jacques.le.r...@les7arts.com> 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
> >>
> >>
>

Re: Default constructors in JAVA classes

2020-04-23 Thread 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 <
jacques.le.r...@les7arts.com> 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

Re: Default constructors in JAVA classes

2020-04-22 Thread Girish Vasmatkar 
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 <
jacques.le.r...@les7arts.com> 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
>
>

Re: Default constructors in JAVA classes

2020-04-22 Thread 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

Re: Default constructors in JAVA classes

2020-04-22 Thread 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=4

On Wed, 22 Apr 2020 at 17:38, Daniel Watford  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 
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

Re: Default constructors in JAVA classes

2020-04-22 Thread 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=4

On Wed, 22 Apr 2020 at 17:38, Daniel Watford  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 
> 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

Re: Default constructors in JAVA classes

2020-04-22 Thread 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  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

Default constructors in JAVA classes

2020-04-22 Thread Suraj Khurana 
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