commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From venkatesha murthy <venkateshamurth...@gmail.com>
Subject Re: [Math] Utilization of Lombok
Date Mon, 28 Sep 2015 04:14:53 GMT
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 <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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message