Re: Default constructors in JAVA classes

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

Re: Default constructors in JAVA classes

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

Re: Default constructors in JAVA classes

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

Re: Default constructors in JAVA classes

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/Hel

Re: Default constructors in JAVA classes

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

Re: Default constructors in JAVA classes

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 id

Re: Default constructors in JAVA classes

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

Re: Default constructors in JAVA classes

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

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 r

Re: Default constructors in JAVA classes

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 wrote: > Hi Suraj, > > If the class author's intention was to create a utility c

Re: Default constructors in JAVA classes

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 Effect

Default constructors in JAVA classes

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 i