Re: [VOTE] Release commons-io RC2

[Kristian Rosenvold]

Using all my klutzy 10 thumbs I re-added the checksums in r11735, which
should fix the problem and allow the vote to proceed.


Kristian

2015-12-24 4:19 GMT+01:00 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
> > <
> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/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
>

Re: [math] Exception Design

[Luc Maisonobe]

Le 24/12/2015 01:41, Gilles a écrit :
> 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".

It's a design choice for the upper libraries, not for CM.

> 
> 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.]

This would be over-engineering IMHO. From a theoretical point of view,
yes it would be cleaner, but this is really nitpicking. Documenting
proper use case seems sufficient.

> 
>>
>> 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
> sett

Re: [math] Exception Design

[Gilles]

On Thu, 24 Dec 2015 09:36:34 +0100, Luc Maisonobe wrote:

Le 24/12/2015 01:41, Gilles a écrit :

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".


It's a design choice for the upper libraries, not for CM.


Not for upper libraries, only for the user!

Anyway, the design choice at CM level is: localization or not?

My opinion is that a low-level component should not do localization.

If the exception is a programming error, it is a bug (bad input
provided by the caller).
When something like that is encountered, the stack trace must be
reported to the caller of the method that triggered the exception
(either application developer, or CM developer).
I'm sure that a localized detailed message is a nuisance to the
people who have to debug (what if we provided e.g. Chinese
translations?).

If people feel that an operator cannot see a CM message in English
on his console, what do they do to prevent the JVM to show them?

For the few cases in CM that cannot be safe-guarded by precondition
checks, it's less clear-cut.
But I still think that localization is a job for a wrapper.
I.e. if CM would throw an exception instance whose type is a one-to-one
mapping to a cause, the wrapper has all the info to make a full report
(in any language).



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

Re: [math] Exception Design

[Gilles]

Hi Ole.

At this point in time, there are still incompatible views on the
purpose of an "exception framework" in the context of a library
like CM.

Perhaps you could restate your proposal (on another thread?), and
ask explicitly if people agree with the principle.

If in the affirmative, you should then open an issue on JIRA and
prepare a patch for the master branch, in order to ensure that
there is no hidden problem.


Thanks,
Gilles


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

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

[Gilles]

On Thu, 24 Dec 2015 02:43:10 +0100, Gilles wrote:

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?


Done in commit eca374db08ffbb3dd8de746632fbd74acb8f2c92 ("master" 
branch).


Regards,
Gilles


-
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 24/12/2015 14:13, Gilles a écrit :
> On Thu, 24 Dec 2015 09:36:34 +0100, Luc Maisonobe wrote:
>> Le 24/12/2015 01:41, Gilles a écrit :
>>> 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".
>>
>> It's a design choice for the upper libraries, not for CM.
> 
> Not for upper libraries, only for the user!
> 
> Anyway, the design choice at CM level is: localization or not?
> 
> My opinion is that a low-level component should not do localization.
> 
> If the exception is a programming error, it is a bug (bad input
> provided by the caller).
> When something like that is encountered, the stack trace must be
> reported to the caller of the method that triggered the exception
> (either application developer, or CM developer).
> I'm sure that a localized detailed message is a nuisance to the
> people who have to debug (what if we provided e.g. Chinese
> translations?).

Re: [VOTE] Release commons-io RC2

[Gary Gregory]

+1

ASC, MD5, and SHA1 OK.

Reports OK.

The links in
https://people.apache.org/~krosenvold/commons-io-2.5-RC2/checkstyle.html
are broken:

- 
file:///E:/temp/rc/commons-io-2.5-src/commons-io-2.5-src/target/site/xref/src/main/java/org/apache/commons/io/output/WriterOutputStream.html#L313
- 
file:///E:/temp/rc/commons-io-2.5-src/commons-io-2.5-src/target/site/xref/src/main/java/org/apache/commons/io/output/WriterOutputStream.html#L314

Tested with:

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9\bin\..
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

The site build fails with Java 8 (known issue IIRC).

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on
project commons-io: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.4:site failed: Invalid byte
tag in constant pool: 15
-> [Help 1]

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

Re: [math] Exception Design

