You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ole Ersoy <ol...@gmail.com> on 2015/09/25 15:31:38 UTC
[Math] Utilization of Lombok
Hello,
I'm going to utilize Lombok in a CM design experiment. Once the experiment is done CM can decide if it likes Lombok. I know that CM tries to stay dependency free, so I just want to make clear that Lombok is compile time only:
http://stackoverflow.com/questions/6107197/how-does-lombok-work
Lombok eliminates the need to code boilerplate plate code, like getters, setters, toString(). It can also generate a fluid builder for configuration objects, check for null arguments, etc. It also has an @Synchronized annotation that is an improvement on the synchronized keyword.
Lombok alters the byte code, keeping the source code clean and minimal. The additional generated code and be seen using an Eclipse plugin. So for example when looking at the outline view, you can see the generated getters, etc.
https://standardofnorms.wordpress.com/2013/05/10/reducing-java-boilerplate-code-with-lombok-with-eclipse-installation/
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Utilization of Lombok
Posted by Ole Ersoy <ol...@gmail.com>.
On 09/27/2015 11:14 PM, venkatesha murthy wrote:
> Do we know if lombok is supported on all flavours of java for instance IBM
> JDK, Open JDK , java 8 etc...
>
> Was just thinking of the future proof readiness.
>
> Iam absolutely interested in lombok and even today use it for most demo
> purposes and have been stressing for its use where Oracle JDK is the
> primary use.
>
> however i have always been cautioned/warned in the past of using it in
> production systems due to the lombok non-support on different java
> platforms.
More info here:
http://stackoverflow.com/questions/6107197/how-does-lombok-work
I would still future proof by wrapping the solution in a Docker container when possible.
Cheers,
- Ole
>
> On Fri, Sep 25, 2015 at 11:47 PM, Ole Ersoy <ol...@gmail.com> wrote:
>
>>
>> On 09/25/2015 12:55 PM, Thomas Neidhart wrote:
>>
>>> On 09/25/2015 05:04 PM, Ole Ersoy wrote:
>>>
>>>> Hi Thomas,
>>>>
>>>> On 09/25/2015 08:45 AM, Thomas Neidhart wrote:
>>>>
>>>>> Hi Ole,
>>>>>
>>>>> can you explain why you think that the addition of lombok brings any
>>>>> benefit to our users?
>>>>>
>>>> Sure - I'm looking at the LevenbergMarquardtOptimizer ATM, and it has
>>>> the following set of parameters:
>>>>
>>>> /* configuration parameters */
>>>> /** Positive input variable used in determining the initial step
>>>> bound. */
>>>> private final double initialStepBoundFactor;
>>>> /** Desired relative error in the sum of squares. */
>>>> private final double costRelativeTolerance;
>>>> /** Desired relative error in the approximate solution parameters.
>>>> */
>>>> private final double parRelativeTolerance;
>>>> /** Desired max cosine on the orthogonality between the function
>>>> vector
>>>> * and the columns of the jacobian. */
>>>> private final double orthoTolerance;
>>>> /** Threshold for QR ranking. */
>>>> private final double qrRankingThreshold;
>>>>
>>>> And corresponding getters:
>>>> /**
>>>> * Gets the value of a tuning parameter.
>>>> * @see #withInitialStepBoundFactor(double)
>>>> *
>>>> * @return the parameter's value.
>>>> */
>>>> public double getInitialStepBoundFactor() {
>>>> return initialStepBoundFactor;
>>>> }
>>>>
>>>> /**
>>>> * Gets the value of a tuning parameter.
>>>> * @see #withCostRelativeTolerance(double)
>>>> *
>>>> * @return the parameter's value.
>>>> */
>>>> public double getCostRelativeTolerance() {
>>>> return costRelativeTolerance;
>>>> }
>>>>
>>>> /**
>>>> * Gets the value of a tuning parameter.
>>>> * @see #withParameterRelativeTolerance(double)
>>>> *
>>>> * @return the parameter's value.
>>>> */
>>>> public double getParameterRelativeTolerance() {
>>>> return parRelativeTolerance;
>>>> }
>>>>
>>>> /**
>>>> * Gets the value of a tuning parameter.
>>>> * @see #withOrthoTolerance(double)
>>>> *
>>>> * @return the parameter's value.
>>>> */
>>>> public double getOrthoTolerance() {
>>>> return orthoTolerance;
>>>> }
>>>>
>>>> /**
>>>> * Gets the value of a tuning parameter.
>>>> * @see #withRankingThreshold(double)
>>>> *
>>>> * @return the parameter's value.
>>>> */
>>>> public double getRankingThreshold() {
>>>> return qrRankingThreshold;
>>>> }
>>>>
>>>> Lombok will generate all of these. Eclipse can do the same thing, but
>>>> if we delete one of the parameters, then the corresponding getter also
>>>> has to be deleted. Also Lombok cuts down on the source code noise,
>>>> since it is a byte code generator. The generated code does not appear
>>>> in the source.
>>>>
>>>> Lombok also has a @Builder annotation that can be used to generate a
>>>> inner static builder class that provides a fluent construction API. So
>>>> if we break off the LevenbergMarquardtOptimizer configuration into its
>>>> own class, and generate all the getters and the fluid API, there should
>>>> be substantial code reduction.
>>>>
>>>> Gilles is also working on a snapshot capability for neural nets, and the
>>>> @Synchronized annotation could come in handy here. These are the items
>>>> I have looked at so far.
>>>>
>>>> >From my point of view, lombok can help developers by taking over some
>>>>> tedious tasks, but this is quite irrelevant in the case of CM as the
>>>>> majority of work goes into algorithm design and verification rather
>>>>> than in
>>>>> writing getters/setters (which btw has pretty good IDE support).
>>>>>
>>>> I agree that the majority of time goes into the design of the
>>>> algorithm. For me personally, when I'm looking at code, and it has a
>>>> ton of boilerplate, it does slow my productivity...just because of all
>>>> the noise. I'm happy once I've gotten it as DRY as possible.
>>>>
>>>> The more boilerplate, the more reluctant we are going to be to undertake
>>>> refactoring, and we will make more mistakes (At least I will :) ).
>>>>
>>>> So this
>>>>> would just add additional complexity and the gain is very unclear.
>>>>>
>>>> I think you will find it refreshing once you try it. At this point
>>>> though I just wanted to float the idea. I'll complete the experiment
>>>> and publish the result. At that point we will have a good baseline to
>>>> gage whether adding it will add enough value to offset the cost of
>>>> adding it.
>>>>
>>> Well I know lombok.
>>>
>> Super!
>>
>>> Keep in mind that it is a bit more difficult to integrate it into our
>>> build-chain. As you probably know, in order to generate proper javadoc,
>>> you need to use delombok first to create source files which can be used
>>> for the javadoc process.
>>>
>> I was thinking about that too actually. Here's how I was thinking it
>> could be done in the case of the LevenbergMarquardtOptimizer. First split
>> the configuration piece off. Then javadoc the properties of the
>> configuration only. In the class header explain that the boilerplate has
>> been generated using Lombok and put a reference to it there. If someone is
>> smart enough to figure out how to work with the optimizer, then this should
>> be trivial.
>>
>> So to summarize - move to a process of providing minimal javadoc and zero
>> boilerplate. Explain to users that Lombok is used to facilitate this, so
>> methods that are standard boilerplate, do not have comments. Rely on user
>> documentation and unit test examples to guide users. I think this would be
>> good because it's less Javadoc noise.
>>
>>
>>> In general I do not think that lombok is the right tool for a library
>>> like CM, and I do not know any other library that uses lombok. It
>>> certainly has strengths and uses for application development though.
>>>
>> Totally respect that. I'll try integrating it with the general CM build
>> process for the experiment. Maybe I can work out the kinks.
>>
>> Cheers,
>> - Ole
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Utilization of Lombok
Posted by Thomas Neidhart <th...@gmail.com>.
On 09/28/2015 06:14 AM, venkatesha murthy wrote:
> Do we know if lombok is supported on all flavours of java for instance IBM
> JDK, Open JDK , java 8 etc...
>
> Was just thinking of the future proof readiness.
>
> Iam absolutely interested in lombok and even today use it for most demo
> purposes and have been stressing for its use where Oracle JDK is the
> primary use.
>
> however i have always been cautioned/warned in the past of using it in
> production systems due to the lombok non-support on different java
> platforms.
The resulting byte-code should work with every jvm, but lombok uses
internal compiler APIs to perform the code-injection so it will
certainly not work for all jdks.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Utilization of Lombok
Posted by venkatesha murthy <ve...@gmail.com>.
Do we know if lombok is supported on all flavours of java for instance IBM
JDK, Open JDK , java 8 etc...
Was just thinking of the future proof readiness.
Iam absolutely interested in lombok and even today use it for most demo
purposes and have been stressing for its use where Oracle JDK is the
primary use.
however i have always been cautioned/warned in the past of using it in
production systems due to the lombok non-support on different java
platforms.
On Fri, Sep 25, 2015 at 11:47 PM, Ole Ersoy <ol...@gmail.com> wrote:
>
>
> On 09/25/2015 12:55 PM, Thomas Neidhart wrote:
>
>> On 09/25/2015 05:04 PM, Ole Ersoy wrote:
>>
>>> Hi Thomas,
>>>
>>> On 09/25/2015 08:45 AM, Thomas Neidhart wrote:
>>>
>>>> Hi Ole,
>>>>
>>>> can you explain why you think that the addition of lombok brings any
>>>> benefit to our users?
>>>>
>>> Sure - I'm looking at the LevenbergMarquardtOptimizer ATM, and it has
>>> the following set of parameters:
>>>
>>> /* configuration parameters */
>>> /** Positive input variable used in determining the initial step
>>> bound. */
>>> private final double initialStepBoundFactor;
>>> /** Desired relative error in the sum of squares. */
>>> private final double costRelativeTolerance;
>>> /** Desired relative error in the approximate solution parameters.
>>> */
>>> private final double parRelativeTolerance;
>>> /** Desired max cosine on the orthogonality between the function
>>> vector
>>> * and the columns of the jacobian. */
>>> private final double orthoTolerance;
>>> /** Threshold for QR ranking. */
>>> private final double qrRankingThreshold;
>>>
>>> And corresponding getters:
>>> /**
>>> * Gets the value of a tuning parameter.
>>> * @see #withInitialStepBoundFactor(double)
>>> *
>>> * @return the parameter's value.
>>> */
>>> public double getInitialStepBoundFactor() {
>>> return initialStepBoundFactor;
>>> }
>>>
>>> /**
>>> * Gets the value of a tuning parameter.
>>> * @see #withCostRelativeTolerance(double)
>>> *
>>> * @return the parameter's value.
>>> */
>>> public double getCostRelativeTolerance() {
>>> return costRelativeTolerance;
>>> }
>>>
>>> /**
>>> * Gets the value of a tuning parameter.
>>> * @see #withParameterRelativeTolerance(double)
>>> *
>>> * @return the parameter's value.
>>> */
>>> public double getParameterRelativeTolerance() {
>>> return parRelativeTolerance;
>>> }
>>>
>>> /**
>>> * Gets the value of a tuning parameter.
>>> * @see #withOrthoTolerance(double)
>>> *
>>> * @return the parameter's value.
>>> */
>>> public double getOrthoTolerance() {
>>> return orthoTolerance;
>>> }
>>>
>>> /**
>>> * Gets the value of a tuning parameter.
>>> * @see #withRankingThreshold(double)
>>> *
>>> * @return the parameter's value.
>>> */
>>> public double getRankingThreshold() {
>>> return qrRankingThreshold;
>>> }
>>>
>>> Lombok will generate all of these. Eclipse can do the same thing, but
>>> if we delete one of the parameters, then the corresponding getter also
>>> has to be deleted. Also Lombok cuts down on the source code noise,
>>> since it is a byte code generator. The generated code does not appear
>>> in the source.
>>>
>>> Lombok also has a @Builder annotation that can be used to generate a
>>> inner static builder class that provides a fluent construction API. So
>>> if we break off the LevenbergMarquardtOptimizer configuration into its
>>> own class, and generate all the getters and the fluid API, there should
>>> be substantial code reduction.
>>>
>>> Gilles is also working on a snapshot capability for neural nets, and the
>>> @Synchronized annotation could come in handy here. These are the items
>>> I have looked at so far.
>>>
>>> >From my point of view, lombok can help developers by taking over some
>>>> tedious tasks, but this is quite irrelevant in the case of CM as the
>>>> majority of work goes into algorithm design and verification rather
>>>> than in
>>>> writing getters/setters (which btw has pretty good IDE support).
>>>>
>>> I agree that the majority of time goes into the design of the
>>> algorithm. For me personally, when I'm looking at code, and it has a
>>> ton of boilerplate, it does slow my productivity...just because of all
>>> the noise. I'm happy once I've gotten it as DRY as possible.
>>>
>>> The more boilerplate, the more reluctant we are going to be to undertake
>>> refactoring, and we will make more mistakes (At least I will :) ).
>>>
>>> So this
>>>> would just add additional complexity and the gain is very unclear.
>>>>
>>> I think you will find it refreshing once you try it. At this point
>>> though I just wanted to float the idea. I'll complete the experiment
>>> and publish the result. At that point we will have a good baseline to
>>> gage whether adding it will add enough value to offset the cost of
>>> adding it.
>>>
>> Well I know lombok.
>>
> Super!
>
>>
>> Keep in mind that it is a bit more difficult to integrate it into our
>> build-chain. As you probably know, in order to generate proper javadoc,
>> you need to use delombok first to create source files which can be used
>> for the javadoc process.
>>
> I was thinking about that too actually. Here's how I was thinking it
> could be done in the case of the LevenbergMarquardtOptimizer. First split
> the configuration piece off. Then javadoc the properties of the
> configuration only. In the class header explain that the boilerplate has
> been generated using Lombok and put a reference to it there. If someone is
> smart enough to figure out how to work with the optimizer, then this should
> be trivial.
>
> So to summarize - move to a process of providing minimal javadoc and zero
> boilerplate. Explain to users that Lombok is used to facilitate this, so
> methods that are standard boilerplate, do not have comments. Rely on user
> documentation and unit test examples to guide users. I think this would be
> good because it's less Javadoc noise.
>
>
>> In general I do not think that lombok is the right tool for a library
>> like CM, and I do not know any other library that uses lombok. It
>> certainly has strengths and uses for application development though.
>>
> Totally respect that. I'll try integrating it with the general CM build
> process for the experiment. Maybe I can work out the kinks.
>
> Cheers,
> - Ole
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Utilization of Lombok
Posted by Ole Ersoy <ol...@gmail.com>.
On 09/25/2015 12:55 PM, Thomas Neidhart wrote:
> On 09/25/2015 05:04 PM, Ole Ersoy wrote:
>> Hi Thomas,
>>
>> On 09/25/2015 08:45 AM, Thomas Neidhart wrote:
>>> Hi Ole,
>>>
>>> can you explain why you think that the addition of lombok brings any
>>> benefit to our users?
>> Sure - I'm looking at the LevenbergMarquardtOptimizer ATM, and it has
>> the following set of parameters:
>>
>> /* configuration parameters */
>> /** Positive input variable used in determining the initial step
>> bound. */
>> private final double initialStepBoundFactor;
>> /** Desired relative error in the sum of squares. */
>> private final double costRelativeTolerance;
>> /** Desired relative error in the approximate solution parameters. */
>> private final double parRelativeTolerance;
>> /** Desired max cosine on the orthogonality between the function vector
>> * and the columns of the jacobian. */
>> private final double orthoTolerance;
>> /** Threshold for QR ranking. */
>> private final double qrRankingThreshold;
>>
>> And corresponding getters:
>> /**
>> * Gets the value of a tuning parameter.
>> * @see #withInitialStepBoundFactor(double)
>> *
>> * @return the parameter's value.
>> */
>> public double getInitialStepBoundFactor() {
>> return initialStepBoundFactor;
>> }
>>
>> /**
>> * Gets the value of a tuning parameter.
>> * @see #withCostRelativeTolerance(double)
>> *
>> * @return the parameter's value.
>> */
>> public double getCostRelativeTolerance() {
>> return costRelativeTolerance;
>> }
>>
>> /**
>> * Gets the value of a tuning parameter.
>> * @see #withParameterRelativeTolerance(double)
>> *
>> * @return the parameter's value.
>> */
>> public double getParameterRelativeTolerance() {
>> return parRelativeTolerance;
>> }
>>
>> /**
>> * Gets the value of a tuning parameter.
>> * @see #withOrthoTolerance(double)
>> *
>> * @return the parameter's value.
>> */
>> public double getOrthoTolerance() {
>> return orthoTolerance;
>> }
>>
>> /**
>> * Gets the value of a tuning parameter.
>> * @see #withRankingThreshold(double)
>> *
>> * @return the parameter's value.
>> */
>> public double getRankingThreshold() {
>> return qrRankingThreshold;
>> }
>>
>> Lombok will generate all of these. Eclipse can do the same thing, but
>> if we delete one of the parameters, then the corresponding getter also
>> has to be deleted. Also Lombok cuts down on the source code noise,
>> since it is a byte code generator. The generated code does not appear
>> in the source.
>>
>> Lombok also has a @Builder annotation that can be used to generate a
>> inner static builder class that provides a fluent construction API. So
>> if we break off the LevenbergMarquardtOptimizer configuration into its
>> own class, and generate all the getters and the fluid API, there should
>> be substantial code reduction.
>>
>> Gilles is also working on a snapshot capability for neural nets, and the
>> @Synchronized annotation could come in handy here. These are the items
>> I have looked at so far.
>>
>>> >From my point of view, lombok can help developers by taking over some
>>> tedious tasks, but this is quite irrelevant in the case of CM as the
>>> majority of work goes into algorithm design and verification rather
>>> than in
>>> writing getters/setters (which btw has pretty good IDE support).
>> I agree that the majority of time goes into the design of the
>> algorithm. For me personally, when I'm looking at code, and it has a
>> ton of boilerplate, it does slow my productivity...just because of all
>> the noise. I'm happy once I've gotten it as DRY as possible.
>>
>> The more boilerplate, the more reluctant we are going to be to undertake
>> refactoring, and we will make more mistakes (At least I will :) ).
>>
>>> So this
>>> would just add additional complexity and the gain is very unclear.
>> I think you will find it refreshing once you try it. At this point
>> though I just wanted to float the idea. I'll complete the experiment
>> and publish the result. At that point we will have a good baseline to
>> gage whether adding it will add enough value to offset the cost of
>> adding it.
> Well I know lombok.
Super!
>
> Keep in mind that it is a bit more difficult to integrate it into our
> build-chain. As you probably know, in order to generate proper javadoc,
> you need to use delombok first to create source files which can be used
> for the javadoc process.
I was thinking about that too actually. Here's how I was thinking it could be done in the case of the LevenbergMarquardtOptimizer. First split the configuration piece off. Then javadoc the properties of the configuration only. In the class header explain that the boilerplate has been generated using Lombok and put a reference to it there. If someone is smart enough to figure out how to work with the optimizer, then this should be trivial.
So to summarize - move to a process of providing minimal javadoc and zero boilerplate. Explain to users that Lombok is used to facilitate this, so methods that are standard boilerplate, do not have comments. Rely on user documentation and unit test examples to guide users. I think this would be good because it's less Javadoc noise.
>
> In general I do not think that lombok is the right tool for a library
> like CM, and I do not know any other library that uses lombok. It
> certainly has strengths and uses for application development though.
Totally respect that. I'll try integrating it with the general CM build process for the experiment. Maybe I can work out the kinks.
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Utilization of Lombok
Posted by Thomas Neidhart <th...@gmail.com>.
On 09/25/2015 05:04 PM, Ole Ersoy wrote:
> Hi Thomas,
>
> On 09/25/2015 08:45 AM, Thomas Neidhart wrote:
>> Hi Ole,
>>
>> can you explain why you think that the addition of lombok brings any
>> benefit to our users?
> Sure - I'm looking at the LevenbergMarquardtOptimizer ATM, and it has
> the following set of parameters:
>
> /* configuration parameters */
> /** Positive input variable used in determining the initial step
> bound. */
> private final double initialStepBoundFactor;
> /** Desired relative error in the sum of squares. */
> private final double costRelativeTolerance;
> /** Desired relative error in the approximate solution parameters. */
> private final double parRelativeTolerance;
> /** Desired max cosine on the orthogonality between the function vector
> * and the columns of the jacobian. */
> private final double orthoTolerance;
> /** Threshold for QR ranking. */
> private final double qrRankingThreshold;
>
> And corresponding getters:
> /**
> * Gets the value of a tuning parameter.
> * @see #withInitialStepBoundFactor(double)
> *
> * @return the parameter's value.
> */
> public double getInitialStepBoundFactor() {
> return initialStepBoundFactor;
> }
>
> /**
> * Gets the value of a tuning parameter.
> * @see #withCostRelativeTolerance(double)
> *
> * @return the parameter's value.
> */
> public double getCostRelativeTolerance() {
> return costRelativeTolerance;
> }
>
> /**
> * Gets the value of a tuning parameter.
> * @see #withParameterRelativeTolerance(double)
> *
> * @return the parameter's value.
> */
> public double getParameterRelativeTolerance() {
> return parRelativeTolerance;
> }
>
> /**
> * Gets the value of a tuning parameter.
> * @see #withOrthoTolerance(double)
> *
> * @return the parameter's value.
> */
> public double getOrthoTolerance() {
> return orthoTolerance;
> }
>
> /**
> * Gets the value of a tuning parameter.
> * @see #withRankingThreshold(double)
> *
> * @return the parameter's value.
> */
> public double getRankingThreshold() {
> return qrRankingThreshold;
> }
>
> Lombok will generate all of these. Eclipse can do the same thing, but
> if we delete one of the parameters, then the corresponding getter also
> has to be deleted. Also Lombok cuts down on the source code noise,
> since it is a byte code generator. The generated code does not appear
> in the source.
>
> Lombok also has a @Builder annotation that can be used to generate a
> inner static builder class that provides a fluent construction API. So
> if we break off the LevenbergMarquardtOptimizer configuration into its
> own class, and generate all the getters and the fluid API, there should
> be substantial code reduction.
>
> Gilles is also working on a snapshot capability for neural nets, and the
> @Synchronized annotation could come in handy here. These are the items
> I have looked at so far.
>
>>
>> >From my point of view, lombok can help developers by taking over some
>> tedious tasks, but this is quite irrelevant in the case of CM as the
>> majority of work goes into algorithm design and verification rather
>> than in
>> writing getters/setters (which btw has pretty good IDE support).
>
> I agree that the majority of time goes into the design of the
> algorithm. For me personally, when I'm looking at code, and it has a
> ton of boilerplate, it does slow my productivity...just because of all
> the noise. I'm happy once I've gotten it as DRY as possible.
>
> The more boilerplate, the more reluctant we are going to be to undertake
> refactoring, and we will make more mistakes (At least I will :) ).
>
>> So this
>> would just add additional complexity and the gain is very unclear.
> I think you will find it refreshing once you try it. At this point
> though I just wanted to float the idea. I'll complete the experiment
> and publish the result. At that point we will have a good baseline to
> gage whether adding it will add enough value to offset the cost of
> adding it.
Well I know lombok.
Keep in mind that it is a bit more difficult to integrate it into our
build-chain. As you probably know, in order to generate proper javadoc,
you need to use delombok first to create source files which can be used
for the javadoc process.
In general I do not think that lombok is the right tool for a library
like CM, and I do not know any other library that uses lombok. It
certainly has strengths and uses for application development though.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Utilization of Lombok
Posted by Ole Ersoy <ol...@gmail.com>.
Hi Thomas,
On 09/25/2015 08:45 AM, Thomas Neidhart wrote:
> Hi Ole,
>
> can you explain why you think that the addition of lombok brings any
> benefit to our users?
Sure - I'm looking at the LevenbergMarquardtOptimizer ATM, and it has the following set of parameters:
/* configuration parameters */
/** Positive input variable used in determining the initial step bound. */
private final double initialStepBoundFactor;
/** Desired relative error in the sum of squares. */
private final double costRelativeTolerance;
/** Desired relative error in the approximate solution parameters. */
private final double parRelativeTolerance;
/** Desired max cosine on the orthogonality between the function vector
* and the columns of the jacobian. */
private final double orthoTolerance;
/** Threshold for QR ranking. */
private final double qrRankingThreshold;
And corresponding getters:
/**
* Gets the value of a tuning parameter.
* @see #withInitialStepBoundFactor(double)
*
* @return the parameter's value.
*/
public double getInitialStepBoundFactor() {
return initialStepBoundFactor;
}
/**
* Gets the value of a tuning parameter.
* @see #withCostRelativeTolerance(double)
*
* @return the parameter's value.
*/
public double getCostRelativeTolerance() {
return costRelativeTolerance;
}
/**
* Gets the value of a tuning parameter.
* @see #withParameterRelativeTolerance(double)
*
* @return the parameter's value.
*/
public double getParameterRelativeTolerance() {
return parRelativeTolerance;
}
/**
* Gets the value of a tuning parameter.
* @see #withOrthoTolerance(double)
*
* @return the parameter's value.
*/
public double getOrthoTolerance() {
return orthoTolerance;
}
/**
* Gets the value of a tuning parameter.
* @see #withRankingThreshold(double)
*
* @return the parameter's value.
*/
public double getRankingThreshold() {
return qrRankingThreshold;
}
Lombok will generate all of these. Eclipse can do the same thing, but if we delete one of the parameters, then the corresponding getter also has to be deleted. Also Lombok cuts down on the source code noise, since it is a byte code generator. The generated code does not appear in the source.
Lombok also has a @Builder annotation that can be used to generate a inner static builder class that provides a fluent construction API. So if we break off the LevenbergMarquardtOptimizer configuration into its own class, and generate all the getters and the fluid API, there should be substantial code reduction.
Gilles is also working on a snapshot capability for neural nets, and the @Synchronized annotation could come in handy here. These are the items I have looked at so far.
>
> >From my point of view, lombok can help developers by taking over some
> tedious tasks, but this is quite irrelevant in the case of CM as the
> majority of work goes into algorithm design and verification rather than in
> writing getters/setters (which btw has pretty good IDE support).
I agree that the majority of time goes into the design of the algorithm. For me personally, when I'm looking at code, and it has a ton of boilerplate, it does slow my productivity...just because of all the noise. I'm happy once I've gotten it as DRY as possible.
The more boilerplate, the more reluctant we are going to be to undertake refactoring, and we will make more mistakes (At least I will :) ).
> So this
> would just add additional complexity and the gain is very unclear.
I think you will find it refreshing once you try it. At this point though I just wanted to float the idea. I'll complete the experiment and publish the result. At that point we will have a good baseline to gage whether adding it will add enough value to offset the cost of adding it.
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Utilization of Lombok
Posted by Thomas Neidhart <th...@gmail.com>.
Hi Ole,
can you explain why you think that the addition of lombok brings any
benefit to our users?
>From my point of view, lombok can help developers by taking over some
tedious tasks, but this is quite irrelevant in the case of CM as the
majority of work goes into algorithm design and verification rather than in
writing getters/setters (which btw has pretty good IDE support). So this
would just add additional complexity and the gain is very unclear.
Thomas
On Fri, Sep 25, 2015 at 3:31 PM, Ole Ersoy <ol...@gmail.com> wrote:
> Hello,
>
> I'm going to utilize Lombok in a CM design experiment. Once the
> experiment is done CM can decide if it likes Lombok. I know that CM tries
> to stay dependency free, so I just want to make clear that Lombok is
> compile time only:
> http://stackoverflow.com/questions/6107197/how-does-lombok-work
>
> Lombok eliminates the need to code boilerplate plate code, like getters,
> setters, toString(). It can also generate a fluid builder for
> configuration objects, check for null arguments, etc. It also has an
> @Synchronized annotation that is an improvement on the synchronized keyword.
>
> Lombok alters the byte code, keeping the source code clean and minimal.
> The additional generated code and be seen using an Eclipse plugin. So for
> example when looking at the outline view, you can see the generated
> getters, etc.
>
>
> https://standardofnorms.wordpress.com/2013/05/10/reducing-java-boilerplate-code-with-lombok-with-eclipse-installation/
>
> Cheers,
> - Ole
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>