Re: [math] Exception Design

[luc]

Le 2015-12-23 01:41, Gilles a écrit :

On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:

On 12/22/2015 11:46 AM, Gilles wrote:

Hi.

On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:

On 12/21/2015 06:44 PM, Gilles wrote:

On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:

Hi,

I was considering jumping into the JDKRandomGenerator exception
discussion, but I did not want to hijack it.

Not sure if any of you have had a chance to looks at this:
https://github.com/firefly-math/firefly-math-exceptions/



https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java


[...]

But I did not see how localization is handled.


I did leave localization out.  I think localization was a hard
requirement in earlier versions of CM, but I'm hoping that there is
some flexibility on this


There was not, since I argued many times to leave it out.
So unless you can show practically how it can work, I have my doubts
that we'll be allowed to go forward with this approach.


and that future versions can defer to a
utility that uses the ExceptionTypes Enum instance as the key to 
look

up the internationalized template string.


Looks good.  Where is the code? ;-)


So CM clients would:
catch(MathException e) {
String exceptionTemplate = 
ResourceBundle.getBundle("cm.exception.templates", new Locale("en", 
"US")).getString(e.getType());
String i18Nmessage = buildMessage(exceptionTemplate, 
e.getContext());

...
}

I can prototype that out more.  Just trying to get a feel for how
viable the concept is first.