[Ole Ersoy]

Hi Gilles,

It sounds like we're starting to coalesce on this.  Hopefully this is not going 
to come as too much of a shock :).  [1]  The exception patch will permeate 
every class that throws an exception.  We will have to delete all the other 
exception and replace them with MathException.  Here's an example from the 
ArithmeticUtils refactoring:

https://github.com/firefly-math/firefly-math-arithmetic/blob/master/src/main/java/com/fireflysemantics/math/arithmetic/Arithmetic.java#L582

Notice that the Javadoc has 2 throws declarations containing the same exception 
using different exception types.

Luc - I think the localization design your created is as elegant as can be.  As 
far as productivity goes the ExceptionFactory class utilization pattern remains 
unchanged.  I feel like we just got done stacking 50 wine classes, and I'm not 
sure I want to move anything, unless I just throw a fork wrench at it in [1] 
above :).

So suppose we include the MathException with localization.  If anyone is a 
super purist (Like me) they can just remove the 6 lines of localization code.  
Reinstall.  Done.  So from a practical point of view it's about as trivial as 
it gets.

So the only thing that bugs me about it is that others looking at CM might have the 
"Why is there localization code in the exception" reaction.  And maybe there is 
a good reason for that, but having looked at the threads so far, it's not obvious to me 
that there is.

For example say we have an application exists that throws at 10,000 different 
points in the App without catching.  So I'm guessing either a server web app or 
just some app we run from the console. We get a stack trace.  Most of it is in 
English right (Java vernacular)?  So my gut reaction is that if someone gives 
me a technical manual in Greek, and it has one sentence in English, that's not 
so helpful.  This is Java and Math combined.  Anyone looking at it is probably 
very smart, very confused, or asleep.

Also, the documentation will be updated to say that in order to get translated 
exception messages, before using CM, set this property on this class.  Or it 
could say:

---

In order to translate exception put the following try catch block at the root 
entry point to your application:

try {
   Application.run()
} catch(MathException e) {
u.translate(e)
}

This has the same effect, but I think it's a better pattern for developers in general.  
The functionality for `u.translate(e)` can be provided in a separate module.  You can do 
more than just translate the exception.  Move it to a central logging server, etc. I also 
think makes CM look "Sharper" by advertising the above usage pattern, although 
everyone knows it's fairly amazing as is.

Cheers,
Ole




On 12/24/2015 08:06 AM, Gilles wrote:

Hi Ole.

At this point in time, there are still incompatible views on the
purpose of an "exception framework" in the context of a library
like CM.

Perhaps you could restate your proposal (on another thread?), and
ask explicitly if people agree with the principle.

If in the affirmative, you should then open an issue on JIRA and
prepare a patch for the master branch, in order to ensure that
there is no hidden problem.


Thanks,
Gilles


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

.




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

[math] MatrixDimensionMismatchException vs. DimensionMismatchException

[Ole Ersoy]

So if IUC whenever we are dealing with matrices, a MDME should be thrown?  So 
in this needs an update?:

https://github.com/apache/commons-math/blob/master/src/main/java/org/apache/commons/math4/linear/RealMatrix.java#L95

Ole

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

Re: [math] MatrixDimensionMismatchException vs. DimensionMismatchException

[Ole Ersoy]

Actually - I the Factory is used, then the key signature should determine if 
it's an MDME or DME.  So if 4 keys are used row, column, row, column then MDME 
otherwise DME...Sound good?

Ole

On 12/24/2015 06:12 PM, Ole Ersoy wrote:

So if IUC whenever we are dealing with matrices, a MDME should be thrown?  So 
in this needs an update?:

https://github.com/apache/commons-math/blob/master/src/main/java/org/apache/commons/math4/linear/RealMatrix.java#L95

Ole



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

Re: [math] Exception Design

[Gilles]

On Thu, 24 Dec 2015 16:56:54 +0100, Luc Maisonobe wrote:

[...]

When our users build a large application, they rely on numerous
different libraries and tools, both open-source and proprietary.
These libraries do have standard interfaces so they can be used
together. The Java standard library is one of them. the
getLocalizedMessage method is specified there. Many of the 
libraries

