Re: [Math] About NullArgumentException
Hi,
2012/9/10 Gilles Sadowski gil...@harfang.homelinux.org:
On Sun, Sep 09, 2012 at 09:16:51AM -0700, Phil Steitz wrote:
On 9/9/12 4:34 AM, Gilles Sadowski wrote:
Hi.
Further discussion on the JIRA page
https://issues.apache.org/jira/browse/MATH-856
cannot reach a consensus on solving the issue that raised this thread.
The proposal was that CM never checks for null and lets the JVM do it
(and
thus throw the standard NPE).
Phil wants to retain some null checks but opposes to throwing a NPE without
a detailed message.
The localization mechanism being implemented in ExceptionContext, we
cannot throw a standard NPE (since the error message won't be localized).
For a consistent behaviour (as seen from the caller), we would have to
implement a subclass of the standard NPE: callers could do
try {
// Call CM
} catch (NullPointerException e) {
// Handle NPE (raised by the JVM _or_ by CM).
}
However, this breaks the consensus we arrived at (for v4.0) about CM
throwing only subclasses of MathRuntimeExceprion (singly rooted
hierarchy).
Phil proposes to throw MathIAE (IMO, it must be the specific
NullArgumentException), but this breaks the above use-case: Users have to
do
try {
// Call CM
} catch (NullPointerException e) {
// Handle NPE (raised by the JVM).
} catch (NullArgumentException e)
// Handle NPE (raised by CM).
}
showing blatantly that CM is not consistent: sometimes it lets a JVM
exception propagate, and sometimes it catches the problem eralier and
throws
an exception that is not in the same hierarchy (NPE vs IAE or, in 4.0,
MathRuntimeException).
This is the current state of affairs, and I think that it is not
satisfactory. [As proven by this issue having recurred two or three times
already.]
In light of this, I propose that either
* Phil changes his mind (no check for null performed in CM code), or
* we make an exception to the singly-rooted hierarchy just for
NullArgumentException (which, in 4.0, would become a subclass of the
standard NPE).
Why not just leave things alone [...]
For the reason I gave above: the inconsistent/non-existent policy will make
the issue recur sooner or later, as it happened now with Sébastien, as it
happened with me when I first signalled the burden of checked excpetions and
later when we agreed about MathRuntimeException, then changed again, to come
back again now, to where we were almost two years ago (IIRC)...
- i.e., let some APIs document null
handling and throw IAE at the point of method invocation when
supplying a null violates the documented API contract?
The answer to that question is in the previous post.
We can leave the (needless, IMO) NullArgumentException as a subclass
of MathIAE in place, or drop it and throw MathIAE directly in these
cases.
NullArgumentException is about as needless as any subclass of Exception
or RuntimeException. Either we use inheritance for what it's primarily
meant or we choose another, non-OO, language.
This is going in circles; some people will drop from the discussion (or
already did) and some time from now, someone will rediscover this, among
other little defects of CM. These are worth correcting, but not worth
discussing endlessly.
Let's just have all people here provide their preference and be done with
it.
Since there is no way to enforce a strict policy on checking for null
in CM, I think that NAE is useless, and should be droped.
If we assume that every user of CM can use a debugger, then probably
(and contrary to what I advocated earlier), checking early for null is
also superfluous.
I tend to document arguments which *can* be null (I think someone else
also mentioned this practice), so that it's fairly safe (as someone
already wrote) to assume that all other arguments *must* be non-null.
To sum up, I would favor complete removal of NAE. As for existing
checks, I would either remove them, or throw an argumentless standard
NPE.
Phil was talking about loss of robustness. I don't think that CM as a
whole is robust with respect to null pointers. In some places, the
code fails in the standard way (NPE), while in others, it fails in a
fully documented way. Since this is inconsistent, I don't think we
should be afraid of losing robustness in the case of complete removal
of existing checks for null. Again, I'm happy to keep them, but I'd
rather throw a standard NPE in this case.
Sébastien
Gilles
P.S. Is there an occurrence in CM, where a method can be passed a null
argument?
Phil
The second option cares for all the various positions _except_ the
singly-rooted hierarchy.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] About NullArgumentException
Le 10/09/2012 08:11, Sébastien Brisard a écrit :
Hi,
2012/9/10 Gilles Sadowski gil...@harfang.homelinux.org:
On Sun, Sep 09, 2012 at 09:16:51AM -0700, Phil Steitz wrote:
On 9/9/12 4:34 AM, Gilles Sadowski wrote:
Hi.
Further discussion on the JIRA page
https://issues.apache.org/jira/browse/MATH-856
cannot reach a consensus on solving the issue that raised this thread.
The proposal was that CM never checks for null and lets the JVM do it
(and
thus throw the standard NPE).
Phil wants to retain some null checks but opposes to throwing a NPE without
a detailed message.
The localization mechanism being implemented in ExceptionContext, we
cannot throw a standard NPE (since the error message won't be localized).
For a consistent behaviour (as seen from the caller), we would have to
implement a subclass of the standard NPE: callers could do
try {
// Call CM
} catch (NullPointerException e) {
// Handle NPE (raised by the JVM _or_ by CM).
}
However, this breaks the consensus we arrived at (for v4.0) about CM
throwing only subclasses of MathRuntimeExceprion (singly rooted
hierarchy).
Phil proposes to throw MathIAE (IMO, it must be the specific
NullArgumentException), but this breaks the above use-case: Users have to
do
try {
// Call CM
} catch (NullPointerException e) {
// Handle NPE (raised by the JVM).
} catch (NullArgumentException e)
// Handle NPE (raised by CM).
}
showing blatantly that CM is not consistent: sometimes it lets a JVM
exception propagate, and sometimes it catches the problem eralier and
throws
an exception that is not in the same hierarchy (NPE vs IAE or, in 4.0,
MathRuntimeException).
This is the current state of affairs, and I think that it is not
satisfactory. [As proven by this issue having recurred two or three times
already.]
In light of this, I propose that either
* Phil changes his mind (no check for null performed in CM code), or
* we make an exception to the singly-rooted hierarchy just for
NullArgumentException (which, in 4.0, would become a subclass of the
standard NPE).
Why not just leave things alone [...]
For the reason I gave above: the inconsistent/non-existent policy will make
the issue recur sooner or later, as it happened now with Sébastien, as it
happened with me when I first signalled the burden of checked excpetions and
later when we agreed about MathRuntimeException, then changed again, to come
back again now, to where we were almost two years ago (IIRC)...
- i.e., let some APIs document null
handling and throw IAE at the point of method invocation when
supplying a null violates the documented API contract?
The answer to that question is in the previous post.
We can leave the (needless, IMO) NullArgumentException as a subclass
of MathIAE in place, or drop it and throw MathIAE directly in these
cases.
NullArgumentException is about as needless as any subclass of Exception
or RuntimeException. Either we use inheritance for what it's primarily
meant or we choose another, non-OO, language.
This is going in circles; some people will drop from the discussion (or
already did) and some time from now, someone will rediscover this, among
other little defects of CM. These are worth correcting, but not worth
discussing endlessly.
Let's just have all people here provide their preference and be done with
it.
Since there is no way to enforce a strict policy on checking for null
in CM, I think that NAE is useless, and should be droped.
If we assume that every user of CM can use a debugger, then probably
(and contrary to what I advocated earlier), checking early for null is
also superfluous.
There are some cases pointed to be Phil which can be useful. We can let
them if they are already there.
I tend to document arguments which *can* be null (I think someone else
also mentioned this practice), so that it's fairly safe (as someone
already wrote) to assume that all other arguments *must* be non-null.
+1.
To sum up, I would favor complete removal of NAE. As for existing
checks, I would either remove them, or throw an argumentless standard
NPE.
As null is so ubiquitous, I would tend to choose Gilles second option
(i.e. we preserve NullArgumentException, outside of the single root
hierarchy I promote for other exceptions). This would preserve
robustness Phil asks for and I would not complain against this as in
this case I would not mind if it is not advertised in javadocs and
throws declarations (because even if we don't throw it ourselves, a
regular NPE from JVM can always occur).
Phil was talking about loss of robustness. I don't think that CM as a
whole is robust with respect to null pointers.
It is not globally robust, but in some places it is because some effort
was already put on this.
Luc
In some places, the
code fails in the standard way (NPE), while in others, it fails in a
fully documented way. Since this is inconsistent, I don't think we
Re: [Math] About NullArgumentException
[...] P.S. Is there an occurrence in CM, where a method can be passed a null argument? Yes. One example is the constructor for EmpiricalDistribution that takes a RandomGenerator as argument. Thanks for finding one of those few examples. The first remark (concerning the issue at hand in this thread) is that it is enough to say in the documentation of those cases that null is allowed. The policy is (would be) that null is never a valid argument (except in the documented cases). If a null is supplied, the constructor does not complain and the lazy initialization works as though the argumentless constructor had been used and a JDK random generator is created. The second remark is that allowing null in this case only brings confusion because there also exists overloaded constructors. [Overloading is the right way to provide default arguments; using null is to be avoided (and is a remnant from C programming where no two methods can have the same name).] We thus have public EmpiricalDistribution(int binCount) and public EmpiricalDistribution(int binCount, RandomGenerator generator) In the latter case, the doc says: * @param generator random data generator (may be null, resulting in * default JDK generator) Which is also what happens in the former case, albeit a little later. It's confusing because the word lazy does not appear anywhere, so there is no usefulness (from the user's point-of-view) to pass null to the two-args constructor, where he could use the more concise, one-arg, constructor. Even if the doc would highlight the difference, it's still needlessly complicated to allow null since the class's seemingly central method getNextValue would trigger the initialization of the RNG sooner or later. [Hence the gain of lazy init is nil.] If there are use-cases where the RNG part of the functionality is never used, then, IMHO, the design can be improved by separating the data loading + statistics computation from the actual distribution functionality (getNextValue). In the new product, there would be no reference to a RNG (thus vanished the can be null, and if it is, there will be lazy init etc.) in one class, while in the other, getNextValue would indeed be so prominent that the class cannot be used without a RNG (thus lazy init is totally useless) and that argument _cannot_ be null. There are other similar examples, mostly constructors, IIRC. Then a similar analysis probably applies. Gilles Phil Phil The second option cares for all the various positions _except_ the singly-rooted hierarchy. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1382770 - /commons/proper/codec/trunk/src/changes/changes.xml
On Mon, Sep 10, 2012 at 1:43 PM, ggreg...@apache.org wrote: Author: ggregory Date: Mon Sep 10 11:43:48 2012 New Revision: 1382770 URL: http://svn.apache.org/viewvc?rev=1382770view=rev Log: Preparing for release 1.7 RC1. Modified: commons/proper/codec/trunk/src/changes/changes.xml Modified: commons/proper/codec/trunk/src/changes/changes.xml URL: http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/changes/changes.xml?rev=1382770r1=1382769r2=1382770view=diff == --- commons/proper/codec/trunk/src/changes/changes.xml (original) +++ commons/proper/codec/trunk/src/changes/changes.xml Mon Sep 10 11:43:48 2012 @@ -50,7 +50,7 @@ The action type attribute can be add,u /action /release -- -release version=1.7 date=TBD description=Feature and fix release. +release version=1.7 date=9 Semptember 2012 description=Feature and fix release. Typo: September Thomas
Re: svn commit: r1382770 - /commons/proper/codec/trunk/src/changes/changes.xml
On Mon, Sep 10, 2012 at 7:53 AM, Thomas Neidhart thomas.neidh...@gmail.comwrote: On Mon, Sep 10, 2012 at 1:43 PM, ggreg...@apache.org wrote: Author: ggregory Date: Mon Sep 10 11:43:48 2012 New Revision: 1382770 URL: http://svn.apache.org/viewvc?rev=1382770view=rev Log: Preparing for release 1.7 RC1. Modified: commons/proper/codec/trunk/src/changes/changes.xml Modified: commons/proper/codec/trunk/src/changes/changes.xml URL: http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/changes/changes.xml?rev=1382770r1=1382769r2=1382770view=diff == --- commons/proper/codec/trunk/src/changes/changes.xml (original) +++ commons/proper/codec/trunk/src/changes/changes.xml Mon Sep 10 11:43:48 2012 @@ -50,7 +50,7 @@ The action type attribute can be add,u /action /release -- -release version=1.7 date=TBD description=Feature and fix release. +release version=1.7 date=9 Semptember 2012 description=Feature and fix release. Typo: September Arg. Thanks. Fixed in SVN. Gary Thomas -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
[GUMP@vmgump]: Project commons-io (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-io has an issue affecting its community integration. This issue affects 23 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-fileupload : Commons File Upload Package - commons-io : Commons I/O Utility Package - commons-io-test : Apache Commons - forrest-rat : Apache Forrest software is a publishing framework that trans... - fulcrum-naming : Services Framework - fulcrum-osworkflow : Services Framework - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-coyote-tomcat4 : Connectors to various web servers - jakarta-tomcat-jk : Connectors to various web servers - jmeter-svn : Pure Java load testing and performance measurement tool. ... - jmeter-test : Pure Java load testing and performance measurement tool. ... - org.apache.commons.commons-io : Apache Commons - org.apache.xmlgraphics.fop : XSL-FO (Formatting Objects) processor - portals-pluto-portal-1.0 : JSR168 Container - rat-tasks-antunit-tests : Release Audit Tool - solr : Java Based Search Engine - solr-test : Java Based Search Engine - tomcat-catalina : Servlet 2.3 and JSP 1.2 Reference Implementation - xml-fop : XSL-FO (Formatting Objects) processor - xml-fop-test : XSL-FO (Formatting Objects) processor - xmlgraphics-commons : Apache XML Graphics Commons - Common Components for Batik an... - xmlgraphics-commons-test : Apache XML Graphics Commons - Common Components for Batik an... Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-io/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-io-*[0-9T].jar] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/io/pom.xml -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-io/gump_work/build_apache-commons_commons-io.html Work Name: build_apache-commons_commons-io (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 44 secs Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings /srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/io] M2_HOME: /opt/maven2 - Downloading: http://maven.tmatesoft.com/content/repositories/releases/org/apache/maven/scm/maven-scm-provider-perforce/1.7/maven-scm-provider-perforce-1.7.pom [INFO] Unable to find resource 'org.apache.maven.scm:maven-scm-provider-perforce:pom:1.7' in repository maven.tmatesoft.com.releases (http://maven.tmatesoft.com/content/repositories/releases) Downloading: http://localhost:8192/maven2/org/apache/maven/scm/maven-scm-provider-perforce/1.7/maven-scm-provider-perforce-1.7.pom 2K downloaded (maven-scm-provider-perforce-1.7.pom) Downloading: http://maven.tmatesoft.com/content/repositories/releases/org/apache/maven/scm/maven-scm-provider-hg/1.7/maven-scm-provider-hg-1.7.pom [INFO] Unable to find resource 'org.apache.maven.scm:maven-scm-provider-hg:pom:1.7' in repository maven.tmatesoft.com.releases (http://maven.tmatesoft.com/content/repositories/releases) Downloading: http://localhost:8192/maven2/org/apache/maven/scm/maven-scm-provider-hg/1.7/maven-scm-provider-hg-1.7.pom 2K downloaded (maven-scm-provider-hg-1.7.pom) Downloading: http://maven.tmatesoft.com/content/repositories/releases/com/google/code/maven-scm-provider-svnjava/maven-scm-provider-svnjava/1.13/maven-scm-provider-svnjava-1.13.pom [INFO] Unable to find resource 'com.google.code.maven-scm-provider-svnjava:maven-scm-provider-svnjava:pom:1.13' in repository maven.tmatesoft.com.releases (http://maven.tmatesoft.com/content/repositories/releases) Downloading: http://localhost:8192/maven2/com/google/code/maven-scm-provider-svnjava/maven-scm-provider-svnjava/1.13/maven-scm-provider-svnjava-1.13.pom 9K downloaded (maven-scm-provider-svnjava-1.13.pom) Downloading: http://maven.tmatesoft.com/content/repositories/releases/org/sonatype/oss/oss-parent/5/oss-parent-5.pom [INFO] Unable to find resource 'org.sonatype.oss:oss-parent:pom:5' in repository maven.tmatesoft.com.releases
[VOTE] Release Commons Codec 1.7-RC1
Hello All: This is a VOTE to release Commons Codec 1.7-RC1. Changes in this version include: New features: o CODEC-157: DigestUtils: Add MD2 APIs. Thanks to ggregory. o CODEC-156: DigestUtils: add APIs named after standard algorithm name SHA-1. Thanks to ggregory. o CODEC-155: DigestUtils.getDigest(String) should throw IllegalArgumentException instead of RuntimeException. Thanks to ggregory. o CODEC-153: Create a class MessageDigestAlgorithms to define standard algorithm names. Thanks to ggregory. o CODEC-152: DigestUtils.getDigest(String) loses the original exception. Thanks to ggregory. o CODEC-151: Remove unnecessary attempt to fill up the salt variable in UnixCrypt. Thanks to lathspell. o CODEC-150: Remove unnecessary call to Math.abs(). Thanks to lathspell. o CODEC-148: More tests and minor things. Thanks to lathspell. o CODEC-146: Added regression tests for PhoneticEngine based on Solr-3.6.0. Thanks to Julius Davies. o CODEC-139: DigestUtils: add updateDigest methods and make methods public. Thanks to dsebastien. o CODEC-133: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. Thanks to lathspell. o CODEC-130: Base64InputStream.skip skips underlying stream, not output. Thanks to tn. o CODEC-63: Implement NYSIIS phonetic encoder. Thanks to bayard. Fixed Bugs: o CODEC-96: Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder. Note: the fix breaks binary compatibility, however the changes are to a class (BaseNCodec) which is intended for internal use. Thanks to sebb. o CODEC-138: Complete FilterInputStream interface for BaseNCodecInputStream. o CODEC-136: Use Charset objects when possible, create Charsets for required character encodings. o CODEC-132: BeiderMorseEncoder OOM issues. Thanks to rcmuir. o CODEC-131: DoubleMetaphone javadoc contains dead links. Thanks to smolav. Changes: o CODEC-147: BeiderMorseEncoder/PhoneticEngine: make results deterministic by using a LinkedHashSet instead of a HashSet. o CODEC-143: StringBuffer could be replaced by StringBuilder for local variables. Known issue only on IBM Java 5: --- Test set: org.apache.commons.codec.binary.Base64InputStreamTest --- Tests run: 15, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.287 sec FAILURE! testInputStreamReader(org.apache.commons.codec.binary.Base64InputStreamTest) Time elapsed: 0.004 sec ERROR! sun.io.MalformedInputException at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:310) at sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:316) at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:366) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:252) at java.io.InputStreamReader.read(InputStreamReader.java:212) at java.io.BufferedReader.fill(BufferedReader.java:157) at java.io.BufferedReader.readLine(BufferedReader.java:320) at java.io.BufferedReader.readLine(BufferedReader.java:383) at org.apache.commons.codec.binary.Base64InputStreamTest.testInputStreamReader(Base64InputStreamTest.java:110) --- $ java -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pxa64devifx-20110627 (SR12 FP5 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64 j9vmxa6423ifx-20110624 (JIT enabled) J9VM - 20110623_85457_LHdSMr JIT - 20100623_16197ifx10_r8 GC - FP22011_06) JCL - 20110627 --- This VOTE is open for at least 72 hours until September 13 2012 at 10:00 AM EST. The files: https://repository.apache.org/content/repositories/orgapachecommons-046/ The tag: https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.7-RC1 The site: https://people.apache.org/builds/commons/commons-codec/1.7/RC1/ Note that the JIRA report is empty and it is a known issue in the Maven JIRA plugin and that requires a new plugin version. Thank you, Gary Gregory -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory http://twitter.com/GaryGregory
Re: [VOTE] Release Commons Codec 1.7-RC1
Hi Gary, how you manage the non-maven assemblies? I mean, if the vote passes, you just download them from Nexus to the dist machine? TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Sep 10, 2012 at 3:59 PM, Gary Gregory ggreg...@apache.org wrote: Hello All: This is a VOTE to release Commons Codec 1.7-RC1. Changes in this version include: New features: o CODEC-157: DigestUtils: Add MD2 APIs. Thanks to ggregory. o CODEC-156: DigestUtils: add APIs named after standard algorithm name SHA-1. Thanks to ggregory. o CODEC-155: DigestUtils.getDigest(String) should throw IllegalArgumentException instead of RuntimeException. Thanks to ggregory. o CODEC-153: Create a class MessageDigestAlgorithms to define standard algorithm names. Thanks to ggregory. o CODEC-152: DigestUtils.getDigest(String) loses the original exception. Thanks to ggregory. o CODEC-151: Remove unnecessary attempt to fill up the salt variable in UnixCrypt. Thanks to lathspell. o CODEC-150: Remove unnecessary call to Math.abs(). Thanks to lathspell. o CODEC-148: More tests and minor things. Thanks to lathspell. o CODEC-146: Added regression tests for PhoneticEngine based on Solr-3.6.0. Thanks to Julius Davies. o CODEC-139: DigestUtils: add updateDigest methods and make methods public. Thanks to dsebastien. o CODEC-133: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. Thanks to lathspell. o CODEC-130: Base64InputStream.skip skips underlying stream, not output. Thanks to tn. o CODEC-63: Implement NYSIIS phonetic encoder. Thanks to bayard. Fixed Bugs: o CODEC-96: Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder. Note: the fix breaks binary compatibility, however the changes are to a class (BaseNCodec) which is intended for internal use. Thanks to sebb. o CODEC-138: Complete FilterInputStream interface for BaseNCodecInputStream. o CODEC-136: Use Charset objects when possible, create Charsets for required character encodings. o CODEC-132: BeiderMorseEncoder OOM issues. Thanks to rcmuir. o CODEC-131: DoubleMetaphone javadoc contains dead links. Thanks to smolav. Changes: o CODEC-147: BeiderMorseEncoder/PhoneticEngine: make results deterministic by using a LinkedHashSet instead of a HashSet. o CODEC-143: StringBuffer could be replaced by StringBuilder for local variables. Known issue only on IBM Java 5: --- Test set: org.apache.commons.codec.binary.Base64InputStreamTest --- Tests run: 15, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.287 sec FAILURE! testInputStreamReader(org.apache.commons.codec.binary.Base64InputStreamTest) Time elapsed: 0.004 sec ERROR! sun.io.MalformedInputException at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:310) at sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:316) at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:366) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:252) at java.io.InputStreamReader.read(InputStreamReader.java:212) at java.io.BufferedReader.fill(BufferedReader.java:157) at java.io.BufferedReader.readLine(BufferedReader.java:320) at java.io.BufferedReader.readLine(BufferedReader.java:383) at org.apache.commons.codec.binary.Base64InputStreamTest.testInputStreamReader(Base64InputStreamTest.java:110) --- $ java -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pxa64devifx-20110627 (SR12 FP5 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64 j9vmxa6423ifx-20110624 (JIT enabled) J9VM - 20110623_85457_LHdSMr JIT - 20100623_16197ifx10_r8 GC - FP22011_06) JCL - 20110627 --- This VOTE is open for at least 72 hours until September 13 2012 at 10:00 AM EST. The files: https://repository.apache.org/content/repositories/orgapachecommons-046/ The tag: https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.7-RC1 The site: https://people.apache.org/builds/commons/commons-codec/1.7/RC1/ Note that the JIRA report is empty and it is a known issue in the Maven JIRA plugin and that requires a new plugin version. Thank you, Gary Gregory -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory http://twitter.com/GaryGregory
Re: [VOTE] Release Commons Codec 1.7-RC1
On Mon, Sep 10, 2012 at 10:36 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi Gary, how you manage the non-maven assemblies? I mean, if the vote passes, you just download them from Nexus to the dist machine? Yes, the process is manual. Gary TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Sep 10, 2012 at 3:59 PM, Gary Gregory ggreg...@apache.org wrote: Hello All: This is a VOTE to release Commons Codec 1.7-RC1. Changes in this version include: New features: o CODEC-157: DigestUtils: Add MD2 APIs. Thanks to ggregory. o CODEC-156: DigestUtils: add APIs named after standard algorithm name SHA-1. Thanks to ggregory. o CODEC-155: DigestUtils.getDigest(String) should throw IllegalArgumentException instead of RuntimeException. Thanks to ggregory. o CODEC-153: Create a class MessageDigestAlgorithms to define standard algorithm names. Thanks to ggregory. o CODEC-152: DigestUtils.getDigest(String) loses the original exception. Thanks to ggregory. o CODEC-151: Remove unnecessary attempt to fill up the salt variable in UnixCrypt. Thanks to lathspell. o CODEC-150: Remove unnecessary call to Math.abs(). Thanks to lathspell. o CODEC-148: More tests and minor things. Thanks to lathspell. o CODEC-146: Added regression tests for PhoneticEngine based on Solr-3.6.0. Thanks to Julius Davies. o CODEC-139: DigestUtils: add updateDigest methods and make methods public. Thanks to dsebastien. o CODEC-133: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. Thanks to lathspell. o CODEC-130: Base64InputStream.skip skips underlying stream, not output. Thanks to tn. o CODEC-63: Implement NYSIIS phonetic encoder. Thanks to bayard. Fixed Bugs: o CODEC-96: Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder. Note: the fix breaks binary compatibility, however the changes are to a class (BaseNCodec) which is intended for internal use. Thanks to sebb. o CODEC-138: Complete FilterInputStream interface for BaseNCodecInputStream. o CODEC-136: Use Charset objects when possible, create Charsets for required character encodings. o CODEC-132: BeiderMorseEncoder OOM issues. Thanks to rcmuir. o CODEC-131: DoubleMetaphone javadoc contains dead links. Thanks to smolav. Changes: o CODEC-147: BeiderMorseEncoder/PhoneticEngine: make results deterministic by using a LinkedHashSet instead of a HashSet. o CODEC-143: StringBuffer could be replaced by StringBuilder for local variables. Known issue only on IBM Java 5: --- Test set: org.apache.commons.codec.binary.Base64InputStreamTest --- Tests run: 15, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.287 sec FAILURE! testInputStreamReader(org.apache.commons.codec.binary.Base64InputStreamTest) Time elapsed: 0.004 sec ERROR! sun.io.MalformedInputException at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:310) at sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:316) at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:366) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:252) at java.io.InputStreamReader.read(InputStreamReader.java:212) at java.io.BufferedReader.fill(BufferedReader.java:157) at java.io.BufferedReader.readLine(BufferedReader.java:320) at java.io.BufferedReader.readLine(BufferedReader.java:383) at org.apache.commons.codec.binary.Base64InputStreamTest.testInputStreamReader(Base64InputStreamTest.java:110) --- $ java -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pxa64devifx-20110627 (SR12 FP5 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64 j9vmxa6423ifx-20110624 (JIT enabled) J9VM - 20110623_85457_LHdSMr JIT - 20100623_16197ifx10_r8 GC - FP22011_06) JCL - 20110627 --- This VOTE is open for at least 72 hours until September 13 2012 at 10:00 AM EST. The files: https://repository.apache.org/content/repositories/orgapachecommons-046/ The tag: https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.7-RC1 The site: https://people.apache.org/builds/commons/commons-codec/1.7/RC1/ Note that the JIRA report is empty and it is a known issue in the Maven JIRA plugin and that requires a new plugin version. Thank you, Gary Gregory -- E-Mail: garydgreg...@gmail.com |
Re: [Math] About NullArgumentException
On 9/10/12 3:44 AM, Gilles Sadowski wrote: [...] P.S. Is there an occurrence in CM, where a method can be passed a null argument? Yes. One example is the constructor for EmpiricalDistribution that takes a RandomGenerator as argument. Thanks for finding one of those few examples. The first remark (concerning the issue at hand in this thread) is that it is enough to say in the documentation of those cases that null is allowed. Good, we agree there. The policy is (would be) that null is never a valid argument (except in the documented cases). I agree there. Where we disagree is what we should do when an illegal null argument is passed to an API that does not accept nulls. I like to document and throw IAE in this case (per guidelines in the Developers Guide). That is more robust, since failure is immediate, there are no potential downstream impacts / resource utilization / leakage potential, and it is easier to debug / trace without looking at the source code, especially if an informative message indicating what precondition failed is provided. If a null is supplied, the constructor does not complain and the lazy initialization works as though the argumentless constructor had been used and a JDK random generator is created. The second remark is that allowing null in this case only brings confusion because there also exists overloaded constructors. [Overloading is the right way to provide default arguments; using null is to be avoided (and is a remnant from C programming where no two methods can have the same name).] I am sure you can figure out how to refactor my applications that use this functionality, but here an example showing why it exists. When initializing an application from external configuration meta-data, if a RandomGenerator class is provided in the config, the initialization framework creates an instance of the provided class and sets a property of an application class being created equal to the instance. This property is used by constructors of other members of the class. If no config is provided for the RandomGenerator, the property is null. The null-safe constructor allows the property to be used as an argument to the constructor, avoiding the need to code (or configure) the test for null in initialization. We thus have public EmpiricalDistribution(int binCount) and public EmpiricalDistribution(int binCount, RandomGenerator generator) In the latter case, the doc says: * @param generator random data generator (may be null, resulting in * default JDK generator) Which is also what happens in the former case, albeit a little later. It's confusing because the word lazy does not appear anywhere, so there is no usefulness (from the user's point-of-view) to pass null to the two-args constructor, where he could use the more concise, one-arg, constructor. See use case above - when what is being passed in is a property, which may be null, it is convenient to be able to provide null to the constructor. Phil Even if the doc would highlight the difference, it's still needlessly complicated to allow null since the class's seemingly central method getNextValue would trigger the initialization of the RNG sooner or later. [Hence the gain of lazy init is nil.] If there are use-cases where the RNG part of the functionality is never used, then, IMHO, the design can be improved by separating the data loading + statistics computation from the actual distribution functionality (getNextValue). In the new product, there would be no reference to a RNG (thus vanished the can be null, and if it is, there will be lazy init etc.) in one class, while in the other, getNextValue would indeed be so prominent that the class cannot be used without a RNG (thus lazy init is totally useless) and that argument _cannot_ be null. There are other similar examples, mostly constructors, IIRC. Then a similar analysis probably applies. Gilles Phil Phil The second option cares for all the various positions _except_ the singly-rooted hierarchy. Regards, 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
Re: [Math] About NullArgumentException
On 9/9/12 11:11 PM, Sébastien Brisard wrote:
Hi,
2012/9/10 Gilles Sadowski gil...@harfang.homelinux.org:
On Sun, Sep 09, 2012 at 09:16:51AM -0700, Phil Steitz wrote:
On 9/9/12 4:34 AM, Gilles Sadowski wrote:
Hi.
Further discussion on the JIRA page
https://issues.apache.org/jira/browse/MATH-856
cannot reach a consensus on solving the issue that raised this thread.
The proposal was that CM never checks for null and lets the JVM do it
(and
thus throw the standard NPE).
Phil wants to retain some null checks but opposes to throwing a NPE without
a detailed message.
The localization mechanism being implemented in ExceptionContext, we
cannot throw a standard NPE (since the error message won't be localized).
For a consistent behaviour (as seen from the caller), we would have to
implement a subclass of the standard NPE: callers could do
try {
// Call CM
} catch (NullPointerException e) {
// Handle NPE (raised by the JVM _or_ by CM).
}
However, this breaks the consensus we arrived at (for v4.0) about CM
throwing only subclasses of MathRuntimeExceprion (singly rooted
hierarchy).
Phil proposes to throw MathIAE (IMO, it must be the specific
NullArgumentException), but this breaks the above use-case: Users have to
do
try {
// Call CM
} catch (NullPointerException e) {
// Handle NPE (raised by the JVM).
} catch (NullArgumentException e)
// Handle NPE (raised by CM).
}
showing blatantly that CM is not consistent: sometimes it lets a JVM
exception propagate, and sometimes it catches the problem eralier and
throws
an exception that is not in the same hierarchy (NPE vs IAE or, in 4.0,
MathRuntimeException).
This is the current state of affairs, and I think that it is not
satisfactory. [As proven by this issue having recurred two or three times
already.]
In light of this, I propose that either
* Phil changes his mind (no check for null performed in CM code), or
* we make an exception to the singly-rooted hierarchy just for
NullArgumentException (which, in 4.0, would become a subclass of the
standard NPE).
Why not just leave things alone [...]
For the reason I gave above: the inconsistent/non-existent policy will make
the issue recur sooner or later, as it happened now with Sébastien, as it
happened with me when I first signalled the burden of checked excpetions and
later when we agreed about MathRuntimeException, then changed again, to come
back again now, to where we were almost two years ago (IIRC)...
- i.e., let some APIs document null
handling and throw IAE at the point of method invocation when
supplying a null violates the documented API contract?
The answer to that question is in the previous post.
We can leave the (needless, IMO) NullArgumentException as a subclass
of MathIAE in place, or drop it and throw MathIAE directly in these
cases.
NullArgumentException is about as needless as any subclass of Exception
or RuntimeException. Either we use inheritance for what it's primarily
meant or we choose another, non-OO, language.
This is going in circles; some people will drop from the discussion (or
already did) and some time from now, someone will rediscover this, among
other little defects of CM. These are worth correcting, but not worth
discussing endlessly.
Let's just have all people here provide their preference and be done with
it.
Since there is no way to enforce a strict policy on checking for null
in CM, I think that NAE is useless, and should be droped.
I agree there, as long as APIs that specify null-handling and
disallow nulls can throw MathIAE in its place.
If we assume that every user of CM can use a debugger, then probably
(and contrary to what I advocated earlier), checking early for null is
also superfluous.
The most important advantage of checking preconditions and throwing
client-meaningful exceptions at the point of activation is that it
makes it easier to diagnose run time failures - not just for
developers debugging code with access to the full sources; but for
operations and other developers who may not have access to the
sources. Seeing an IllegalArgumentException with an informative
message in a stack trace at the point of activation, anyone can look
at the published javadoc and understand exactly what happened, at
least from the standpoint of the library. Just seeing an
undocumented NPE somewhere down in the call stack leads to a harder
problem, sometimes requiring added instrumentation, examination of
the source code, or other methods to diagnose what is going on.
Phil
I tend to document arguments which *can* be null (I think someone else
also mentioned this practice), so that it's fairly safe (as someone
already wrote) to assume that all other arguments *must* be non-null.
To sum up, I would favor complete removal of NAE. As for existing
checks, I would either remove them, or throw an argumentless standard
NPE.
Phil was talking about loss of robustness. I don't
[GUMP@vmgump]: Project commons-vfs2 (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-vfs2 has an issue affecting its community integration. This issue affects 5 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-configuration : Apache Commons - commons-configuration-test : Apache Commons - commons-vfs2 : Apache Commons - commons-vfs2-sandbox : Apache Commons - commons-vfs2-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-vfs2-*[0-9T].jar] identifier set to project name -INFO- Optional dependency org.jdom prerequisite failed with reason build failed -INFO- Optional dependency commons-net failed with reason build failed -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/vfs/pom.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/gump_work/build_apache-commons_commons-vfs2.html Work Name: build_apache-commons_commons-vfs2 (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: /opt/maven3/bin/mvn --batch-mode -DskipTests=true --settings /srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/vfs] M2_HOME: /opt/maven3 - [INFO] Commons VFS [INFO] Commons VFS Core [INFO] Commons VFS Examples [INFO] Commons VFS Distribution [INFO] [INFO] [INFO] Building Commons VFS 2.1-SNAPSHOT [INFO] [INFO] [INFO] --- maven-antrun-plugin:1.7:run (javadoc.resources) @ commons-vfs2-project --- [INFO] Executing tasks main: [copy] Copying 2 files to /srv/gump/public/workspace/apache-commons/vfs/target/apidocs/META-INF [INFO] Executed tasks [INFO] [INFO] --- maven-antrun-plugin:1.7:run (vfs-jar-manifest) @ commons-vfs2-project --- [INFO] Executing tasks main: [mkdir] Created dir: /srv/gump/public/workspace/apache-commons/vfs/target/osgi [touch] Creating /srv/gump/public/workspace/apache-commons/vfs/target/osgi/MANIFEST.MF [INFO] Executed tasks [INFO] [INFO] --- maven-remote-resources-plugin:1.3:process (default) @ commons-vfs2-project --- [INFO] [INFO] --- buildnumber-maven-plugin:1.1:create (default) @ commons-vfs2-project --- Downloading: http://localhost:8192/maven2/org/apache/maven/scm/maven-scm-provider-cvs-commons/1.7/maven-scm-provider-cvs-commons-1.7.pom Downloading: http://maven.tmatesoft.com/content/repositories/releases/org/apache/maven/scm/maven-scm-provider-cvs-commons/1.7/maven-scm-provider-cvs-commons-1.7.pom [INFO] [INFO] Reactor Summary: [INFO] [INFO] Commons VFS ... FAILURE [7.926s] [INFO] Commons VFS Core .. SKIPPED [INFO] Commons VFS Examples .. SKIPPED [INFO] Commons VFS Distribution .. SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 9.138s [INFO] Finished at: Mon Sep 10 16:51:38 UTC 2012 [INFO] Final Memory: 10M/24M [INFO] [ERROR] Failed to execute goal org.codehaus.mojo:buildnumber-maven-plugin:1.1:create (default) on project commons-vfs2-project: Execution default of goal org.codehaus.mojo:buildnumber-maven-plugin:1.1:create failed: Plugin org.codehaus.mojo:buildnumber-maven-plugin:1.1 or one of its dependencies could not be resolved: Failed to collect dependencies for org.codehaus.mojo:buildnumber-maven-plugin:jar:1.1 (): Failed to read artifact descriptor for org.apache.maven.scm:maven-scm-provider-cvs-commons:jar:1.7: Could not transfer artifact org.apache.maven.scm:maven-scm-provider-cvs-commons:pom:1.7 from/to gump-central (http://localhost:8192/maven2): Error transferring file: Invalid Http response - [Help 1] [ERROR] [ERROR] To see the full
Re: [VOTE] Release Commons Codec 1.7-RC1
Hi again Gary, Not a blocker at all, but * RAT plugin shows Sha2CryptTest class does not have the ALv2 license header; * question: Clirr plugin shows some breakage, they all look like internal stuff, did you discuss about these breakage? Apologize but I didn't follow the [codec] thread; Trivial: * CPD shows some code redundancies - arrays initialization can be safely ignored, maybe redundant code invocations could be improved * a couple of minor findbugs[4] notification. I repeat, not blocker at all, but maybe the RAT issue worths another RC, since what e really release at ASF are sources. +1 anyway and thanks a lot for cutting the RC! all the best, -Simo [1] https://people.apache.org/builds/commons/commons-codec/1.7/RC1/rat-report.html [2] https://people.apache.org/builds/commons/commons-codec/1.7/RC1/clirr-report.html [3] https://people.apache.org/builds/commons/commons-codec/1.7/RC1/cpd.html [4] https://people.apache.org/builds/commons/commons-codec/1.7/RC1/findbugs.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Sep 10, 2012 at 5:14 PM, Gary Gregory garydgreg...@gmail.com wrote: On Mon, Sep 10, 2012 at 10:36 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi Gary, how you manage the non-maven assemblies? I mean, if the vote passes, you just download them from Nexus to the dist machine? Yes, the process is manual. Gary TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Sep 10, 2012 at 3:59 PM, Gary Gregory ggreg...@apache.org wrote: Hello All: This is a VOTE to release Commons Codec 1.7-RC1. Changes in this version include: New features: o CODEC-157: DigestUtils: Add MD2 APIs. Thanks to ggregory. o CODEC-156: DigestUtils: add APIs named after standard algorithm name SHA-1. Thanks to ggregory. o CODEC-155: DigestUtils.getDigest(String) should throw IllegalArgumentException instead of RuntimeException. Thanks to ggregory. o CODEC-153: Create a class MessageDigestAlgorithms to define standard algorithm names. Thanks to ggregory. o CODEC-152: DigestUtils.getDigest(String) loses the original exception. Thanks to ggregory. o CODEC-151: Remove unnecessary attempt to fill up the salt variable in UnixCrypt. Thanks to lathspell. o CODEC-150: Remove unnecessary call to Math.abs(). Thanks to lathspell. o CODEC-148: More tests and minor things. Thanks to lathspell. o CODEC-146: Added regression tests for PhoneticEngine based on Solr-3.6.0. Thanks to Julius Davies. o CODEC-139: DigestUtils: add updateDigest methods and make methods public. Thanks to dsebastien. o CODEC-133: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. Thanks to lathspell. o CODEC-130: Base64InputStream.skip skips underlying stream, not output. Thanks to tn. o CODEC-63: Implement NYSIIS phonetic encoder. Thanks to bayard. Fixed Bugs: o CODEC-96: Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder. Note: the fix breaks binary compatibility, however the changes are to a class (BaseNCodec) which is intended for internal use. Thanks to sebb. o CODEC-138: Complete FilterInputStream interface for BaseNCodecInputStream. o CODEC-136: Use Charset objects when possible, create Charsets for required character encodings. o CODEC-132: BeiderMorseEncoder OOM issues. Thanks to rcmuir. o CODEC-131: DoubleMetaphone javadoc contains dead links. Thanks to smolav. Changes: o CODEC-147: BeiderMorseEncoder/PhoneticEngine: make results deterministic by using a LinkedHashSet instead of a HashSet. o CODEC-143: StringBuffer could be replaced by StringBuilder for local variables. Known issue only on IBM Java 5: --- Test set: org.apache.commons.codec.binary.Base64InputStreamTest --- Tests run: 15, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.287 sec FAILURE! testInputStreamReader(org.apache.commons.codec.binary.Base64InputStreamTest) Time elapsed: 0.004 sec ERROR! sun.io.MalformedInputException at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:310) at sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:316) at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:366) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:252) at java.io.InputStreamReader.read(InputStreamReader.java:212) at java.io.BufferedReader.fill(BufferedReader.java:157) at java.io.BufferedReader.readLine(BufferedReader.java:320) at
Re: [Math] About NullArgumentException
Hi
What should I do there?
I'm trying to work on MATH-854. It turns out that FieldElementT.add
throws a NAE. Should I catch it below, and rethrow it with a more
detailed message (including the entry index)?
Best,
Sébastien
/** {@inheritDoc} */
public FieldVectorT add(FieldVectorT v)
throws DimensionMismatchException {
try {
return add((ArrayFieldVectorT) v);
} catch (ClassCastException cce) {
checkVectorDimensions(v);
T[] out = buildArray(data.length);
for (int i = 0; i data.length; i++) {
out[i] = data[i].add(v.getEntry(i));
// SHOULD I CATCH NAE HERE?
}
return new ArrayFieldVectorT(field, out, false);
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[vfs] Problem running VFS on Win 2008
I have an archive processor that extends Apache VFS. On windows XP it runs as designed, however; when I run this process on Windows 2008, it seams like my FileEventListeners are not firing on file change or on file add. Has anyone else ever experienced this problem? The source was compiled with 1.7 and the host's java runtime is 1.7. The only other difference is I compiled on a 32 bit system. I am pretty much stumped at this point Thanks for any help you might be able to provide Sean
Re: [configuration] Plan for 2.0
Am 09.09.2012 14:26, schrieb sebb: On 8 September 2012 15:45, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 08.09.2012 03:44, schrieb sebb: On 7 September 2012 20:46, Oliver Heger oliver.he...@oliver-heger.de wrote: Hi all, the pom was updated to make 2.0-SNAPSHOT the current development version. This means we are free to implement major changes without having to enforce binary backwards compatibility. BC breakage will require package and Maven coordinate changes at some point just before release. Yes, I am aware of this. The question is: What are the goals for version 2.0? I would recommend to define a clear focus so that the next release will not take too long. Obviously there are already people waiting for a [configuration] version compatible with [lang3]. Some points I have in mind are the following ones: - Switch to [lang3]. This is the main reason for going to version 2.0 because this cannot be done in a binary compatible way. Not sure I follow that. Why would changing a dependency affect the API for Configuration? Does not make sense to me. Some classes of [lang] are exposed in the public API of [configuration]. For instance, variable substitution in configuration files is done by a org.apache.commons.lang.text.StrSubstitutor object. The StrSubstitutor to use can be set. So switching to [lang3] will effectively change the public API of [configuration] in an incompatible way. That seems very fragile. There has to be a better way to handle that. Fixing it will break the API (once), but at least the API will then be stable, regardless of what happens with LANG. Do you mean all interfaces or classes from 3rd party libraries should be wrapped so that they do not leak in the public API? I agree that using 3rd party classes in the public API is obviously fragile and should be avoided as much as possible. But I am not sure whether a radical wrapping approach works in all cases. Also, it might make reuse of classes harder for client code. Take for instance the StrSubstitutor example. A client may already have a custom implementation to be used with the corresponding [lang] classes. Now this implementation cannot be used together with [configuration] because here a slightly different interface is required - although the functionality is the same. Not sure how to deal with this issue in general. Oliver Oliver - Improve thread safety and concurrent implementations in general. - Rework reloading. This is related to the previous point because I think the tight coupling of the current reloading implementation is one of the root causes making the implementation of thread-safe configurations so hard. - Have a look at older Jira tickets which have been postponed because they would break binary compatibility. Any other points, wishes, or opinions? We should discuss the points separately when it comes to their implementation. Oliver - 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Is this good practice?
Le 10/09/2012 21:08, Sébastien Brisard a écrit :
Hi,
Hi Sébastien,
I thought it was not good practice to rely on exception in
unexceptional circumstances. In ArrayFieldVector, there are numerous
occurences of the following pattern
public FieldVectorT add(FieldVectorT v)
throws DimensionMismatchException {
try {
return add((ArrayFieldVectorT) v);
} catch (ClassCastException cce) {
checkVectorDimensions(v);
T[] out = buildArray(data.length);
for (int i = 0; i data.length; i++) {
out[i] = data[i].add(v.getEntry(i));
}
return new ArrayFieldVectorT(field, out, false);
}
}
The catch (ClassCastException cce) seems uggly to me. Should I file
a JIRA issue and start replacing with instanceof?
This was done on purpose a long time ago.
At that time, it appeared that it was faster to do it this way, i.e.
attempt by default the fast method which did not rely on getEntry, and
fall back to a loop using getEntry only in the very rare cases the first
fails.
I am not sure this is useful anymore, as JVM optimizers are better and
better (so they may well replace the getEntry on the fly and use direct
array access when they can).
Perhaps you could do some benchmark with a modern JVM and look if this
hack is still useful or not.
best regards,
Luc
Best regards,
Sébastien
-
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
Re: [VOTE] Release Commons Codec 1.7-RC1
Build works fine with Maven and ant on Windows 7 with JDK 1.6. Artifacts look good, site, too, except for the following very minor points (in addition to the things Simone already discovered): - The JIRA report is just a blank page (I think during build an exception is thrown - maybe an incompatible plug-in version?). - The surefire report says that the tests were not to 100% successful. The release notes mention an issue with IBM Java 1.5.0. But is [codec] compatible with Java 1.5 at all? Maybe I got this wrong. All minor things, maybe the missing ASL header should be fixed. But you have my +1. Oliver Am 10.09.2012 15:59, schrieb Gary Gregory: Hello All: This is a VOTE to release Commons Codec 1.7-RC1. Changes in this version include: New features: o CODEC-157: DigestUtils: Add MD2 APIs. Thanks to ggregory. o CODEC-156: DigestUtils: add APIs named after standard algorithm name SHA-1. Thanks to ggregory. o CODEC-155: DigestUtils.getDigest(String) should throw IllegalArgumentException instead of RuntimeException. Thanks to ggregory. o CODEC-153: Create a class MessageDigestAlgorithms to define standard algorithm names. Thanks to ggregory. o CODEC-152: DigestUtils.getDigest(String) loses the original exception. Thanks to ggregory. o CODEC-151: Remove unnecessary attempt to fill up the salt variable in UnixCrypt. Thanks to lathspell. o CODEC-150: Remove unnecessary call to Math.abs(). Thanks to lathspell. o CODEC-148: More tests and minor things. Thanks to lathspell. o CODEC-146: Added regression tests for PhoneticEngine based on Solr-3.6.0. Thanks to Julius Davies. o CODEC-139: DigestUtils: add updateDigest methods and make methods public. Thanks to dsebastien. o CODEC-133: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. Thanks to lathspell. o CODEC-130: Base64InputStream.skip skips underlying stream, not output. Thanks to tn. o CODEC-63: Implement NYSIIS phonetic encoder. Thanks to bayard. Fixed Bugs: o CODEC-96: Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder. Note: the fix breaks binary compatibility, however the changes are to a class (BaseNCodec) which is intended for internal use. Thanks to sebb. o CODEC-138: Complete FilterInputStream interface for BaseNCodecInputStream. o CODEC-136: Use Charset objects when possible, create Charsets for required character encodings. o CODEC-132: BeiderMorseEncoder OOM issues. Thanks to rcmuir. o CODEC-131: DoubleMetaphone javadoc contains dead links. Thanks to smolav. Changes: o CODEC-147: BeiderMorseEncoder/PhoneticEngine: make results deterministic by using a LinkedHashSet instead of a HashSet. o CODEC-143: StringBuffer could be replaced by StringBuilder for local variables. Known issue only on IBM Java 5: --- Test set: org.apache.commons.codec.binary.Base64InputStreamTest --- Tests run: 15, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.287 sec FAILURE! testInputStreamReader(org.apache.commons.codec.binary.Base64InputStreamTest) Time elapsed: 0.004 sec ERROR! sun.io.MalformedInputException at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:310) at sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:316) at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:366) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:252) at java.io.InputStreamReader.read(InputStreamReader.java:212) at java.io.BufferedReader.fill(BufferedReader.java:157) at java.io.BufferedReader.readLine(BufferedReader.java:320) at java.io.BufferedReader.readLine(BufferedReader.java:383) at org.apache.commons.codec.binary.Base64InputStreamTest.testInputStreamReader(Base64InputStreamTest.java:110) --- $ java -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pxa64devifx-20110627 (SR12 FP5 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64 j9vmxa6423ifx-20110624 (JIT enabled) J9VM - 20110623_85457_LHdSMr JIT - 20100623_16197ifx10_r8 GC - FP22011_06) JCL - 20110627 --- This VOTE is open for at least 72 hours until September 13 2012 at 10:00 AM EST. The files: https://repository.apache.org/content/repositories/orgapachecommons-046/ The tag: https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.7-RC1 The site: https://people.apache.org/builds/commons/commons-codec/1.7/RC1/ Note that the JIRA report is empty and it is a known issue in the Maven JIRA plugin and that requires a new plugin version. Thank you, Gary Gregory
Re: [math] Is this good practice?
Hi,
2012/9/10 Luc Maisonobe luc.maison...@free.fr:
Le 10/09/2012 21:08, Sébastien Brisard a écrit :
Hi,
Hi Sébastien,
I thought it was not good practice to rely on exception in
unexceptional circumstances. In ArrayFieldVector, there are numerous
occurences of the following pattern
public FieldVectorT add(FieldVectorT v)
throws DimensionMismatchException {
try {
return add((ArrayFieldVectorT) v);
} catch (ClassCastException cce) {
checkVectorDimensions(v);
T[] out = buildArray(data.length);
for (int i = 0; i data.length; i++) {
out[i] = data[i].add(v.getEntry(i));
}
return new ArrayFieldVectorT(field, out, false);
}
}
The catch (ClassCastException cce) seems uggly to me. Should I file
a JIRA issue and start replacing with instanceof?
This was done on purpose a long time ago.
At that time, it appeared that it was faster to do it this way, i.e.
attempt by default the fast method which did not rely on getEntry, and
fall back to a loop using getEntry only in the very rare cases the first
fails.
I am not sure this is useful anymore, as JVM optimizers are better and
better (so they may well replace the getEntry on the fly and use direct
array access when they can).
Perhaps you could do some benchmark with a modern JVM and look if this
hack is still useful or not.
If it still is, a comment should be added to make future maintainers
aware of this fact.
Benedikt
best regards,
Luc
Best regards,
Sébastien
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Codec 1.7-RC1
On 2012-09-10 22:01, Oliver Heger wrote: Build works fine with Maven and ant on Windows 7 with JDK 1.6. Artifacts look good, site, too, except for the following very minor points (in addition to the things Simone already discovered): - The JIRA report is just a blank page (I think during build an exception is thrown - maybe an incompatible plug-in version?). This is due to a bug in the Changes Plugin. I've applied a patch that fixes this and I'm working on getting a release out. Hopefully later this week. I've tried the latest SNAPSHOT on commons-codec and it solves this problem. - The surefire report says that the tests were not to 100% successful. The release notes mention an issue with IBM Java 1.5.0. But is [codec] compatible with Java 1.5 at all? Maybe I got this wrong. All minor things, maybe the missing ASL header should be fixed. But you have my +1. Oliver Am 10.09.2012 15:59, schrieb Gary Gregory: Hello All: This is a VOTE to release Commons Codec 1.7-RC1. Changes in this version include: New features: o CODEC-157: DigestUtils: Add MD2 APIs. Thanks to ggregory. o CODEC-156: DigestUtils: add APIs named after standard algorithm name SHA-1. Thanks to ggregory. o CODEC-155: DigestUtils.getDigest(String) should throw IllegalArgumentException instead of RuntimeException. Thanks to ggregory. o CODEC-153: Create a class MessageDigestAlgorithms to define standard algorithm names. Thanks to ggregory. o CODEC-152: DigestUtils.getDigest(String) loses the original exception. Thanks to ggregory. o CODEC-151: Remove unnecessary attempt to fill up the salt variable in UnixCrypt. Thanks to lathspell. o CODEC-150: Remove unnecessary call to Math.abs(). Thanks to lathspell. o CODEC-148: More tests and minor things. Thanks to lathspell. o CODEC-146: Added regression tests for PhoneticEngine based on Solr-3.6.0. Thanks to Julius Davies. o CODEC-139: DigestUtils: add updateDigest methods and make methods public. Thanks to dsebastien. o CODEC-133: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. Thanks to lathspell. o CODEC-130: Base64InputStream.skip skips underlying stream, not output. Thanks to tn. o CODEC-63: Implement NYSIIS phonetic encoder. Thanks to bayard. Fixed Bugs: o CODEC-96: Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder. Note: the fix breaks binary compatibility, however the changes are to a class (BaseNCodec) which is intended for internal use. Thanks to sebb. o CODEC-138: Complete FilterInputStream interface for BaseNCodecInputStream. o CODEC-136: Use Charset objects when possible, create Charsets for required character encodings. o CODEC-132: BeiderMorseEncoder OOM issues. Thanks to rcmuir. o CODEC-131: DoubleMetaphone javadoc contains dead links. Thanks to smolav. Changes: o CODEC-147: BeiderMorseEncoder/PhoneticEngine: make results deterministic by using a LinkedHashSet instead of a HashSet. o CODEC-143: StringBuffer could be replaced by StringBuilder for local variables. Known issue only on IBM Java 5: --- Test set: org.apache.commons.codec.binary.Base64InputStreamTest --- Tests run: 15, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.287 sec FAILURE! testInputStreamReader(org.apache.commons.codec.binary.Base64InputStreamTest) Time elapsed: 0.004 sec ERROR! sun.io.MalformedInputException at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:310) at sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:316) at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:366) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:252) at java.io.InputStreamReader.read(InputStreamReader.java:212) at java.io.BufferedReader.fill(BufferedReader.java:157) at java.io.BufferedReader.readLine(BufferedReader.java:320) at java.io.BufferedReader.readLine(BufferedReader.java:383) at org.apache.commons.codec.binary.Base64InputStreamTest.testInputStreamReader(Base64InputStreamTest.java:110) --- $ java -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pxa64devifx-20110627 (SR12 FP5 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64 j9vmxa6423ifx-20110624 (JIT enabled) J9VM - 20110623_85457_LHdSMr JIT - 20100623_16197ifx10_r8 GC - FP22011_06) JCL - 20110627 --- This VOTE is open for at least 72 hours until September 13 2012 at 10:00 AM EST. The files:
Re: [Math] About NullArgumentException
On 9/10/12 11:47 AM, Sébastien Brisard wrote:
Hi
What should I do there?
I'm trying to work on MATH-854. It turns out that FieldElementT.add
throws a NAE. Should I catch it below, and rethrow it with a more
detailed message (including the entry index)?
IMO, yes.
I would also check v itself and add to the javadoc contract that IAE
is thrown if v is null. This is not consistently done in [math],
though, and rarely in the linear package, so I am OK just letting
the NPE propagate if v is null. It is a little awkward that v
itself being null leads to NPE, but a component of it null leads to
MIAE.
Phil
Best,
Sébastien
/** {@inheritDoc} */
public FieldVectorT add(FieldVectorT v)
throws DimensionMismatchException {
try {
return add((ArrayFieldVectorT) v);
} catch (ClassCastException cce) {
checkVectorDimensions(v);
T[] out = buildArray(data.length);
for (int i = 0; i data.length; i++) {
out[i] = data[i].add(v.getEntry(i));
// SHOULD I CATCH NAE HERE?
}
return new ArrayFieldVectorT(field, out, false);
}
}
-
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
Re: [VOTE] Release Commons Codec 1.7-RC1
Thank you for the review. See below. On Mon, Sep 10, 2012 at 2:25 PM, Simone Tripodi simonetrip...@apache.orgwrote: Hi again Gary, Not a blocker at all, but * RAT plugin shows Sha2CryptTest class does not have the ALv2 license header; This is a bad one and would be a -1 from me. Fixed in SVN. I'll do an RC2 tomorrow. * question: Clirr plugin shows some breakage, they all look like internal stuff, did you discuss about these breakage? Apologize but I didn't follow the [codec] thread; Yes, this is internal. See: CODEC-96: Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder. Note: the fix breaks binary compatibility, however the changes are to a class (BaseNCodec) which is intended for internal use. Thanks to sebb. Trivial: * CPD shows some code redundancies - arrays initialization can be safely ignored, maybe redundant code invocations could be improved I'll not deal with that. I am not sure these are worth refactoring the code. * a couple of minor findbugs[4] notification. Unread field: Can't fix w/o breaking BC. BaseNCodec$Context: False positive. Thank you for the detailed review! Gary I repeat, not blocker at all, but maybe the RAT issue worths another RC, since what e really release at ASF are sources. +1 anyway and thanks a lot for cutting the RC! all the best, -Simo [1] https://people.apache.org/builds/commons/commons-codec/1.7/RC1/rat-report.html [2] https://people.apache.org/builds/commons/commons-codec/1.7/RC1/clirr-report.html [3] https://people.apache.org/builds/commons/commons-codec/1.7/RC1/cpd.html [4] https://people.apache.org/builds/commons/commons-codec/1.7/RC1/findbugs.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Sep 10, 2012 at 5:14 PM, Gary Gregory garydgreg...@gmail.com wrote: On Mon, Sep 10, 2012 at 10:36 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi Gary, how you manage the non-maven assemblies? I mean, if the vote passes, you just download them from Nexus to the dist machine? Yes, the process is manual. Gary TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Sep 10, 2012 at 3:59 PM, Gary Gregory ggreg...@apache.org wrote: Hello All: This is a VOTE to release Commons Codec 1.7-RC1. Changes in this version include: New features: o CODEC-157: DigestUtils: Add MD2 APIs. Thanks to ggregory. o CODEC-156: DigestUtils: add APIs named after standard algorithm name SHA-1. Thanks to ggregory. o CODEC-155: DigestUtils.getDigest(String) should throw IllegalArgumentException instead of RuntimeException. Thanks to ggregory. o CODEC-153: Create a class MessageDigestAlgorithms to define standard algorithm names. Thanks to ggregory. o CODEC-152: DigestUtils.getDigest(String) loses the original exception. Thanks to ggregory. o CODEC-151: Remove unnecessary attempt to fill up the salt variable in UnixCrypt. Thanks to lathspell. o CODEC-150: Remove unnecessary call to Math.abs(). Thanks to lathspell. o CODEC-148: More tests and minor things. Thanks to lathspell. o CODEC-146: Added regression tests for PhoneticEngine based on Solr-3.6.0. Thanks to Julius Davies. o CODEC-139: DigestUtils: add updateDigest methods and make methods public. Thanks to dsebastien. o CODEC-133: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. Thanks to lathspell. o CODEC-130: Base64InputStream.skip skips underlying stream, not output. Thanks to tn. o CODEC-63: Implement NYSIIS phonetic encoder. Thanks to bayard. Fixed Bugs: o CODEC-96: Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder. Note: the fix breaks binary compatibility, however the changes are to a class (BaseNCodec) which is intended for internal use. Thanks to sebb. o CODEC-138: Complete FilterInputStream interface for BaseNCodecInputStream. o CODEC-136: Use Charset objects when possible, create Charsets for required character encodings. o CODEC-132: BeiderMorseEncoder OOM issues. Thanks to rcmuir. o CODEC-131: DoubleMetaphone javadoc contains dead links. Thanks to smolav. Changes: o CODEC-147: BeiderMorseEncoder/PhoneticEngine: make results deterministic by using a LinkedHashSet instead of a HashSet. o CODEC-143: StringBuffer could be replaced by StringBuilder for local variables. Known issue only on IBM Java 5: --- Test set: org.apache.commons.codec.binary.Base64InputStreamTest
Re: [VOTE] Release Commons Codec 1.7-RC1
On Mon, Sep 10, 2012 at 4:01 PM, Oliver Heger oliver.he...@oliver-heger.dewrote: Build works fine with Maven and ant on Windows 7 with JDK 1.6. Artifacts look good, site, too, except for the following very minor points (in addition to the things Simone already discovered): - The JIRA report is just a blank page (I think during build an exception is thrown - maybe an incompatible plug-in version?). - The surefire report says that the tests were not to 100% successful. What failed for you? Can you debug? VM? OS? etc. The release notes mention an issue with IBM Java 1.5.0. But is [codec] compatible with Java 1.5 at all? Maybe I got this wrong. Can someone test this on an IBM Java 6 VM? Thank you for the review! Gary All minor things, maybe the missing ASL header should be fixed. But you have my +1. Oliver Am 10.09.2012 15:59, schrieb Gary Gregory: Hello All: This is a VOTE to release Commons Codec 1.7-RC1. Changes in this version include: New features: o CODEC-157: DigestUtils: Add MD2 APIs. Thanks to ggregory. o CODEC-156: DigestUtils: add APIs named after standard algorithm name SHA-1. Thanks to ggregory. o CODEC-155: DigestUtils.getDigest(String) should throw IllegalArgumentException instead of RuntimeException. Thanks to ggregory. o CODEC-153: Create a class MessageDigestAlgorithms to define standard algorithm names. Thanks to ggregory. o CODEC-152: DigestUtils.getDigest(String) loses the original exception. Thanks to ggregory. o CODEC-151: Remove unnecessary attempt to fill up the salt variable in UnixCrypt. Thanks to lathspell. o CODEC-150: Remove unnecessary call to Math.abs(). Thanks to lathspell. o CODEC-148: More tests and minor things. Thanks to lathspell. o CODEC-146: Added regression tests for PhoneticEngine based on Solr-3.6.0. Thanks to Julius Davies. o CODEC-139: DigestUtils: add updateDigest methods and make methods public. Thanks to dsebastien. o CODEC-133: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. Thanks to lathspell. o CODEC-130: Base64InputStream.skip skips underlying stream, not output. Thanks to tn. o CODEC-63: Implement NYSIIS phonetic encoder. Thanks to bayard. Fixed Bugs: o CODEC-96: Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder. Note: the fix breaks binary compatibility, however the changes are to a class (BaseNCodec) which is intended for internal use. Thanks to sebb. o CODEC-138: Complete FilterInputStream interface for BaseNCodecInputStream. o CODEC-136: Use Charset objects when possible, create Charsets for required character encodings. o CODEC-132: BeiderMorseEncoder OOM issues. Thanks to rcmuir. o CODEC-131: DoubleMetaphone javadoc contains dead links. Thanks to smolav. Changes: o CODEC-147: BeiderMorseEncoder/**PhoneticEngine: make results deterministic by using a LinkedHashSet instead of a HashSet. o CODEC-143: StringBuffer could be replaced by StringBuilder for local variables. Known issue only on IBM Java 5: --**--** --- Test set: org.apache.commons.codec.**binary.Base64InputStreamTest --**--** --- Tests run: 15, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.287 sec FAILURE! testInputStreamReader(org.**apache.commons.codec.binary.** Base64InputStreamTest) Time elapsed: 0.004 sec ERROR! sun.io.MalformedInputException at sun.io.ByteToCharUTF8.convert(**ByteToCharUTF8.java:310) at sun.nio.cs.StreamDecoder$**ConverterSD.convertInto(** StreamDecoder.java:316) at sun.nio.cs.StreamDecoder$**ConverterSD.implRead(**StreamDecoder.java:366) at sun.nio.cs.StreamDecoder.read(**StreamDecoder.java:252) at java.io.InputStreamReader.**read(InputStreamReader.java:**212) at java.io.BufferedReader.fill(**BufferedReader.java:157) at java.io.BufferedReader.**readLine(BufferedReader.java:**320) at java.io.BufferedReader.**readLine(BufferedReader.java:**383) at org.apache.commons.codec.**binary.Base64InputStreamTest.** testInputStreamReader(**Base64InputStreamTest.java:**110) --**--** --- $ java -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pxa64devifx-20110627 (SR12 FP5 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64 j9vmxa6423ifx-20110624 (JIT enabled) J9VM - 20110623_85457_LHdSMr JIT - 20100623_16197ifx10_r8 GC - FP22011_06) JCL - 20110627 --**--** --- This VOTE is open for at least 72 hours until September 13 2012 at 10:00 AM EST. The files: https://repository.apache.org/**content/repositories/**
Re: [VOTE] Release Commons Codec 1.7-RC1
On Mon, Sep 10, 2012 at 4:01 PM, Oliver Heger oliver.he...@oliver-heger.dewrote: Build works fine with Maven and ant on Windows 7 with JDK 1.6. Artifacts look good, site, too, except for the following very minor points (in addition to the things Simone already discovered): - The JIRA report is just a blank page (I think during build an exception is thrown - maybe an incompatible plug-in version?). - The surefire report says that the tests were not to 100% successful. The release notes mention an issue with IBM Java 1.5.0. But is [codec] compatible with Java 1.5 at all? Maybe I got this wrong. Codec 1.7 requires Java 6 but I cannot test a Java 6 IBM JVM. I hesitate to remove the note. If someone cannot test, I'll rephrase it as a warning. Thank you, Gary All minor things, maybe the missing ASL header should be fixed. But you have my +1. Oliver Am 10.09.2012 15:59, schrieb Gary Gregory: Hello All: This is a VOTE to release Commons Codec 1.7-RC1. Changes in this version include: New features: o CODEC-157: DigestUtils: Add MD2 APIs. Thanks to ggregory. o CODEC-156: DigestUtils: add APIs named after standard algorithm name SHA-1. Thanks to ggregory. o CODEC-155: DigestUtils.getDigest(String) should throw IllegalArgumentException instead of RuntimeException. Thanks to ggregory. o CODEC-153: Create a class MessageDigestAlgorithms to define standard algorithm names. Thanks to ggregory. o CODEC-152: DigestUtils.getDigest(String) loses the original exception. Thanks to ggregory. o CODEC-151: Remove unnecessary attempt to fill up the salt variable in UnixCrypt. Thanks to lathspell. o CODEC-150: Remove unnecessary call to Math.abs(). Thanks to lathspell. o CODEC-148: More tests and minor things. Thanks to lathspell. o CODEC-146: Added regression tests for PhoneticEngine based on Solr-3.6.0. Thanks to Julius Davies. o CODEC-139: DigestUtils: add updateDigest methods and make methods public. Thanks to dsebastien. o CODEC-133: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. Thanks to lathspell. o CODEC-130: Base64InputStream.skip skips underlying stream, not output. Thanks to tn. o CODEC-63: Implement NYSIIS phonetic encoder. Thanks to bayard. Fixed Bugs: o CODEC-96: Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder. Note: the fix breaks binary compatibility, however the changes are to a class (BaseNCodec) which is intended for internal use. Thanks to sebb. o CODEC-138: Complete FilterInputStream interface for BaseNCodecInputStream. o CODEC-136: Use Charset objects when possible, create Charsets for required character encodings. o CODEC-132: BeiderMorseEncoder OOM issues. Thanks to rcmuir. o CODEC-131: DoubleMetaphone javadoc contains dead links. Thanks to smolav. Changes: o CODEC-147: BeiderMorseEncoder/**PhoneticEngine: make results deterministic by using a LinkedHashSet instead of a HashSet. o CODEC-143: StringBuffer could be replaced by StringBuilder for local variables. Known issue only on IBM Java 5: --**--** --- Test set: org.apache.commons.codec.**binary.Base64InputStreamTest --**--** --- Tests run: 15, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.287 sec FAILURE! testInputStreamReader(org.**apache.commons.codec.binary.** Base64InputStreamTest) Time elapsed: 0.004 sec ERROR! sun.io.MalformedInputException at sun.io.ByteToCharUTF8.convert(**ByteToCharUTF8.java:310) at sun.nio.cs.StreamDecoder$**ConverterSD.convertInto(** StreamDecoder.java:316) at sun.nio.cs.StreamDecoder$**ConverterSD.implRead(**StreamDecoder.java:366) at sun.nio.cs.StreamDecoder.read(**StreamDecoder.java:252) at java.io.InputStreamReader.**read(InputStreamReader.java:**212) at java.io.BufferedReader.fill(**BufferedReader.java:157) at java.io.BufferedReader.**readLine(BufferedReader.java:**320) at java.io.BufferedReader.**readLine(BufferedReader.java:**383) at org.apache.commons.codec.**binary.Base64InputStreamTest.** testInputStreamReader(**Base64InputStreamTest.java:**110) --**--** --- $ java -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pxa64devifx-20110627 (SR12 FP5 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64 j9vmxa6423ifx-20110624 (JIT enabled) J9VM - 20110623_85457_LHdSMr JIT - 20100623_16197ifx10_r8 GC - FP22011_06) JCL - 20110627 --**--** --- This VOTE is open for at least 72 hours until September 13 2012 at 10:00 AM EST. The files:
Re: [configuration] Plan for 2.0
On 10 September 2012 20:33, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 09.09.2012 14:26, schrieb sebb: On 8 September 2012 15:45, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 08.09.2012 03:44, schrieb sebb: On 7 September 2012 20:46, Oliver Heger oliver.he...@oliver-heger.de wrote: Hi all, the pom was updated to make 2.0-SNAPSHOT the current development version. This means we are free to implement major changes without having to enforce binary backwards compatibility. BC breakage will require package and Maven coordinate changes at some point just before release. Yes, I am aware of this. The question is: What are the goals for version 2.0? I would recommend to define a clear focus so that the next release will not take too long. Obviously there are already people waiting for a [configuration] version compatible with [lang3]. Some points I have in mind are the following ones: - Switch to [lang3]. This is the main reason for going to version 2.0 because this cannot be done in a binary compatible way. Not sure I follow that. Why would changing a dependency affect the API for Configuration? Does not make sense to me. Some classes of [lang] are exposed in the public API of [configuration]. For instance, variable substitution in configuration files is done by a org.apache.commons.lang.text.StrSubstitutor object. The StrSubstitutor to use can be set. So switching to [lang3] will effectively change the public API of [configuration] in an incompatible way. That seems very fragile. There has to be a better way to handle that. Fixing it will break the API (once), but at least the API will then be stable, regardless of what happens with LANG. Do you mean all interfaces or classes from 3rd party libraries should be wrapped so that they do not leak in the public API? Not sure it's necessary to wrap all 3rd party library APIs, just don't expose their classes in the Configuration API. I agree that using 3rd party classes in the public API is obviously fragile and should be avoided as much as possible. But I am not sure whether a radical wrapping approach works in all cases. Also, it might make reuse of classes harder for client code. Take for instance the StrSubstitutor example. A client may already have a custom implementation to be used with the corresponding [lang] classes. Now this implementation cannot be used together with [configuration] because here a slightly different interface is required - although the functionality is the same. If you update Configuration to use lang3, then the custom implementation will break anyway - unless Configuration is updated to work with both Lang and Lang3. Do you really want that? Does not seem scalable. If custom classes in future have to implement a Configuration interface, rather than something from Lang, then at least the custom class is then only dependent on the Config. API. Whatever happens, custom classes are going to need to be changed if support for Lang is dropped in favour of Lang3. Or am I missing something here? Not sure how to deal with this issue in general. Once the API dependency on Lang is removed, it won't be an issue. Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Is this good practice?
On Mon, Sep 10, 2012 at 10:07:11PM +0200, Benedikt Ritter wrote:
Hi,
2012/9/10 Luc Maisonobe luc.maison...@free.fr:
Le 10/09/2012 21:08, Sébastien Brisard a écrit :
Hi,
Hi Sébastien,
I thought it was not good practice to rely on exception in
unexceptional circumstances. In ArrayFieldVector, there are numerous
occurences of the following pattern
public FieldVectorT add(FieldVectorT v)
throws DimensionMismatchException {
try {
return add((ArrayFieldVectorT) v);
} catch (ClassCastException cce) {
checkVectorDimensions(v);
T[] out = buildArray(data.length);
for (int i = 0; i data.length; i++) {
out[i] = data[i].add(v.getEntry(i));
}
return new ArrayFieldVectorT(field, out, false);
}
}
The catch (ClassCastException cce) seems uggly to me. Should I file
a JIRA issue and start replacing with instanceof?
This was done on purpose a long time ago.
At that time, it appeared that it was faster to do it this way, i.e.
attempt by default the fast method which did not rely on getEntry, and
fall back to a loop using getEntry only in the very rare cases the first
fails.
I am not sure this is useful anymore, as JVM optimizers are better and
better (so they may well replace the getEntry on the fly and use direct
array access when they can).
Perhaps you could do some benchmark with a modern JVM and look if this
hack is still useful or not.
If it still is, a comment should be added to make future maintainers
aware of this fact.
I imagine that at the time this was coded, it was assumed that it would be
faster because it skips the conditional (the change proposed by Sébastien).
IIUC, what Luc proposes is to check whether the JIT compiler will replace
calls to getEntry with the method from the actual type. If that's true, it
would also be true that the conditional if (v instanceof ArrayFieldVector)
will be optimized away.
Hence I'd assume that the proposed change is a safe first step (removing
usage of exception for control flow).
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] About NullArgumentException
On Mon, Sep 10, 2012 at 01:31:12PM -0700, Phil Steitz wrote: On 9/10/12 11:47 AM, Sébastien Brisard wrote: Hi What should I do there? I'm trying to work on MATH-854. It turns out that FieldElementT.add throws a NAE. Should I catch it below, and rethrow it with a more detailed message (including the entry index)? IMO, yes. I would also check v itself and add to the javadoc contract that IAE is thrown if v is null. This is not consistently done in [math], though, and rarely in the linear package, so I am OK just letting the NPE propagate if v is null. It is a little awkward that v itself being null leads to NPE, but a component of it null leads to MIAE. Awkward? Of course it is; that's what I explained two posts ago. If we want to allow for the possibility of checking for null (and I agree that it could be useful to pinpoint the problem by passing the information about which index contains an invalid null entry), then we should adopt the second option which I presented in that preceding post: NullArgumentException inherits from NullPointerException This really solves all issues (now that Luc has said that it is not a problem if this one exception escapes the single-root hierarchy): It allows to check for null in CM code and raise the same kind of exception that would arise when no null check is performed. Both flexible and consistent. Gilles [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] About NullArgumentException
Hey,
I'm a disinterested third party (not a CM user) but I thought I should
chime in my two cents worth...
On Sun, Sep 9, 2012 at 4:34 AM, Gilles Sadowski
gil...@harfang.homelinux.org wrote:
Hi.
Further discussion on the JIRA page
https://issues.apache.org/jira/browse/MATH-856
cannot reach a consensus on solving the issue that raised this thread.
The proposal was that CM never checks for null and lets the JVM do it (and
thus throw the standard NPE).
I think a standard NPE should be thrown as soon as a null is detected
where one shouldn't be. If the caller passes in a null and the callee
knows that's bad, throw the NPE right there. Fail fast.
Phil wants to retain some null checks but opposes to throwing a NPE without
a detailed message.
The localization mechanism being implemented in ExceptionContext, we
cannot throw a standard NPE (since the error message won't be localized).
I personally think that localizing exceptions is madness. Maybe that's
just me. Why not localize the CM source code as well? L10n is a
problem for application writers and not math libraries.
It seems to me that CM is trying to achieve documentation through
exceptions, as if the exceptions thrown should guide the user how to
use the library. This is the job of javadoc, tutorials, wikis, etc.
For a consistent behaviour (as seen from the caller), we would have to
implement a subclass of the standard NPE: callers could do
try {
// Call CM
} catch (NullPointerException e) {
// Handle NPE (raised by the JVM _or_ by CM).
}
Is this going to be the typical case? NPE indicates a programming
error, so this is something that *should* completely crash your JVM.
However, this breaks the consensus we arrived at (for v4.0) about CM
throwing only subclasses of MathRuntimeExceprion (singly rooted hierarchy).
Phil proposes to throw MathIAE (IMO, it must be the specific
NullArgumentException), but this breaks the above use-case: Users have to
do
try {
// Call CM
} catch (NullPointerException e) {
// Handle NPE (raised by the JVM).
} catch (NullArgumentException e)
// Handle NPE (raised by CM).
}
showing blatantly that CM is not consistent: sometimes it lets a JVM
exception propagate, and sometimes it catches the problem eralier and throws
an exception that is not in the same hierarchy (NPE vs IAE or, in 4.0,
MathRuntimeException).
This is the current state of affairs, and I think that it is not
satisfactory. [As proven by this issue having recurred two or three times
already.]
+1 this is terrible from an API design perspective
In light of this, I propose that either
* Phil changes his mind (no check for null performed in CM code), or
* we make an exception to the singly-rooted hierarchy just for
NullArgumentException (which, in 4.0, would become a subclass of the
standard NPE).
The second option cares for all the various positions _except_ the
singly-rooted hierarchy.
Regards,
Gilles
Hope you can all work it out. I would start by dropping the
document-by-exception thinking that seems to permeate these
discussions.
Regards,
James
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] About NullArgumentException
On Mon, Sep 10, 2012 at 08:47:35PM +0200, Sébastien Brisard wrote:
Hi
What should I do there?
If we adopt the flexible policy (cf. other post), then you can do what you
want. ;-)
I'm trying to work on MATH-854. It turns out that FieldElementT.add
throws a NAE. Should I catch it below, and rethrow it with a more
detailed message (including the entry index)?
Best,
Sébastien
/** {@inheritDoc} */
public FieldVectorT add(FieldVectorT v)
throws DimensionMismatchException {
try {
return add((ArrayFieldVectorT) v);
} catch (ClassCastException cce) {
checkVectorDimensions(v);
T[] out = buildArray(data.length);
for (int i = 0; i data.length; i++) {
out[i] = data[i].add(v.getEntry(i));
// SHOULD I CATCH NAE HERE?
Not _catch_ NAE but _throw_ it; the line in the loop would become:
final T entry = v.getEntry(i);
if (entry == null) {
throw new NullArgumentException(LocalizedFormats.INDEX, i);
}
out[i] = data[i].add(entry);
}
return new ArrayFieldVectorT(field, out, false);
}
}
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 Codec 1.7-RC1
With IBM Java 1.6: java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260-20071123_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20071121_15015 (JIT enabled) J9VM - 20071121_015015_lHdSMR JIT - r9_20071121_1330 GC - 20071031_AA) JCL - 20071118_01 [This is quite an old IBM Java, IIRC I got it as part of an Eclipse download from IBM] I get the following failures --- Test set: org.apache.commons.codec.binary.StringUtilsTest --- Failed tests: testNewStringUtf16Be(org.apache.commons.codec.binary.StringUtilsTest): expected:?[] but was:?[?] testNewStringUtf16Le(org.apache.commons.codec.binary.StringUtilsTest): expected:?[] but was:?[?] Note that it's not possible to run Maven 2.2.1 with that version of Java; however Maven 3.0.4 works OK - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] About NullArgumentException
On 9/10/12 3:46 PM, Gilles Sadowski wrote:
On Mon, Sep 10, 2012 at 08:47:35PM +0200, Sébastien Brisard wrote:
Hi
What should I do there?
If we adopt the flexible policy (cf. other post), then you can do what you
want. ;-)
Good one :)
I'm trying to work on MATH-854. It turns out that FieldElementT.add
throws a NAE. Should I catch it below, and rethrow it with a more
detailed message (including the entry index)?
Best,
Sébastien
/** {@inheritDoc} */
public FieldVectorT add(FieldVectorT v)
throws DimensionMismatchException {
try {
return add((ArrayFieldVectorT) v);
} catch (ClassCastException cce) {
checkVectorDimensions(v);
T[] out = buildArray(data.length);
for (int i = 0; i data.length; i++) {
out[i] = data[i].add(v.getEntry(i));
// SHOULD I CATCH NAE HERE?
Not _catch_ NAE but _throw_ it; the line in the loop would become:
final T entry = v.getEntry(i);
if (entry == null) {
throw new NullArgumentException(LocalizedFormats.INDEX, i);
}
out[i] = data[i].add(entry);
What about for v itself?
Phil
}
return new ArrayFieldVectorT(field, out, false);
}
}
Regards,
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
Re: [Math] About NullArgumentException
On 9/10/12 3:43 PM, James Ring wrote:
Hey,
I'm a disinterested third party (not a CM user) but I thought I should
chime in my two cents worth...
On Sun, Sep 9, 2012 at 4:34 AM, Gilles Sadowski
gil...@harfang.homelinux.org wrote:
Hi.
Further discussion on the JIRA page
https://issues.apache.org/jira/browse/MATH-856
cannot reach a consensus on solving the issue that raised this thread.
The proposal was that CM never checks for null and lets the JVM do it (and
thus throw the standard NPE).
I think a standard NPE should be thrown as soon as a null is detected
where one shouldn't be. If the caller passes in a null and the callee
knows that's bad, throw the NPE right there. Fail fast.
Phil wants to retain some null checks but opposes to throwing a NPE without
a detailed message.
The localization mechanism being implemented in ExceptionContext, we
cannot throw a standard NPE (since the error message won't be localized).
I personally think that localizing exceptions is madness. Maybe that's
just me. Why not localize the CM source code as well? L10n is a
problem for application writers and not math libraries.
It seems to me that CM is trying to achieve documentation through
exceptions, as if the exceptions thrown should guide the user how to
use the library. This is the job of javadoc, tutorials, wikis, etc.
For a consistent behaviour (as seen from the caller), we would have to
implement a subclass of the standard NPE: callers could do
try {
// Call CM
} catch (NullPointerException e) {
// Handle NPE (raised by the JVM _or_ by CM).
}
Is this going to be the typical case? NPE indicates a programming
error, so this is something that *should* completely crash your JVM.
Maybe I am being stupid here, but why is NPE so vastly different
from, say, array index error and why is it bad to check parameters
against documented preconditions and throw IAE when actual
parameters do not meet the preconditions? Do you think APIs should
just let the chips fall where they may regarding invalid
arguments, or do you think checking parameters and throwing IAE with
an informative message is an acceptable practice?
Phil
However, this breaks the consensus we arrived at (for v4.0) about CM
throwing only subclasses of MathRuntimeExceprion (singly rooted hierarchy).
Phil proposes to throw MathIAE (IMO, it must be the specific
NullArgumentException), but this breaks the above use-case: Users have to
do
try {
// Call CM
} catch (NullPointerException e) {
// Handle NPE (raised by the JVM).
} catch (NullArgumentException e)
// Handle NPE (raised by CM).
}
showing blatantly that CM is not consistent: sometimes it lets a JVM
exception propagate, and sometimes it catches the problem eralier and throws
an exception that is not in the same hierarchy (NPE vs IAE or, in 4.0,
MathRuntimeException).
This is the current state of affairs, and I think that it is not
satisfactory. [As proven by this issue having recurred two or three times
already.]
+1 this is terrible from an API design perspective
In light of this, I propose that either
* Phil changes his mind (no check for null performed in CM code), or
* we make an exception to the singly-rooted hierarchy just for
NullArgumentException (which, in 4.0, would become a subclass of the
standard NPE).
The second option cares for all the various positions _except_ the
singly-rooted hierarchy.
Regards,
Gilles
Hope you can all work it out. I would start by dropping the
document-by-exception thinking that seems to permeate these
discussions.
Regards,
James
-
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
Re: [Math] About NullArgumentException
Hey Phil
On Mon, Sep 10, 2012 at 5:09 PM, Phil Steitz phil.ste...@gmail.com wrote:
On 9/10/12 3:43 PM, James Ring wrote:
try {
// Call CM
} catch (NullPointerException e) {
// Handle NPE (raised by the JVM _or_ by CM).
}
Is this going to be the typical case? NPE indicates a programming
error, so this is something that *should* completely crash your JVM.
Maybe I am being stupid here, but why is NPE so vastly different
from, say, array index error and why is it bad to check parameters
against documented preconditions and throw IAE when actual
parameters do not meet the preconditions? Do you think APIs should
just let the chips fall where they may regarding invalid
arguments, or do you think checking parameters and throwing IAE with
an informative message is an acceptable practice?
I don't think NPE is different, you should check parameters against
preconditions and throw IAE as soon as you can. APIs should fail fast
so the stack traces are meaningful and errors are caught as early as
possible. Throwing IAE with an informative error is great.
Throwing an exception with a localized message seems pointless to me, FWIW.
Phil
Regards,
James
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[CANCEL][VOTE] Release Commons Codec 1.7-RC1
This VOTE is canceled to fix: - test failures on the IBM JVM - release notes (for the above), - and a missing ASF header. I will reload an RC2 tomorrow. Thank you all and especially Sebb for your diligence. Gary On Mon, Sep 10, 2012 at 7:02 PM, sebb seb...@gmail.com wrote: With IBM Java 1.6: java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260-20071123_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20071121_15015 (JIT enabled) J9VM - 20071121_015015_lHdSMR JIT - r9_20071121_1330 GC - 20071031_AA) JCL - 20071118_01 [This is quite an old IBM Java, IIRC I got it as part of an Eclipse download from IBM] I get the following failures --- Test set: org.apache.commons.codec.binary.StringUtilsTest --- Failed tests: testNewStringUtf16Be(org.apache.commons.codec.binary.StringUtilsTest): expected:?[] but was:?[?] testNewStringUtf16Le(org.apache.commons.codec.binary.StringUtilsTest): expected:?[] but was:?[?] Note that it's not possible to run Maven 2.2.1 with that version of Java; however Maven 3.0.4 works OK - 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 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-dbcp has an issue affecting its community integration. This issue affects 18 projects, and has been outstanding for 67 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-dbcp : Object Pooling - db-ddlutils : Easy-to-use component for working with Database Definition (... - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-dbcp : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-tomcat-jk : Connectors to various web servers - javax.el : Java Servlet 2.5 Server Pages JSP 2.1 implementation (for ... - javax.servlet : Java Servlet 2.5 Server Pages JSP 2.1 implementation (for ... - javax.servlet.jsp : Java Servlet 2.5 Server Pages JSP 2.1 implementation (for ... - solr : Java Based Search Engine - solr-test : Java Based Search Engine - tomcat-tc6 : Java Servlet 2.5 Server Pages JSP 2.1 implementation (for ... - tomcat-tc7.0.x : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... - tomcat-tc7.0.x-dbcp : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... - tomcat-tc7.0.x-test : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... - tomcat-trunk : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... - tomcat-trunk-dbcp : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... - tomcat-trunk-test : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-dbcp.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/gump_work/build_commons-dbcp-1.x_commons-dbcp.html Work Name: build_commons-dbcp-1.x_commons-dbcp (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only -Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml dist [Working Directory: /srv/gump/public/workspace/commons-dbcp-1.x] CLASSPATH: /usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/junit/dist/junit-11092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-11092012.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/public/workspace/commons-pool-1.x/dist/commons-pool-1.6.1-SNAPSHOT.jar - [javac]^ [javac] where T is a type-variable: [javac] T extends Object declared in method TgetObject(String,ClassT) [javac] /srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingConnection.java:65: error: DelegatingConnection is not abstract and does not override abstract method getNetworkTimeout() in Connection [javac] public class DelegatingConnection extends AbandonedTrace [javac]^ [javac] /srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java:38: error: DelegatingDatabaseMetaData is not abstract and does not override abstract method generatedKeyAlwaysReturned() in DatabaseMetaData [javac] public class DelegatingDatabaseMetaData extends AbandonedTrace [javac]^ [javac] /srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingResultSet.java:61: error: DelegatingResultSet is not abstract and does not override abstract method TgetObject(String,ClassT) in ResultSet [javac] public class DelegatingResultSet extends
[GUMP@vmgump]: Project commons-dbcp2 (in module apache-commons) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbcp2 has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 67 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp2 : Database Connection Pool
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-dbcp2-*[0-9T].jar] identifier set to project
name
-INFO- Failed with reason build failed
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/gump_work/build_apache-commons_commons-dbcp2.html
Work Name: build_apache-commons_commons-dbcp2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true
-Dbuild.sysclasspath=only
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml
dist
[Working Directory: /srv/gump/public/workspace/apache-commons/dbcp]
CLASSPATH:
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/apache-commons/dbcp/dist/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/packages/jdbc2_0/jdbc2_0-stdext.jar:/srv/gump/public/workspace/junit/dist/junit-11092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-11092012.jar:/srv/gump/public/workspace/apache-commons/pool/dist/commons-pool2-2.0-SNAPSHOT.jar
-
[mkdir] Created dir:
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] Compiling 52 source files to
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/BasicDataSource.java:52:
error: BasicDataSource is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[javac] public class BasicDataSource implements DataSource {
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingConnection.java:65:
error: DelegatingConnection is not abstract and does not override abstract
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingStatement.java:46:
error: DelegatingStatement is not abstract and does not override abstract
method isCloseOnCompletion() in Statement
[javac] public class DelegatingStatement extends AbandonedTrace implements
Statement {
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingPreparedStatement.java:57:
error: DelegatingPreparedStatement is not abstract and does not override
abstract method isCloseOnCompletion() in Statement
[javac] public class DelegatingPreparedStatement extends DelegatingStatement
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingCallableStatement.java:58:
error: DelegatingCallableStatement is not abstract and does not override
abstract method TgetObject(String,ClassT) in CallableStatement
[javac] public class DelegatingCallableStatement extends
DelegatingPreparedStatement
[javac]^
[javac] where T is a type-variable:
[javac] T extends Object declared in method
TgetObject(String,ClassT)
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingDatabaseMetaData.java:36:
error: DelegatingDatabaseMetaData is not abstract and does not override
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public
[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
and has been outstanding for 72 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-digester3 : XML to Java Object Configuration
- commons-digester3-test : Apache Commons
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-digester3-*[0-9T].jar] identifier set to
project name
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/apache-commons/digester/pom.xml
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 1 sec
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
package
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/digester/annotations-processor svn
--non-interactive info
[INFO] Working directory:
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildNumber: ?? at timestamp: 1347335552262
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/digester/annotations-processor svn
--non-interactive info
[INFO] Working directory:
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 5 source files to
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/src/test/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 3 source files to
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/test-classes
@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern=rss/channel)
@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern=rss/channel/image)
@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern=rss/channel/item)
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[INFO] 2 errors
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-chain2 has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 89 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-chain2 : GoF Chain of Responsibility pattern Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-chain2-*[0-9T].jar] identifier set to project name -DEBUG- Sole pom output [pom.xml] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/chain/pom.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/gump_work/build_apache-commons_commons-chain2.html Work Name: build_apache-commons_commons-chain2 (Type: Build) Work ended in a state of : Failed Elapsed: 57 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/chain] M2_HOME: /opt/maven2 - [INFO] Building war: /srv/gump/public/workspace/apache-commons/chain/apps/cookbook-examples/target/chain-cookbook-examples-2.0-SNAPSHOT.war [INFO] [INFO] Building Apache Commons Chain :: Distribution Packages [INFO]task-segment: [package] [INFO] [INFO] snapshot org.apache.commons:commons-chain2-configuration:2.0-SNAPSHOT: checking for updates from apache.snapshots Downloading: http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.pom [INFO] Unable to find resource 'org.apache.commons:commons-chain2-configuration:pom:2.0-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) Downloading: http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.jar [INFO] Unable to find resource 'org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.commons -DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT 2) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT from the specified remote repositories: gump-central (http://localhost:8192/maven2), gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 55 seconds [INFO] Finished at: Tue Sep 11 05:04:11 UTC 2012 [INFO] Final Memory: 113M/241M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml - Atom:
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 72 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.057 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.038 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.324 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 15 seconds [INFO] Finished at: Tue Sep 11 05:20:39 UTC 2012 [INFO] Final Memory: 25M/61M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom:
Re: [Math] About NullArgumentException
Hello, 2012/9/11 Gilles Sadowski gil...@harfang.homelinux.org: On Mon, Sep 10, 2012 at 01:31:12PM -0700, Phil Steitz wrote: On 9/10/12 11:47 AM, Sébastien Brisard wrote: Hi What should I do there? I'm trying to work on MATH-854. It turns out that FieldElementT.add throws a NAE. Should I catch it below, and rethrow it with a more detailed message (including the entry index)? IMO, yes. I would also check v itself and add to the javadoc contract that IAE is thrown if v is null. This is not consistently done in [math], though, and rarely in the linear package, so I am OK just letting the NPE propagate if v is null. It is a little awkward that v itself being null leads to NPE, but a component of it null leads to MIAE. Awkward? Of course it is; that's what I explained two posts ago. If we want to allow for the possibility of checking for null (and I agree that it could be useful to pinpoint the problem by passing the information about which index contains an invalid null entry), then we should adopt the second option which I presented in that preceding post: NullArgumentException inherits from NullPointerException This really solves all issues (now that Luc has said that it is not a problem if this one exception escapes the single-root hierarchy): It allows to check for null in CM code and raise the same kind of exception that would arise when no null check is performed. Both flexible and consistent. I may be a bit slow, but I understood that localized error messages were an absolute requirement on Luc's side (which, BTW is good to know, I have always been wondering why we cared so much about localized error messages...). So, if I understand correctly, NAE inheriting from NPE would mean no error message. In the present case, if we can't specify the index of the faulty entry in the error message, I don't see the benefit of NAE over NPE. I must have missed something; I guess that NAE would inherit from NPE, AND implement ExceptionContextProvider, is that right? In that case, I like this solution. Sorry for polluting this thread with silly questions, but I am not used to writing programs for third-party end-users (I *AM* the end-user, or maybe my student enxt door), so I have to say I'm not familiar with the concerns raised in this thread. Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] About NullArgumentException
Hi,
2012/9/11 Gilles Sadowski gil...@harfang.homelinux.org:
On Mon, Sep 10, 2012 at 08:47:35PM +0200, Sébastien Brisard wrote:
Hi
What should I do there?
If we adopt the flexible policy (cf. other post), then you can do what you
want. ;-)
This is absolutely what I do not want to do... I've already realized
that I've been too flexible on e.g. formatting this last year...
Sébastien
I'm trying to work on MATH-854. It turns out that FieldElementT.add
throws a NAE. Should I catch it below, and rethrow it with a more
detailed message (including the entry index)?
Best,
Sébastien
/** {@inheritDoc} */
public FieldVectorT add(FieldVectorT v)
throws DimensionMismatchException {
try {
return add((ArrayFieldVectorT) v);
} catch (ClassCastException cce) {
checkVectorDimensions(v);
T[] out = buildArray(data.length);
for (int i = 0; i data.length; i++) {
out[i] = data[i].add(v.getEntry(i));
// SHOULD I CATCH NAE HERE?
Not _catch_ NAE but _throw_ it; the line in the loop would become:
final T entry = v.getEntry(i);
if (entry == null) {
throw new NullArgumentException(LocalizedFormats.INDEX, i);
}
out[i] = data[i].add(entry);
}
return new ArrayFieldVectorT(field, out, false);
}
}
Regards,
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
Re: [math] Is this good practice?
Hi,
2012/9/11 Gilles Sadowski gil...@harfang.homelinux.org:
On Mon, Sep 10, 2012 at 10:07:11PM +0200, Benedikt Ritter wrote:
Hi,
2012/9/10 Luc Maisonobe luc.maison...@free.fr:
Le 10/09/2012 21:08, Sébastien Brisard a écrit :
Hi,
Hi Sébastien,
I thought it was not good practice to rely on exception in
unexceptional circumstances. In ArrayFieldVector, there are numerous
occurences of the following pattern
public FieldVectorT add(FieldVectorT v)
throws DimensionMismatchException {
try {
return add((ArrayFieldVectorT) v);
} catch (ClassCastException cce) {
checkVectorDimensions(v);
T[] out = buildArray(data.length);
for (int i = 0; i data.length; i++) {
out[i] = data[i].add(v.getEntry(i));
}
return new ArrayFieldVectorT(field, out, false);
}
}
The catch (ClassCastException cce) seems uggly to me. Should I file
a JIRA issue and start replacing with instanceof?
This was done on purpose a long time ago.
At that time, it appeared that it was faster to do it this way, i.e.
attempt by default the fast method which did not rely on getEntry, and
fall back to a loop using getEntry only in the very rare cases the first
fails.
I am not sure this is useful anymore, as JVM optimizers are better and
better (so they may well replace the getEntry on the fly and use direct
array access when they can).
Perhaps you could do some benchmark with a modern JVM and look if this
hack is still useful or not.
If it still is, a comment should be added to make future maintainers
aware of this fact.
I imagine that at the time this was coded, it was assumed that it would be
faster because it skips the conditional (the change proposed by Sébastien).
IIUC, what Luc proposes is to check whether the JIT compiler will replace
calls to getEntry with the method from the actual type. If that's true, it
would also be true that the conditional if (v instanceof ArrayFieldVector)
will be optimized away.
Hence I'd assume that the proposed change is a safe first step (removing
usage of exception for control flow).
I will try and do some benchmarking on this issue. I do not like these
micro-optimizations which tend to be true optimizations with one
version of the JVM, and are no longer with the next one.
Also, while we are at it, is there a benefit in defining a separate,
specialized method add(ArrayFieldVectorT). The other option would be
to inline this method directly in the instanceof test in the general
add(FieldVectorT). I guess the second solution would incur a slight
overhead in those cases when the compiler can resolve the actual type
of the parameter at compilation time. But I'm not sure the gain is
worth the pain (again, the JIT seems to be pretty smart). The drawback
of having two separate methods is that there is a little bit of
maintenance work in order to ensure that both have the same contract
(regarding, guess what, exceptions!). This is not a problem with the
general version of the method, which is specified in an
interface/abstract class. This is more problematic with the specific
version of the method. Of course, this only requires to be careful,
it's not so much of a hassle.
Any thoughts on this?
Sébastien
Regards,
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