I'm not sure I understand correctly.
Does that mean that
1. Uncaught exceptions will lead to a message in English?
2. Every "catch" must repeat the same calls (although the arguments are 
likely

   to be the same for all clauses (and for all applications)?

Comparing this with the current behaviour (where the translated message 
String
is created when "e.getLocalizedMessage()" is called) is likely to make 
people

unhappy.


This could be made simpler with some task delegating between user code 
and CM code.

What about :

 interface ExceptionLocalizer {
/** Localize an exception message.
  * @param locale locale to use
  * @param me exception to localize
  * @return localized message for the exception
  */
String localize(Locale locale, MathException me);
 }

and having ExceptionFactory hold a user-provided implementation of this 
interface?


 public class ExceptionFactory {

   private static ExceptionLocalizer localizer = new NoOpLocalizer();

   public static setLocalizer(ExceptionLocalizer l) {
  localizer = l;
   }

   public static String localize(Locale locale, MathException me) {
 return localizer.localize(locale, me);
   }

   /** Default implementation of the localizer that does nothing. */
   private static class NoOpLocalizer implements ExceptionLocalizer {
  /** {@inheritDoc} */
  @Override
  public String localize(MathException me) {
   return me.getMessage();
 }
   }

 }

and MathException could implement both getLocalizedMessage() and
even getMessage(Locale) by delegating to the user code:

  public class MathException {

public String getLocalizedMessage() {
  return ExceptionFactory.localize(Locale.getDefault(), this);
}

public String getMessage(Locale locale) {
  return ExceptionFactory.localize(locale, this);
}

...

  }

One thing that would be nice would be that in addition to the get 
method,

MathException also provides a getKeys to retrieve all keys and a getType
to retrieve the type. The later correspond to the getPatern (or 
getLocalizable)
I asked for a few years ago in ExceptionContext. The point for these 
methods
is that if we provide users a way to retrieve the parameters that were 
used
in the exception construction, then we can delegate localization to 
users
as they can do their own code that will rebuild a complete meaasage as 
they
want. When you have only the keys and they have reused names like 
OPERATOR

or VECTOR, it can't be delegated.

Note that this is independent of the fact there is one or several 
hierarchies.
If there are several ones, the two one-liners above must simply be 
copied

(yeah, code duplication, I know).






I think it satisfies everyone's requirements with:
- A single MathException (No hierarchy)


That would not satisfy everyone. :-!


- The ExceptionTypes Enum contains all the exception types
- The ExceptionTypes Enum 'key' maps to the corresponding message 
1 to 1

- The ExceptionFactory (Utility) throws exceptions, if necessary,
that have always have a single unique root cause, such as NPEs


I was wondering whether the "factory" idea could indeed satisfy
everyone.

Rather than throwing the non-standard "MathException", the factory 
would
generate one of the standard exceptions, constructed with the 
internal

"MathException" as its cause:

I think it's go

Re: [SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

[Ate Douma]

We'll now make a start with executing on the below proposal, moving to Java 8 
first and then introducing JSON datamodel support to replace and drop XML/XPath 
datamodel thereafter.


Regards, Ate

On 2015-12-09 10:15, Ate Douma wrote:

Since early this year the progress and development of Commons SCXML 2.0 has
severely declined because of two major technical hurdles, and thereafter of
both motivation and lack of time:

- The SCXML XML/XPath datamodel support has been dropped from the final
W3C SCXML 1.0 specification [1], because of too many functional and semantic
complications and limitation, as well as lack of interest for implementing it.

The implementation of the XML/XPath datamodel in Commons SCXML has been
problematic for precisely the same reasons.
And not being able to provide such implementation properly by us (Commons
SCXML) actually has been one (final) argument for dropping it from the
specification...

- The implementation of the Javascript datamodel support based on the
old/outdated Rhino Javascript engine in Java 7 and below, turned out to be
quite difficult. While it turns out to be much easier and reliable, but
different, with the new Nashorn Javascript engine in Java 8+.

After bringing this first up on the user@ list earlier this week, I now want to
propose the following major changes to revive the further development towards
Commons SCXML 2.0:
- drop the support for XML/XPath based datamodel, and instead introduce a much
   easier to implement and support JSON datamodel as alternative, for all 
current
   Commons SCXML support 'languages': JEXL, Groovy and Javascript.
- bump the minimum Java version to 8 so we can leverage and only need to support
   the Nashorn Javascript engine

The only user response so far on user@ is fully in favor of these changes,
and both myself and Woonsan Ko are motivated to continue developing and
completing the goals for Commons SCXML 2.0 based on these changes.

If nobody here has strong arguments against the above proposal (and assuming
lazy consensus otherwise), we would like to start on these changes shortly,
before the end of the year.

Kind regards,
Ate Douma
Woonsan Ko

[1] http://www.w3.org/TR/2015/REC-scxml-20150901/



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Exception Design

[Gilles]

Hello.

On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:

Le 2015-12-23 01:41, Gilles a écrit :

On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:

On 12/22/2015 11:46 AM, Gilles wrote:

Hi.
On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:

On 12/21/2015 06:44 PM, Gilles wrote:

On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:

Hi,
I was considering jumping into the JDKRandomGenerator exception
discussion, but I did not want to hijack it.
Not sure if any of you have had a chance to looks at this:
https://github.com/firefly-math/firefly-math-exceptions/



https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java

[...]
But I did not see how localization is handled.

I did leave localization out.  I think localization was a hard
requirement in earlier versions of CM, but I'm hoping that there 
is

some flexibility on this

There was not, since I argued many times to leave it out.
So unless you can show practically how it can work, I have my 
doubts

that we'll be allowed to go forward with this approach.


and that future versions can defer to a
utility that uses the ExceptionTypes Enum instance as the key to 
look

up the internationalized template string.

Looks good.  Where is the code? ;-)

So CM clients would:
catch(MathException e) {
String exceptionTemplate = 
ResourceBundle.getBundle("cm.exception.templates", new Locale("en", 
"US")).getString(e.getType());
String i18Nmessage = buildMessage(exceptionTemplate, 
e.getContext());

...
}
I can prototype that out more.  Just trying to get a feel for how
viable the concept is first.

I'm not sure I understand correctly.
Does that mean that
1. Uncaught exceptions will lead to a message in English?
2. Every "catch" must repeat the same calls (although the arguments 
are likely

   to be the same for all clauses (and for all applications)?
Comparing this with the current behaviour (where the translated 
message String
is created when "e.getLocalizedMessage()" is called) is likely to 
make people

unhappy.


This could be made simpler with some task delegating between user
code and CM code.
What about :

 interface ExceptionLocalizer {
/** Localize an exception message.
  * @param locale locale to use
  * @param me exception to localize
  * @return localized message for the exception
  */
String localize(Locale locale, MathException me);
 }

and having ExceptionFactory hold a user-provided implementation of
this interface?

 public class ExceptionFactory {

   private static ExceptionLocalizer localizer = new NoOpLocalizer();

   public static setLocalizer(ExceptionLocalizer l) {
  localizer = l;
   }


I think that this is potentially dangerous for two reasons (if I'm
not mistaken): it's not thread-safe and it can be called by any
library used by the main application.

I think that the "localizer" instance must be obtained in a way which
the end-user controls.



   public static String localize(Locale locale, MathException me) {
 return localizer.localize(locale, me);
   }

   /** Default implementation of the localizer that does nothing. */
   private static class NoOpLocalizer implements ExceptionLocalizer {
  /** {@inheritDoc} */
  @Override
  public String localize(MathException me) {
   return me.getMessage();
 }
   }

 }

and MathException could implement both getLocalizedMessage() and
even getMessage(Locale) by delegating to the user code:

  public class MathException {

public String getLocalizedMessage() {
  return ExceptionFactory.localize(Locale.getDefault(), this);
}

public String getMessage(Locale locale) {
  return ExceptionFactory.localize(locale, this);
}

...

  }

One thing that would be nice would be that in addition to the get 
method,
MathException also provides a getKeys to retrieve all keys and a 
getType

to retrieve the type. The later correspond to the getPatern (or
getLocalizable)
I asked for a few years ago in ExceptionContext. The point for these 
methods
is that if we provide users a way to retrieve the parameters that 
were used
in the exception construction, then we can delegate localization to 
users
as they can do their own code that will rebuild a complete meaasage 
as they
want. When you have only the keys and they have reused names like 
OPERATOR

or VECTOR, it can't be delegated.


If those are available (as suggested in Ole's example above), would you 
indeed

be OK that localization is not a CM concern anymore?

We could provide code of how to perform the translation in the 
userguide.



Note that this is independent of the fact there is one or several
hierarchies.
If there are several ones, the two one-liners above must simply be 
copied

(yeah, code duplication, I know).






I think it satisfies everyone's requirements with:
- A single MathException (No hierarchy)

That would not satisfy everyone. :-!


- The Exce

Re: [Math] Exceptions from "JDKRandomGenerator"

[Thomas Neidhart]

On 12/21/2015 04:41 AM, Gilles wrote:
> On Sat, 19 Dec 2015 11:35:26 -0700, Phil Steitz wrote:
>> On 12/19/15 9:02 AM, Gilles wrote:
>>> Hi.
>>>
>>> While experimenting on
>>>   https://issues.apache.org/jira/browse/MATH-1300
>>> I created a new
>>>   JDKRandomGeneratorTest
>>> that inherits from
>>>   RandomGeneratorAbstractTest
>>> similarly to the classes for testing all the other RNG implemented
>>> in CM.
>>>
>>> The following tests (implemented in the base class) failed:
>>> 1.
>>>
>>> testNextIntNeg(org.apache.commons.math4.random.JDKRandomGeneratorTest)
>>> Time elapsed: 0.001 sec  <<< ERROR!
>>>java.lang.Exception: Unexpected exception,
>>>
>>> expected
>>>
>>> but was
>>> 2.
>>>
>>> testNextIntIAE2(org.apache.commons.math4.random.JDKRandomGeneratorTest)
>>> Time elapsed: 0.015 sec  <<< ERROR!
>>>java.lang.IllegalArgumentException: bound must be positive
>>>
>>> This is caused by try/catch clauses that expect a
>>> "MathIllegalArgumentException"
>>> but "JDKRandomGenerator" extends "java.util.Random" that for those
>>> methods throws
>>> "IllegalArgumentException".
>>>
>>> What to do?
>>
>> I would change the test to expect IllegalArgumentException.  Most
>> [math] generators actually throw NotStrictlyPositiveException here,
>> which extends MIAE, which extends IAE, so this should work.
> 
> It turns out that, in the master branch, the hierarchy is
> 
>RuntimeException
>  |
>  MathRuntimeException
>  |
>MathIllegalArgumentException
> 
> as per
>   https://issues.apache.org/jira/browse/MATH-853
> 
> [And the Javadoc and "throws" clauses are not yet consistent with this
> in all the code base (e.g. the "RandomGenerator" interface).]
> 
> So, in 4.0, "JDKRandomGenerator" should probably not inherit from
> "java.util.Random" but delegate to it, trap standard exceptions raised,
> and rethrow CM ones.

which is probably a good indication that the current situation in CM4
(as per MATH-853) was not a good design decision.

I applied the changes as I thought the issue was settled, but it turns
out that some of its implications were not fully taken into account.

>From my POV, we should stick to the existing exceptions were applicable,
as this is what people usually expect and is good practice. This means
we should not create our own MathIAE but instead throw a standard IAE. I
understand that the MIAE was created to support the localization of
exception messages, but I wonder if this is really needed in that case.
Usually, when an IAE is thrown it indicates a bug, as the developer did
not provide proper arguments as indicated per javadoc. Now I do not see
the value of being able to localize such exceptions as *only* developers
should ever see them.

For any other exceptions (typically converge exceptions or similar)
which are clearly algorithm dependent, I fully support the design of 1
base MathRuntimeException with localization support.

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

[Gary Gregory]

Go to town! ;-)

G

On Wed, Dec 23, 2015 at 4:00 AM, Ate Douma  wrote:

> We'll now make a start with executing on the below proposal, moving to
> Java 8 first and then introducing JSON datamodel support to replace and
> drop XML/XPath datamodel thereafter.
>
> Regards, Ate
>
>
> On 2015-12-09 10:15, Ate Douma wrote:
>
>> Since early this year the progress and development of Commons SCXML 2.0
>> has
>> severely declined because of two major technical hurdles, and thereafter
>> of
>> both motivation and lack of time:
>>
>> - The SCXML XML/XPath datamodel support has been dropped from the final
>> W3C SCXML 1.0 specification [1], because of too many functional and
>> semantic
>> complications and limitation, as well as lack of interest for
>> implementing it.
>>
>> The implementation of the XML/XPath datamodel in Commons SCXML has been
>> problematic for precisely the same reasons.
>> And not being able to provide such implementation properly by us (Commons
>> SCXML) actually has been one (final) argument for dropping it from the
>> specification...
>>
>> - The implementation of the Javascript datamodel support based on the
>> old/outdated Rhino Javascript engine in Java 7 and below, turned out to be
>> quite difficult. While it turns out to be much easier and reliable, but
>> different, with the new Nashorn Javascript engine in Java 8+.
>>
>> After bringing this first up on the user@ list earlier this week, I now
>> want to
>> propose the following major changes to revive the further development
>> towards
>> Commons SCXML 2.0:
>> - drop the support for XML/XPath based datamodel, and instead introduce a
>> much
>>easier to implement and support JSON datamodel as alternative, for all
>> current
>>Commons SCXML support 'languages': JEXL, Groovy and Javascript.
>> - bump the minimum Java version to 8 so we can leverage and only need to
>> support
>>the Nashorn Javascript engine
>>
>> The only user response so far on user@ is fully in favor of these
>> changes,
>> and both myself and Woonsan Ko are motivated to continue developing and
>> completing the goals for Commons SCXML 2.0 based on these changes.
>>
>> If nobody here has strong arguments against the above proposal (and
>> assuming
>> lazy consensus otherwise), we would like to start on these changes
>> shortly,
>> before the end of the year.
>>
>> Kind regards,
>> Ate Douma
>> Woonsan Ko
>>
>> [1] http://www.w3.org/TR/2015/REC-scxml-20150901/
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Exceptions from "JDKRandomGenerator"

[Gilles]

On Wed, 23 Dec 2015 16:26:52 +0100, Thomas Neidhart wrote:

On 12/21/2015 04:41 AM, Gilles wrote:

On Sat, 19 Dec 2015 11:35:26 -0700, Phil Steitz wrote:

On 12/19/15 9:02 AM, Gilles wrote:

Hi.

While experimenting on
  https://issues.apache.org/jira/browse/MATH-1300
I created a new
  JDKRandomGeneratorTest
that inherits from
  RandomGeneratorAbstractTest
similarly to the classes for testing all the other RNG implemented
in CM.

The following tests (implemented in the base class) failed:
1.


testNextIntNeg(org.apache.commons.math4.random.JDKRandomGeneratorTest)
Time elapsed: 0.001 sec  <<< ERROR!
   java.lang.Exception: Unexpected exception,


expected

but was
2.


testNextIntIAE2(org.apache.commons.math4.random.JDKRandomGeneratorTest)
Time elapsed: 0.015 sec  <<< ERROR!
   java.lang.IllegalArgumentException: bound must be positive

This is caused by try/catch clauses that expect a
"MathIllegalArgumentException"
but "JDKRandomGenerator" extends "java.util.Random" that for those
methods throws
"IllegalArgumentException".

What to do?


I would change the test to expect IllegalArgumentException.  Most
[math] generators actually throw NotStrictlyPositiveException here,
which extends MIAE, which extends IAE, so this should work.


It turns out that, in the master branch, the hierarchy is

   RuntimeException
 |
 MathRuntimeException
 |
   MathIllegalArgumentException

as per
  https://issues.apache.org/jira/browse/MATH-853

[And the Javadoc and "throws" clauses are not yet consistent with 
this

in all the code base (e.g. the "RandomGenerator" interface).]

So, in 4.0, "JDKRandomGenerator" should probably not inherit from
"java.util.Random" but delegate to it, trap standard exceptions 
raised,

and rethrow CM ones.


which is probably a good indication that the current situation in CM4
(as per MATH-853) was not a good design decision.


It was consensual.
What you express below is far more controversial.

I applied the changes as I thought the issue was settled, but it 
turns

out that some of its implications were not fully taken into account.

From my POV, we should stick to the existing exceptions were 
applicable,
as this is what people usually expect and is good practice. This 
means
we should not create our own MathIAE but instead throw a standard 
IAE. I

understand that the MIAE was created to support the localization of
exception messages, but I wonder if this is really needed in that 
case.
Usually, when an IAE is thrown it indicates a bug, as the developer 
did
not provide proper arguments as indicated per javadoc. Now I do not 
see
the value of being able to localize such exceptions as *only* 
developers

should ever see them.


This is a point I made a long time ago (not "in a far, far away 
galaxy").

To which I got the answer that CM must provide a
 * detailed,
 * localizable,
 * textual
error message.

IMO, for a bug pointed to by an IAE, all the developer has to know is 
the

stack trace.

If we want to be "standard", we shouldn't even have to check for null 
or

array length on caller's input data as we know that the JVM will do the
checks and trivially throw standard exceptions on these programming 
errors!


Javadoc and stack trace are necessary and sufficient to fix those bugs.


For any other exceptions (typically converge exceptions or similar)
which are clearly algorithm dependent, I fully support the design of 
1

base MathRuntimeException with localization support.


This is a really tiny subset. Ole's proposal could focus on those few
cases.
For the rest, I'm all for being consistently "standard"; meaning that
in CM we'd write code similar to the following:

/**
 * Comment on "evaluate".
 *
 * @paran n Comment on "n".
 * @return the result.
 * @throws IllegalArgumentException if {@code n <= 0}.
 */
public double evaluate(int n) {
  if (n <= 0) {
throw new IllegalArgumentException("n <= 0");
  }

  return compute(n);
}

KISS.

And if somewhere else there is
  throw new IllegalArgumentException("p <= 0");
I won't consider it duplicate code...


Gilles



Thomas



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Exceptions from "JDKRandomGenerator"

[Thomas Neidhart]

On 12/23/2015 05:39 PM, Gilles wrote:
> On Wed, 23 Dec 2015 16:26:52 +0100, Thomas Neidhart wrote:
>> On 12/21/2015 04:41 AM, Gilles wrote:
>>> On Sat, 19 Dec 2015 11:35:26 -0700, Phil Steitz wrote:
 On 12/19/15 9:02 AM, Gilles wrote:
> Hi.
>
> While experimenting on
>   https://issues.apache.org/jira/browse/MATH-1300
> I created a new
>   JDKRandomGeneratorTest
> that inherits from
>   RandomGeneratorAbstractTest
> similarly to the classes for testing all the other RNG implemented
> in CM.
>
> The following tests (implemented in the base class) failed:
> 1.
>
>
> testNextIntNeg(org.apache.commons.math4.random.JDKRandomGeneratorTest)
> Time elapsed: 0.001 sec  <<< ERROR!
>java.lang.Exception: Unexpected exception,
>
>
> expected
>
>
> but was
> 2.
>
>
> testNextIntIAE2(org.apache.commons.math4.random.JDKRandomGeneratorTest)
>
> Time elapsed: 0.015 sec  <<< ERROR!
>java.lang.IllegalArgumentException: bound must be positive
>
> This is caused by try/catch clauses that expect a
> "MathIllegalArgumentException"
> but "JDKRandomGenerator" extends "java.util.Random" that for those
> methods throws
> "IllegalArgumentException".
>
> What to do?

 I would change the test to expect IllegalArgumentException.  Most
 [math] generators actually throw NotStrictlyPositiveException here,
 which extends MIAE, which extends IAE, so this should work.
>>>
>>> It turns out that, in the master branch, the hierarchy is
>>>
>>>RuntimeException
>>>  |
>>>  MathRuntimeException
>>>  |
>>>MathIllegalArgumentException
>>>
>>> as per
>>>   https://issues.apache.org/jira/browse/MATH-853
>>>
>>> [And the Javadoc and "throws" clauses are not yet consistent with this
>>> in all the code base (e.g. the "RandomGenerator" interface).]
>>>
>>> So, in 4.0, "JDKRandomGenerator" should probably not inherit from
>>> "java.util.Random" but delegate to it, trap standard exceptions raised,
>>> and rethrow CM ones.
>>
>> which is probably a good indication that the current situation in CM4
>> (as per MATH-853) was not a good design decision.
> 
> It was consensual.
> What you express below is far more controversial.
> 
>> I applied the changes as I thought the issue was settled, but it turns
>> out that some of its implications were not fully taken into account.
>>
>> From my POV, we should stick to the existing exceptions were applicable,
>> as this is what people usually expect and is good practice. This means
>> we should not create our own MathIAE but instead throw a standard IAE. I
>> understand that the MIAE was created to support the localization of
>> exception messages, but I wonder if this is really needed in that case.
>> Usually, when an IAE is thrown it indicates a bug, as the developer did
>> not provide proper arguments as indicated per javadoc. Now I do not see
>> the value of being able to localize such exceptions as *only* developers
>> should ever see them.
> 
> This is a point I made a long time ago (not "in a far, far away galaxy").
> To which I got the answer that CM must provide a
>  * detailed,
>  * localizable,
>  * textual
> error message.
> 
> IMO, for a bug pointed to by an IAE, all the developer has to know is the
> stack trace.
> 
> If we want to be "standard", we shouldn't even have to check for null or
> array length on caller's input data as we know that the JVM will do the
> checks and trivially throw standard exceptions on these programming errors!

Checking input parameters and explicitly throwing exceptions *is*
considered to be good practice.

Some of the commons libraries that exist for a very long time do it
differently (especially lang and collections), but this might lead to
inconsistent behavior (check the numerous bug reports related to that)
depending on input. I understand that 15 years ago this was not yet good
practice, but it is nowadays imho.

> Javadoc and stack trace are necessary and sufficient to fix those bugs.

I agree.

>> For any other exceptions (typically converge exceptions or similar)
>> which are clearly algorithm dependent, I fully support the design of 1
>> base MathRuntimeException with localization support.
> 
> This is a really tiny subset. Ole's proposal could focus on those few
> cases.

I think the other existing exceptions and the way we handle localization
is fine, and does not really need a refactoring.

The use-cases provided in Ole's proposal look weird and seem again more
suited for something like spring rather than for a low-level library as
CM. There was the case how spring handles exceptions from hibernate, but
we should compare ourselves not with spring but with hibernate, Just my
2cents.

> For the rest, I'm all for being consistently "standard"; meaning that
> in CM we'd write code similar to the following:
> 
> /**
>  * Comment on "evaluate".
>  *
>

Re: [math] Exception Design

[Ole Ersoy]

[...]



Looks good.  Where is the code? ;-)


So CM clients would:
catch(MathException e) {
String exceptionTemplate = ResourceBundle.getBundle("cm.exception.templates", new 
Locale("en", "US")).getString(e.getType());
String i18Nmessage = buildMessage(exceptionTemplate, e.getContext());
...
}

I can prototype that out more.  Just trying to get a feel for how
viable the concept is first.


I'm not sure I understand correctly.
Does that mean that
1. Uncaught exceptions will lead to a message in English?

Sort of - Right now the exception message is just the Enum 'type/code'.  For 
example: MIA__INTEGER_OVERFLOW.  Calling toString() on the exception will 
produce a more detailed message with the context parameters as well.



2. Every "catch" must repeat the same calls (although the arguments are likely
   to be the same for all clauses (and for all applications)?


Well - Suppose the use case is using CM to just write quick simulations in the 
main block.  We don't want to bother the analyst with what exceptions mean or 
throw catch concepts, etc.  So primarily the user is concerned with the //CM 
code block below:

public static void main(String args[]) {
   //The CM code...
}

So instead of providing the above block as a starting point this block would be 
provided:

public static void main(String args[]) {
   try {
   //The CM code...

} catch(MathException) {
   u.rethrowLocalized(e)
}




Comparing this with the current behaviour (where the translated message String
is created when "e.getLocalizedMessage()" is called) is likely to make people
unhappy.

Hopefully they would be OK with something like the above.  If a single 
MathException is adopted it should be very easy to create a Cheatsheet with all 
the exception codes that can occur in a given scenario along with what it means 
in a language, in addition to handling it with the type of utility describe 
above.  I would think the goal would be to get the user to understand the 
exceptions as they are thrown in Java vernacular though...Even if I see an 
exception message in Norwegian I still need to read the code and Javadoc to 
figure out what it means.

I'm still looking into the possibility of a custom designed annotation to do 
the above utility, but it may require the use of AspectJ or Apache Weaver.





[...]


I'd be interested in settling the matter of whether we must use a single
hierarchy because of technical limitations, or if it is a good solution
on its own, i.e. extending standard exceptions is not a better practice
after all.

I think we understand this, but anything other than a single exception is going 
to introduce a non trivial amount of additional effort both for users, 
maintainers, and documenters.  Consider the ripple effect this has on other 
libraries using CM.





We could provide a utility:

public boolean isMathException(RuntimeException e) {
  if (e instanceof MathException) {
return true;
  }
  final Throwable t = e.getCause();
  if (t != null) {
if (e instanceof MathException) {
  return true;
}
  }
  return false;
}


Or just not wrap.


Of course, but choosing one or the other is not a technical problem;
it's design decision.  Do we have arguments (or reference to them)?


As Luke pointed out, we want to be able to catch the exception and know that it 
came from CM with minimal effort.  If another layer is using CM, then that 
layer should catch the CM exception and rethrow it using a System exception 
providing a global facade the same way Spring does.





public class ExceptionFactory {

  public static void throwIllegalArgumentException(MathException e) {
throw new IllegalArgumentException(e);
  }

  public static void throwNullPointerException(MathException e) {
throw new NullPointerException(e);
  }

  // And so on...
}

So, CM code would be

public class Algo {

  public void evaluate(double value) {
// Check precondition.
final double min = computeMin();
if (value < min) {
  final MathException e = new 
MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, min).put(VALUE, value);
  ExceptionFactory.throwIllegalArgumentException(e);
}

// Precondition OK.
  }
}

Another thing that I hinted to is that the the factory builds in the
precondition check in the throw method.  So that the line:

if (value < min) {

can be nixed.


It seems nice to ensure that the exception raised is consistent with the
checked condition.

That's the idea.


OK, but do you foresee that all precondition checks will be handle by
factory methods.

It would be nice.  Like you said, it's also good if an exception is always 
produced by a globally unique condition.


It would not be so nice to have explicit checks sprinkled here and there.

Indeed.  The single exception design should allow for a factory method for all 
the Enum types.  If it's done right the factory should also make writing the 
utility for localizing messages easier.

[...]

Cheers,
Ole


---

Re: [math] Exception Design

[Ole Ersoy]

[...]

On 12/23/2015 03:38 AM, luc wrote:


 interface ExceptionLocalizer {
/** Localize an exception message.
  * @param locale locale to use
  * @param me exception to localize
  * @return localized message for the exception
  */
String localize(Locale locale, MathException me);
 }

and having ExceptionFactory hold a user-provided implementation of this 
interface?

 public class ExceptionFactory {

   private static ExceptionLocalizer localizer = new NoOpLocalizer();

   public static setLocalizer(ExceptionLocalizer l) {
  localizer = l;
   }

   public static String localize(Locale locale, MathException me) {
 return localizer.localize(locale, me);
   }

   /** Default implementation of the localizer that does nothing. */
   private static class NoOpLocalizer implements ExceptionLocalizer {
  /** {@inheritDoc} */
  @Override
  public String localize(MathException me) {
   return me.getMessage();
 }
   }

 }

and MathException could implement both getLocalizedMessage() and
even getMessage(Locale) by delegating to the user code:

  public class MathException {

public String getLocalizedMessage() {
  return ExceptionFactory.localize(Locale.getDefault(), this);
}

public String getMessage(Locale locale) {
  return ExceptionFactory.localize(locale, this);
}

...

  }


Nice!


One thing that would be nice would be that in addition to the get method,
MathException also provides a getKeys to retrieve all keys and a getType
to retrieve the type.


Just added getKeys() (Line 48):
https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java

getType() already there (Line 29 - @Getter annotation produces the getter)

Also added getMethodName() and getClassName() to get the source of the 
exception.  Since there is only a single exception there is no need to unroll 
it to get the root cause.

[...]

Cheers,
Ole


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Exception Design

[Luc Maisonobe]

Le 23/12/2015 14:32, Gilles a écrit :
> Hello.
> 
> On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:
>> Le 2015-12-23 01:41, Gilles a écrit :
>>> On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:
 On 12/22/2015 11:46 AM, Gilles wrote:
> Hi.
> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>> On 12/21/2015 06:44 PM, Gilles wrote:
>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
 Hi,
 I was considering jumping into the JDKRandomGenerator exception
 discussion, but I did not want to hijack it.
 Not sure if any of you have had a chance to looks at this:
 https://github.com/firefly-math/firefly-math-exceptions/



 https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java

>>> [...]
>>> But I did not see how localization is handled.
>> I did leave localization out.  I think localization was a hard
>> requirement in earlier versions of CM, but I'm hoping that there is
>> some flexibility on this
> There was not, since I argued many times to leave it out.
> So unless you can show practically how it can work, I have my doubts
> that we'll be allowed to go forward with this approach.
>
>> and that future versions can defer to a
>> utility that uses the ExceptionTypes Enum instance as the key to look
>> up the internationalized template string.
> Looks good.  Where is the code? ;-)
 So CM clients would:
 catch(MathException e) {
 String exceptionTemplate =
 ResourceBundle.getBundle("cm.exception.templates", new Locale("en",
 "US")).getString(e.getType());
 String i18Nmessage = buildMessage(exceptionTemplate,
 e.getContext());
 ...
 }
 I can prototype that out more.  Just trying to get a feel for how
 viable the concept is first.
>>> I'm not sure I understand correctly.
>>> Does that mean that
>>> 1. Uncaught exceptions will lead to a message in English?
>>> 2. Every "catch" must repeat the same calls (although the arguments
>>> are likely
>>>to be the same for all clauses (and for all applications)?
>>> Comparing this with the current behaviour (where the translated
>>> message String
>>> is created when "e.getLocalizedMessage()" is called) is likely to
>>> make people
>>> unhappy.
>>
>> This could be made simpler with some task delegating between user
>> code and CM code.
>> What about :
>>
>>  interface ExceptionLocalizer {
>> /** Localize an exception message.
>>   * @param locale locale to use
>>   * @param me exception to localize
>>   * @return localized message for the exception
>>   */
>> String localize(Locale locale, MathException me);
>>  }
>>
>> and having ExceptionFactory hold a user-provided implementation of
>> this interface?
>>
>>  public class ExceptionFactory {
>>
>>private static ExceptionLocalizer localizer = new NoOpLocalizer();
>>
>>public static setLocalizer(ExceptionLocalizer l) {
>>   localizer = l;
>>}
> 
> I think that this is potentially dangerous for two reasons (if I'm
> not mistaken): it's not thread-safe and it can be called by any
> library used by the main application.

Intermedaite libraries could also call it, and I hope they would be
designed to use a consistent way for their own exception (they should
let the user specify the localization mechanism, use it for themselves
and pass the configuration to CM).

Thread safety here is really not a concern (but we could protect it
if desired). This setting is a configuration level setting, it is
usually done once near the beginning of the main program. You don't
change the mechanism every millisecond.

> 
> I think that the "localizer" instance must be obtained in a way which
> the end-user controls.

The user controls it. The setLocalizer method can be called directly by
user, and in fact I expect the user to do it.

> 
>>
>>public static String localize(Locale locale, MathException me) {
>>  return localizer.localize(locale, me);
>>}
>>
>>/** Default implementation of the localizer that does nothing. */
>>private static class NoOpLocalizer implements ExceptionLocalizer {
>>   /** {@inheritDoc} */
>>   @Override
>>   public String localize(MathException me) {
>>return me.getMessage();
>>  }
>>}
>>
>>  }
>>
>> and MathException could implement both getLocalizedMessage() and
>> even getMessage(Locale) by delegating to the user code:
>>
>>   public class MathException {
>>
>> public String getLocalizedMessage() {
>>   return ExceptionFactory.localize(Locale.getDefault(), this);
>> }
>>
>> public String getMessage(Locale locale) {
>>   return ExceptionFactory.localize(locale, this);
>> }
>>
>> ...
>>
>>   }
>>
>> One thing that would be nice would be that in addition to the get method,
>> MathException al

Re: [Math] Exceptions from "JDKRandomGenerator"

[Ole Ersoy]

A few drawbacks to having IAE thrown by CM is that it complicates and blurres 
things for those designing a handler that catches all CM exceptions.  CM 
advertising a factory that throws each exception 'type' under globally unique 
conditions minimizes root cause analysis time and indirection.

This:

  if (n <= 0) {
throw new IllegalArgumentException("n <= 0");
  }

Misses out on the factory benefit of closing over the condition that checks and 
throws the exception.  It also makes the explanation for developing and using 
CM longer...Is it a NOT_STRICTLY_POSITIVE_EXCEPTION or IAE that actually is a 
NOT_STRICTLY_POSITIVE_EXCEPTION exception?

If I know that it's a NOT_STRICTLY_POSITIVE_EXCEPTION then I'm one step ahead.  
Maybe I can simply set the argument to zero and try again, or just throw that 
step away and continue.

If we standardizes on using Factory.checkNotStrictlyPositiveException(key, n) 
the client developer can also grab the key and the n value and reconstruct the 
message.

Also, this:

Factory.checkNotStrictlyPositiveException(key, n)

Is easier, more semantic, less error prone, and faster to write than:

  if (n <= 0) {
throw new IllegalArgumentException("n <= 0");
  }

And it provides more benefits:
- Parameter name(s)
- Parameter values
- More semantic
- Almost instant path to root cause
- Exception thrown by class (One method call - no unrolling of the cause stack)
- Exception thrown by method (One method call - no unrolling of the cause stack)

Also, if CM modularizes, then the Factory approach standardizes exception 
generation and handling across the entire ecosystem.

Cheers,
Ole




On 12/23/2015 10:39 AM, Gilles wrote:

On Wed, 23 Dec 2015 16:26:52 +0100, Thomas Neidhart wrote:

On 12/21/2015 04:41 AM, Gilles wrote:

On Sat, 19 Dec 2015 11:35:26 -0700, Phil Steitz wrote:

On 12/19/15 9:02 AM, Gilles wrote:

Hi.

While experimenting on
  https://issues.apache.org/jira/browse/MATH-1300
I created a new
  JDKRandomGeneratorTest
that inherits from
  RandomGeneratorAbstractTest
similarly to the classes for testing all the other RNG implemented
in CM.

The following tests (implemented in the base class) failed:
1.


testNextIntNeg(org.apache.commons.math4.random.JDKRandomGeneratorTest)
Time elapsed: 0.001 sec  <<< ERROR!
   java.lang.Exception: Unexpected exception,


expected

but was
2.


testNextIntIAE2(org.apache.commons.math4.random.JDKRandomGeneratorTest)
Time elapsed: 0.015 sec  <<< ERROR!
   java.lang.IllegalArgumentException: bound must be positive

This is caused by try/catch clauses that expect a
"MathIllegalArgumentException"
but "JDKRandomGenerator" extends "java.util.Random" that for those
methods throws
"IllegalArgumentException".

What to do?


I would change the test to expect IllegalArgumentException. Most
[math] generators actually throw NotStrictlyPositiveException here,
which extends MIAE, which extends IAE, so this should work.


It turns out that, in the master branch, the hierarchy is

   RuntimeException
 |
 MathRuntimeException
 |
   MathIllegalArgumentException

as per
  https://issues.apache.org/jira/browse/MATH-853

[And the Javadoc and "throws" clauses are not yet consistent with this
in all the code base (e.g. the "RandomGenerator" interface).]

So, in 4.0, "JDKRandomGenerator" should probably not inherit from
"java.util.Random" but delegate to it, trap standard exceptions raised,
and rethrow CM ones.


which is probably a good indication that the current situation in CM4
(as per MATH-853) was not a good design decision.


It was consensual.
What you express below is far more controversial.


I applied the changes as I thought the issue was settled, but it turns
out that some of its implications were not fully taken into account.

From my POV, we should stick to the existing exceptions were applicable,
as this is what people usually expect and is good practice. This means
we should not create our own MathIAE but instead throw a standard IAE. I
understand that the MIAE was created to support the localization of
exception messages, but I wonder if this is really needed in that case.
Usually, when an IAE is thrown it indicates a bug, as the developer did
not provide proper arguments as indicated per javadoc. Now I do not see
the value of being able to localize such exceptions as *only* developers
should ever see them.


This is a point I made a long time ago (not "in a far, far away galaxy").
To which I got the answer that CM must provide a
 * detailed,
 * localizable,
 * textual
error message.

IMO, for a bug pointed to by an IAE, all the developer has to know is the
stack trace.

If we want to be "standard", we shouldn't even have to check for null or
array length on caller's input data as we know that the JVM will do the
checks and trivially throw standard exceptions on these programming errors!

Javadoc and stack trace are necessary and sufficient to fix those bugs.


For any other exceptions (typically converge 

[VOTE] Release commons-io RC2

[Kristian Rosenvold]

We have fixed quite a few bugs and added some significant
enhancements since commons-io was released,
so I would like to release commons-io 2.5

commons-io 2.5 RC2 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/io/ (svn revision   11732)

 Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1136


 Details of changes since 2.4 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/io/RELEASE-NOTES.txt
http://people.apache.org/~krosenvold/commons-io
-2.5-RC2/changes-report.html


 I have tested this with JDK 1.6, 1.7 and 1.8, IBM JDK 1.6, IBM JDK 1.7

Users testing on Windows may want to take note of
https://issues.apache.org/jira/browse/IO-490, which
is an old issue causing intermittent failures on Windows that is unchanged
as of this release.


The tag is here https://svn.apache.org/repos/asf/commons/proper/io/tags/
commons-io-2.5-RC

2
(r1721575)

Site:
 http://people.apache.org/~krosenvold/commons-io-2.5-RC2/

   (note some *relative* links are broken and the 2.5 directories are
   not yet created - these will be OK once the site is deployed)


   Clirr Report (compared to 2.4):
  http://people.apache.org/~krosenvold/commons-io
-2.5-RC2/clirr-report.html



   RAT Report:
  http://people.apache.org/~krosenvold/commons-io
-2.5-RC2/rat-report.html


   KEYS:
   https://www.apache.org/dist/commons/KEYS

   Please review the release candidate and vote.
   This vote will close no sooner that 72 hours from now, i.e. after
 23:00 CET 26-Dec 2015

 [ ] +1 Release these artifacts
 [ ] +0 OK, but...
 [ ] -0 OK, but really should fix...
 [ ] -1 I oppose this release because...


Kristian

Re: [math] Exception Design

[Gilles]

On Wed, 23 Dec 2015 20:18:10 +0100, Luc Maisonobe wrote:

Le 23/12/2015 14:32, Gilles a écrit :

Hello.

On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:

Le 2015-12-23 01:41, Gilles a écrit :

On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:

On 12/22/2015 11:46 AM, Gilles wrote:

Hi.
On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:

On 12/21/2015 06:44 PM, Gilles wrote:

On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:

Hi,
I was considering jumping into the JDKRandomGenerator 
exception

discussion, but I did not want to hijack it.
Not sure if any of you have had a chance to looks at this:
https://github.com/firefly-math/firefly-math-exceptions/




https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java


[...]
But I did not see how localization is handled.

I did leave localization out.  I think localization was a hard
requirement in earlier versions of CM, but I'm hoping that 
there is

some flexibility on this

There was not, since I argued many times to leave it out.
So unless you can show practically how it can work, I have my 
doubts

that we'll be allowed to go forward with this approach.


and that future versions can defer to a
utility that uses the ExceptionTypes Enum instance as the key 
to look

up the internationalized template string.

Looks good.  Where is the code? ;-)

So CM clients would:
catch(MathException e) {
String exceptionTemplate =
ResourceBundle.getBundle("cm.exception.templates", new 
Locale("en",

"US")).getString(e.getType());
String i18Nmessage = buildMessage(exceptionTemplate,
e.getContext());
...
}
I can prototype that out more.  Just trying to get a feel for how
viable the concept is first.

I'm not sure I understand correctly.
Does that mean that
1. Uncaught exceptions will lead to a message in English?
2. Every "catch" must repeat the same calls (although the 
arguments

are likely
   to be the same for all clauses (and for all applications)?
Comparing this with the current behaviour (where the translated
message String
is created when "e.getLocalizedMessage()" is called) is likely to
make people
unhappy.


This could be made simpler with some task delegating between user
code and CM code.
What about :

 interface ExceptionLocalizer {
/** Localize an exception message.
  * @param locale locale to use
  * @param me exception to localize
  * @return localized message for the exception
  */
String localize(Locale locale, MathException me);
 }

and having ExceptionFactory hold a user-provided implementation of
this interface?

 public class ExceptionFactory {

   private static ExceptionLocalizer localizer = new 
NoOpLocalizer();


   public static setLocalizer(ExceptionLocalizer l) {
  localizer = l;
   }


I think that this is potentially dangerous for two reasons (if I'm
not mistaken): it's not thread-safe and it can be called by any
library used by the main application.


Intermedaite libraries could also call it, and I hope they would be
designed to use a consistent way for their own exception (they should
let the user specify the localization mechanism, use it for 
themselves

and pass the configuration to CM).


I'm not sure I follow.

IIUC the implications, libraries should be forbidden to call a method
such as "setLocalizer".

In fact "localizer" should be final. [It could be initialized in a way
similar to what is done by "slf4j".  But this is a lot of work not 
worth

it if we can drop direct support for localiszation in CM.]



Thread safety here is really not a concern (but we could protect it
if desired). This setting is a configuration level setting, it is
usually done once near the beginning of the main program. You don't
change the mechanism every millisecond.



I think that the "localizer" instance must be obtained in a way 
which

the end-user controls.


The user controls it. The setLocalizer method can be called directly 
by

user, and in fact I expect the user to do it.


The user is not in control because any code he calls can override the
setting.



   public static String localize(Locale locale, MathException me) {
 return localizer.localize(locale, me);
   }

   /** Default implementation of the localizer that does nothing. 
*/
   private static class NoOpLocalizer implements ExceptionLocalizer 
{

  /** {@inheritDoc} */
  @Override
  public String localize(MathException me) {
   return me.getMessage();
 }
   }

 }

and MathException could implement both getLocalizedMessage() and
even getMessage(Locale) by delegating to the user code:

  public class MathException {

public String getLocalizedMessage() {
  return ExceptionFactory.localize(Locale.getDefault(), this);
}

public String getMessage(Locale locale) {
  return ExceptionFactory.localize(locale, this);
}

...

  }

One thing that would be nice would be that in addition to the get 
metho

Re: [Math] Exceptions from "JDKRandomGenerator"

[Gilles]

On Wed, 23 Dec 2015 14:08:13 -0600, Ole Ersoy wrote:

A few drawbacks to having IAE thrown by CM is that it complicates and
blurres things for those designing a handler that catches all CM
exceptions.  CM advertising a factory that throws each exception
'type' under globally unique conditions minimizes root cause analysis
time and indirection.

This:

  if (n <= 0) {
throw new IllegalArgumentException("n <= 0");
  }

Misses out on the factory benefit of closing over the condition that
checks and throws the exception.  It also makes the explanation for
developing and using CM longer...Is it a
NOT_STRICTLY_POSITIVE_EXCEPTION or IAE that actually is a
NOT_STRICTLY_POSITIVE_EXCEPTION exception?

If I know that it's a NOT_STRICTLY_POSITIVE_EXCEPTION then I'm one
step ahead.  Maybe I can simply set the argument to zero and try
again, or just throw that step away and continue.


I think that there is a mixing of things:
 1. exception caused by a programming error
 2. exception not caused by a programming error
 3. syntactic sugar (check and throw in one go)

There is the argument that case 1 being a bug, it should not happen and
consequently if an application calls CM with wrong input, it's its 
fault,

not CM's, unless the bug is in CM of course. In either case, the stack
trace pinpoints the bug's location. Once the code is fixed, the 
exception

will not happen again.
Hence why do anything more than throw the exception to stop the code 
where

it is known that there is a problem?
[Arguably, a localized message makes the code harder to debug.]

Using the exception type for control flow is not a good practice. And
assuming that the code can continue after a programming error has been
detected does not look like the best thing to do.

If the error is not a bug, then it makes sense to be able to create a
localized report.

We have to eventually decide whether programming errors _must_ be 
standard

or _can_ be non-standard...


If we standardizes on using
Factory.checkNotStrictlyPositiveException(key, n) the client 
developer

can also grab the key and the n value and reconstruct the message.

Also, this:

Factory.checkNotStrictlyPositiveException(key, n)

Is easier, more semantic, less error prone, and faster to write than:

  if (n <= 0) {
throw new IllegalArgumentException("n <= 0");
  }

And it provides more benefits:
- Parameter name(s)
- Parameter values
- More semantic
- Almost instant path to root cause
- Exception thrown by class (One method call - no unrolling of the
cause stack)
- Exception thrown by method (One method call - no unrolling of the
cause stack)


That's fine with me, as long as all is done so that localization is
gone from CM's main JAR. ;-)


Regards,
Gilles


Also, if CM modularizes, then the Factory approach standardizes
exception generation and handling across the entire ecosystem.

Cheers,
Ole


[...]




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[Math] Commit for MATH-1246 (addition to "JDKRandomGenerator")

[Gilles]

Hi.

In commit f7ab3a70ec426669398b4f16d0f2dd5458d87a2e, a new constructor
was added: "JDKRandomGenerator(int)".

But I think that it should have been "JDKRandomGenerator(long)" as
in the constructor of "java.util.Random".

OK to change?

Regards,
Gilles


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release commons-io RC2

[Gary Gregory]

-1

MD5 and SHA1 sums do not match:

$ md5sum commons-io-2.5-src.zip
75f886de5526b3cc517eaa7b383e57d6 *commons-io-2.5-src.zip

$ cat commons-io-2.5-src.zip.md5
e5844f9b3eaab2f2625da21b9f2e994e

$ sha1sum commons-io-2.5-src.zip
585b0cfe1a6194d40ef70c0ec0b6925bca1856d7 *commons-io-2.5-src.zip

$ cat commons-io-2.5-src.zip.sha1
99b9fac8122d6249e0f958ebaf9e2ab4612845d8

Gary

On Wed, Dec 23, 2015 at 1:14 PM, Kristian Rosenvold 
wrote:

> We have fixed quite a few bugs and added some significant
> enhancements since commons-io was released,
> so I would like to release commons-io 2.5
>
> commons-io 2.5 RC2 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/io/ (svn revision
>  11732)
>
>  Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1136
>
>
>  Details of changes since 2.4 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/io/RELEASE-NOTES.txt
> http://people.apache.org/~krosenvold/commons-io
> -2.5-RC2/changes-report.html
> <
> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/changes-report.html
> >
>
>  I have tested this with JDK 1.6, 1.7 and 1.8, IBM JDK 1.6, IBM JDK 1.7
>
> Users testing on Windows may want to take note of
> https://issues.apache.org/jira/browse/IO-490, which
> is an old issue causing intermittent failures on Windows that is unchanged
> as of this release.
>
>
> The tag is here https://svn.apache.org/repos/asf/commons/proper/io/tags/
> commons-io-2.5-RC
> <
> https://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-2.5-RC1
> >
> 2
> (r1721575)
>
> Site:
>  http://people.apache.org/~krosenvold/commons-io-2.5-RC2/
> 
>(note some *relative* links are broken and the 2.5 directories are
>not yet created - these will be OK once the site is deployed)
>
>
>Clirr Report (compared to 2.4):
>   http://people.apache.org/~krosenvold/commons-io
> -2.5-RC2/clirr-report.html
>  >
>
>
>RAT Report:
>   http://people.apache.org/~krosenvold/commons-io
> -2.5-RC2/rat-report.html
> 
>
>KEYS:
>https://www.apache.org/dist/commons/KEYS
>
>Please review the release candidate and vote.
>This vote will close no sooner that 72 hours from now, i.e. after
>  23:00 CET 26-Dec 2015
>
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
>
>
> Kristian
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[math] LevenbergMarquardt Lombok Generated Configuration Object

[Ole Ersoy]

Hola,

I started working on my LevenbergMarquardt optimizer experiment, and figured 
I'd share the Lombok generated immutable configuration class that I split off 
from the optimizer.  This is only for show...Not trying to restart the lombok 
inclusion in CM discussion.

https://github.com/firefly-math/firefly-math-levenberg-marquardt/blob/master/src/main/java/com/fireflysemantics/math/optimization/LMConfiguration.java

The @Value annotation makes all the fields private and final, generates the 
getters, and the AllArgs constructor.  I attached a static DEFAULT 
configuration instance that I suspect will be used 90% of the time.  All other 
cases are handled by the AllArgs constructor.

Cheers,
Ole


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org