and tolls user will assemble rely on it. Deciding that for the sake
of Apache Commons Math we do not abide to this and decide that all
other existing code should adapt to a different design is a clear
no go for me.


Does the JVM abide by this?


Yes,


Then, how to explain that the following code

---CUT---
for (Locale loc : new Locale[] { Locale.ENGLISH, Locale.FRENCH 
}) {

Locale.setDefault(loc);
System.out.println("Locale=" + loc);

try {
final int a = 2;
double r = a / 0;
} catch (Exception e) {
System.out.println("JVM toString(): " + e);
System.out.println("JVM getLocalizedMessage(): " + 
e.getLocalizedMessage());

}

try {
throw new NotStrictlyPositiveException(-1);
} catch (Exception e) {
System.out.println("CM -> toString(): " + e);
System.out.println("CM -> getLocalizedMessage(): " + 
e.getLocalizedMessage());

}
}
---CUT---

produces this output:

---CUT---
Locale=en
JVM toString(): java.lang.ArithmeticException: / by zero
JVM getLocalizedMessage(): / by zero
CM -> toString(): 
org.apache.commons.math4.exception.NotStrictlyPositiveException: -1 is 
smaller than, or equal to, the minimum (0)
CM -> getLocalizedMessage(): -1 is smaller than, or equal to, the 
minimum (0)

Locale=fr
JVM toString(): java.lang.ArithmeticException: / by zero
JVM getLocalizedMessage(): / by zero
CM -> toString(): 
org.apache.commons.math4.exception.NotStrictlyPositiveException: -1 
n'est pas strictement plus grand que le minimum (0)
CM -> getLocalizedMessage(): -1 n'est pas strictement plus grand que le 
minimum (0)

---CUT---

?


as well as JUnit, Eclipse, Maven, and all tools I use.



The point is that CM code is not user-level code: requirements that
have nothing to do with mathematical algorithms should not have
top-level priority here.  This is what has always biased this
discussion.

This issue is not one of a design that would not use 
"getLocalizedMessage"

just that CM is not the place to do so. CM throws exception; caller
handle them in any way they want.
For example:

try {
 // ...

 // Use a low-level library: do not let foreign exceptions bubble 
up.

 try {
   CMAlgo algo = new CMAlgo();
   algo.run();
 } catch(RuntimeException e) {
   if (e instanceof CMAlgoException)
 throw new MyCMAlgoException(e);
   } else {
 throw new MyUnexpectedException(e);
   }
 }

 // ...
} catch (MyRuntimeException e) {
  LOG.error(e.getLocalizedMessage()); //
}


Times thousands times as CM call in complex applications that do
a lot of math occur everywhere.


But you do not have to do the above a thousand times only at the point
where you need to extract the message.

public class MyApp {

  public static void main(String[] args) {
final Locale loc = new locale(args[0]);
try {
  final MyApp app = new MyApp(args[1], args[2]);
  app.run();
} catch (RuntimeException e) {
  if (e instanceof MathException) {
LOG.error(translate(e, loc));
exit(1);
  }
}
  }

  private void run() {
// ...
  }
}




Look at it, it is *only* one field with its setter and two one line
methods defined in the top level MathException class in order to
abide to a standardized interface widely used.


OK, and I also worked a lot to make it less of a duplication mess.
I don't think that I can oppose you on these 3 lines given all the
work you do. ;-)


Thanks.



But once and for all, I'd like that we acknowledge that this 
decision

has nothing to do with good design.


I don't claim this to be good design. It is only meant to be 
practical

and not cumbersome for users.


If it is not practical or cumbersome, then it is not good design. :-)



The list of translated type could still be maintained here, in the 
same

way the unit tests and user guide are.


I'm not sure. If we decide to delegate the localization to the user
and simply provide the two one-liners hook to call it, then we can
remove the list of translated types and let the user handle it. It
would also allow them to support additional languages. For now,
we support only one, we could drop it using this delegation 
mechanism.


I just meant it as a service to the international of users. :-)
We could centralize the translations as is done for other resources 
like

the userguide.


This is fine with me.


I'm also fine if we don't provide this service!


[...]


The setLocalizer method is not a computation algorithm expected
to be call