commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [Math] Utilization of Lombok
Date Mon, 28 Sep 2015 17:57:17 GMT


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 <ole.ersoy@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


Mime
View raw message