RE: [lang] Add a DaemonThreadFactory
I have a class almost identical to this in my project, so +1 to this idea.
~Roger Whitcomb
-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Tuesday, December 19, 2017 8:27 AM
To: Commons Developers List <dev@commons.apache.org>
Subject: [lang] Add a DaemonThreadFactory
I keep on copying this from project to project and it seems fitting for Commons
Lang:
import java.util.concurrent.ThreadFactory;
import java.util.concurrent.atomic.AtomicLong;
public final class DaemonThreadFactory implements ThreadFactory {
private final static AtomicLong COUNT = new AtomicLong(1);
private final String name;
public DaemonThreadFactory(final String name) {
super();
this.name = name;
}
@Override
public Thread newThread(final Runnable r) {
final Thread thread = new Thread(r, name + " " +
COUNT.getAndIncrement());
thread.setDaemon(true);
return thread;
}
}
Thoughts?
Gary
RE: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)
I have a similar method in our code -- the use case is to take user input (plain English field names, for instance) and turn it into variable names for DTOs (or similar). Another use we have for it is taking Java format ENUM_NAMES and turning them into camelCaseVariableNames for things like dynamic property sheets. ~Roger Whitcomb -Original Message- From: Duncan Jones [mailto:dun...@wortharead.com] Sent: Thursday, June 01, 2017 7:32 AM To: Commons Developers List <dev@commons.apache.org> Subject: Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter) On Thu, 1 Jun 2017 at 15:27, Gary Gregory <garydgreg...@gmail.com> wrote: > IMO camel casing is all about words so [text] WordUtils. But why not > have a CamelCaseUtils instead? > > Gary +1. IMO it belongs in TEXT (if anywhere) and we should avoid classes +with static methods. Per our other conservation about case conversions, we should carefully specify whether this uses upper- or title-case and how it behaves in different locales. OOI, what is your real world use case for this? Duncan > > On Jun 1, 2017 7:14 AM, "Rob Tompkins" <chtom...@gmail.com> wrote: > > > > > > On Jun 1, 2017, at 10:11 AM, Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > > Isn't this kind of stuff or anything camel case supposed to be in > [text] > > > > I’m ok with that path as well. It feels like it’s on the line > > between the two components. Either way, it sounds like you’re not > > opposed to adding > it > > to a component. > > > > Should it be TextUtils.toCamelCase(String str, char delimiter, > > boolean capitalizeFirstLetter), or WordUtils maybe, if we were to > > put it in > [text]? > > > > -Rob > > > > > these days? > > > > > > Gary > > > > > > On Jun 1, 2017 7:03 AM, "Rob Tompkins" <chtom...@gmail.com> wrote: > > > > > >> Hello all, > > >> > > >> Folks at my day job have a method that takes in a space delimited > String > > >> (or arbitrarily delimited string for that matter), and returns a > > >> camel cased string. Is there any reason that this shouldn’t be in > > StringUtils? It > > >> feels reasonable to me. What are folks thoughts? > > >> > > >> Cheers, > > >> -Rob > > >> - > > >> 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
[COMPRESS] Anyone implemented "pigz"?
Someone here was doing benchmarks using "pigz" (see here: http://zlib.net/pigz/, basically multi-threaded "gzip") and I couldn't find any "reasonable" Java implementations. Anyone thought about it for Commons Compress? Thanks, Roger Whitcomb
RE: [VOTE][RRESULT][RC1] Release Commons Math 3.6.1
I believe the necessity of having 3 PMC votes for a release is an Apache-wide requirement, having to do with project oversight, and legal indemnification. See http://www.apache.org/foundation/voting.html for the formal voting rules for the ASF. I don't see anywhere in this page where there is any provision for "relaxing" these requirements for any reason. ~Roger Whitcomb -Original Message- From: Gilles [mailto:gil...@harfang.homelinux.org] Sent: Monday, March 21, 2016 8:43 AM To: dev@commons.apache.org Subject: Re: [VOTE][RRESULT][RC1] Release Commons Math 3.6.1 On Mon, 21 Mar 2016 10:29:48 -0400, Evan Ward wrote: > On 03/21/2016 09:18 AM, Luc Maisonobe wrote: >> Le 21/03/2016 13:44, Evan Ward a écrit : >>> The vote passes with three votes in favor and none against. >> Well, in fact I am not sure it passes yet ... >> >> As far as I know, there are only 2 PMC members who voted: Oliver and >> myself. > > Oh, I didn't realize there had to be 3 PMC members voting. I had > already released the maven artifacts by the time I receive your > message. I'll wait to publish the site until we have a vote from a > third PMC member. > Hopefully it is a +1 so I don't have to figure out how to un-release > something. I'll update the release.howto.txt document to include a > note that a vote must have 3 PMC +1's to pass. I'll vote +1 although I do not have the time to make all the "legal" steps. It's a leap of faith because I trust that you (and Luc) take extreme care in what you do. This kind of trust is sorely missing in other circumstances. Also, concretely, I think that the requirements could be relaxed for a bug-fix release. Regards, Gilles > Best Regards, > Evan > >> >> Could a third PMC member look at it? >> >> best regards, >> Luc >> >>> Thanks for taking time to review. >>> >>> Best Regards, >>> Evan >>> >>> On 03/19/2016 11:06 PM, Matt Sicker wrote: >>>> If you add the -Xdoclint:none command line argument, that will >>>> ignore the javadoc errors. I love how the JDK itself doesn't >>>> compile without that option. >>>> >>>> On 19 March 2016 at 15:38, Oliver Heger >>>> <oliver.he...@oliver-heger.de> >>>> wrote: >>>> >>>>> Build worked fine with Java 1.6 on Windows 10. Artifacts and site >>>>> look good. I could not build the site with Java 8 because of >>>>> Javadoc errors, but this is not blocking. >>>>> >>>>> So +1 >>>>> >>>>> Oliver >>>>> >>>>> Am 17.03.2016 um 20:06 schrieb Evan Ward: >>>>>> This is a [VOTE] for releasing Apache Commons Math 3.6.1 from >>>>>> release >>>>>> candidate 1. >>>>>> >>>>>> Tag name: >>>>>> MATH_3_6_1_RC1 (signature can be checked from git using 'git >>>>>> tag -v') >>>>>> >>>>>> Tag URL: >>>>>> >>>>>> >>>>> >>>>> https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=tag;h=e40b144832c0e138b185c92326588a087e00909c >>>>>> Commit ID the tag points at: >>>>>> 16abfe5de688cc52fb0396e0609cb33044b15653 >>>>>> >>>>>> Site: >>>>>> http://home.apache.org/~evanward/commons-math-3.6.1-RC1-site >>>>>> >>>>>> Distribution files: >>>>>> https://dist.apache.org/repos/dist/dev/commons/math/ >>>>>> >>>>>> Distribution files hashes (SHA1): >>>>>> 4d4bb6741f9b5d095bcab24f5232a871ba579df0 >>>>> commons-math3-3.6.1-bin.tar.gz >>>>>> e088b160c19af7ca2596d91430b8a71aaa5ea5da >>>>>> commons-math3-3.6.1-bin.zip >>>>>> 77ffe792e4bf0d4bcd7b4e2a8ce3b07df40a92b9 >>>>> commons-math3-3.6.1-src.tar.gz >>>>>> cadad1cbb7757b2616a96b20d357e3a6acb1b4c9 >>>>>> commons-math3-3.6.1-src.zip >>>>>> >>>>>> KEYS file to check signatures: >>>>>> http://www.apache.org/dist/commons/KEYS >>>>>> >>>>>> Maven artifacts: >>>>>> >>>>>> >>>>> >>>>> https://repository.apache.org/content/repositories/orgapachecommons-1142/org/apache/commons/commons-math3/3.6.1/ >>>>>> [ ] +1 Release it. >>>>>> [ ] +0 Go ahead; I don't care. >>>>>> [ ] -0 There are a few minor glitches: ... >>>>>> [ ] -1 No, do not release it because ... >>>>>> >>>>>> This vote will close in 72 hours, at 2016-03-20T12:00:00Z (this >>>>>> is UTC >>>>>> time). >>>>>> >>>>>> Best Regards, >>>>>> Evan >>>>>> - 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: [VFS] Further changes to HDFS Provider for alternate configuration support
I have opened issue https://issues.apache.org/jira/browse/VFS-586 with my proposed patch attached, and these questions included in the issue. Updated the patch with some things I noticed after the initial post also. Thanks, ~Roger -Original Message- From: dlmar...@comcast.net [mailto:dlmar...@comcast.net] Sent: Monday, November 16, 2015 3:11 PM To: 'Commons Developers List' <dev@commons.apache.org> Subject: RE: [VFS] Further changes to HDFS Provider for alternate configuration support I don't see the patch. It might be stripped off by the mail server. From: Roger Whitcomb [mailto:roger.whitc...@actian.com] Sent: Monday, November 16, 2015 5:12 PM To: Commons Developers List Subject: [VFS] Further changes to HDFS Provider for alternate configuration support Hi all, In trying to solve some customer issues we're having, mainly to do with trying to browse HDFS files when the Name Node is configured for High-Availability, I found I needed to make some more changes/additions to the VFS HDFS Provider. I have attached a diff/patch file. But, a couple of questions: . This is a follow-on (basically) to my earlier patch for VFS-555, should I open a new JIRA, or just reopen the existing one? . Since this actually changes an API (but which is not released yet), is that an acceptable thing to do? . The new properties I have added to HdfsFileSystemConfigBuilder are not actually symmetrical, so they don't fit the definition of a Java "property", that is the setters are "setXXX" while the getters are "getXXXs" (plural). The logic behind this is that the setters are called by user code, and each can be called multiple times. The getters are only (meant to be) called by the HdfsFileSystem object (that is internally to the HdfsProvider), and thus it is a lot easier to get all the settings at once than to have to make multiple calls, with potentially iterators, etc. . Is this too big a change to fit in last-minute before the release of VFS 2.1? Patch is attached. Thanks, ~Roger Whitcomb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Further changes to HDFS Provider for alternate configuration support
Okay, I'll go ahead and make a new JIRA issue, then, and attach the patch there. Thanks, ~Roger From: Pascal Schumacher <pascalschumac...@gmx.net> Sent: Tuesday, November 17, 2015 9:48 AM To: Commons Developers List Subject: Re: [VFS] Further changes to HDFS Provider for alternate configuration support Yes, the mailing list server does not allow attachments. Please attach the patch to a JIRA issue. Thanks! Am 17.11.2015 um 00:11 schrieb dlmar...@comcast.net: > I don't see the patch. It might be stripped off by the mail server. > > > > From: Roger Whitcomb [mailto:roger.whitc...@actian.com] > Sent: Monday, November 16, 2015 5:12 PM > To: Commons Developers List > Subject: [VFS] Further changes to HDFS Provider for alternate configuration > support > > > > Hi all, > > In trying to solve some customer issues we're having, mainly > to do with trying to browse HDFS files when the Name Node is configured for > High-Availability, I found I needed to make some more changes/additions to > the VFS HDFS Provider. I have attached a diff/patch file. But, a couple of > questions: > > . This is a follow-on (basically) to my earlier patch for VFS-555, > should I open a new JIRA, or just reopen the existing one? > > . Since this actually changes an API (but which is not released > yet), is that an acceptable thing to do? > > . The new properties I have added to HdfsFileSystemConfigBuilder are > not actually symmetrical, so they don't fit the definition of a Java > "property", that is the setters are "setXXX" while the getters are "getXXXs" > (plural). The logic behind this is that the setters are called by user code, > and each can be called multiple times. The getters are only (meant to be) > called by the HdfsFileSystem object (that is internally to the > HdfsProvider), and thus it is a lot easier to get all the settings at once > than to have to make multiple calls, with potentially iterators, etc. > > . Is this too big a change to fit in last-minute before the release > of VFS 2.1? > > > > Patch is attached. > > > > Thanks, > > ~Roger Whitcomb > > - 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: [VFS] Further changes to HDFS Provider for alternate configuration support
I have created https://issues.apache.org/jira/browse/VFS-586 and attached the proposed patch there for your consideration. The original questions I had still apply, and will be added to the issue. Thanks, ~Roger Whitcomb -Original Message- From: Pascal Schumacher [mailto:pascalschumac...@gmx.net] Sent: Tuesday, November 17, 2015 9:48 AM To: Commons Developers List <dev@commons.apache.org> Subject: Re: [VFS] Further changes to HDFS Provider for alternate configuration support Yes, the mailing list server does not allow attachments. Please attach the patch to a JIRA issue. Thanks! Am 17.11.2015 um 00:11 schrieb dlmar...@comcast.net: > I don't see the patch. It might be stripped off by the mail server. > > > > From: Roger Whitcomb [mailto:roger.whitc...@actian.com] > Sent: Monday, November 16, 2015 5:12 PM > To: Commons Developers List > Subject: [VFS] Further changes to HDFS Provider for alternate > configuration support > > > > Hi all, > > In trying to solve some customer issues we're having, > mainly to do with trying to browse HDFS files when the Name Node is > configured for High-Availability, I found I needed to make some more > changes/additions to the VFS HDFS Provider. I have attached a > diff/patch file. But, a couple of > questions: > > . This is a follow-on (basically) to my earlier patch for VFS-555, > should I open a new JIRA, or just reopen the existing one? > > . Since this actually changes an API (but which is not released > yet), is that an acceptable thing to do? > > . The new properties I have added to HdfsFileSystemConfigBuilder are > not actually symmetrical, so they don't fit the definition of a Java > "property", that is the setters are "setXXX" while the getters are "getXXXs" > (plural). The logic behind this is that the setters are called by user > code, and each can be called multiple times. The getters are only > (meant to be) called by the HdfsFileSystem object (that is internally > to the HdfsProvider), and thus it is a lot easier to get all the > settings at once than to have to make multiple calls, with potentially > iterators, etc. > > . Is this too big a change to fit in last-minute before the release > of VFS 2.1? > > > > Patch is attached. > > > > Thanks, > > ~Roger Whitcomb > > - 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
[VFS] Further changes to HDFS Provider for alternate configuration support
Hi all, In trying to solve some customer issues we're having, mainly to do with trying to browse HDFS files when the Name Node is configured for High-Availability, I found I needed to make some more changes/additions to the VFS HDFS Provider. I have attached a diff/patch file. But, a couple of questions: * This is a follow-on (basically) to my earlier patch for VFS-555, should I open a new JIRA, or just reopen the existing one? * Since this actually changes an API (but which is not released yet), is that an acceptable thing to do? * The new properties I have added to HdfsFileSystemConfigBuilder are not actually symmetrical, so they don't fit the definition of a Java "property", that is the setters are "setXXX" while the getters are "getXXXs" (plural). The logic behind this is that the setters are called by user code, and each can be called multiple times. The getters are only (meant to be) called by the HdfsFileSystem object (that is internally to the HdfsProvider), and thus it is a lot easier to get all the settings at once than to have to make multiple calls, with potentially iterators, etc. * Is this too big a change to fit in last-minute before the release of VFS 2.1? Patch is attached. Thanks, ~Roger Whitcomb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [COMPRESS] Compress GUI?
Hi Don, That's awesome! I was thinking of a cross between the UI of WinZip (i.e., big toolbar icons, etc.) and 7-Zip (small cheesy icons, big file browser area). The idea would be to have clean, flat icons and maybe a split pane window with potential source files on the left and target (compressed files) on the right? Or maybe you have two tabs at the top: "Compress" and "Decompress" which would switch these two panes around I'm not sure, just throwing ideas around. But definitely if you have ideas, please feel free to experiment. But, given that Pivot has several forms of file browser available, including one that leverages Commons VFS, it might be better to have the main window be the compressed targets and use the file browsers for the "Add To" file list and the "Save To" / "Expand to" target directory. But again, just thinking aloud. I should mention that the VFS file browser is not in the released Pivot code (i.e., the 2.0.4 version or the 2.0.x branch), but only in "trunk". But building "trunk" is quite easy once you get the code: put Junit in the class path and run "ant clean package". So, I guess I'd like to see the Pivot Commons VFS file browser really put to the test also -- I wrote it, but have only really used it with my own VFS file system, and for HDFS files. But, it would be awesome to be able to navigate to an HDFS file system, open up a zip file from there and expand it to a local directory (for instance). I don't know of any other utility out there that can do that I'd like to help however I can, plus definitely if you need help with Pivot, don't be afraid to ask. You can subscribe to the Pivot mailing list(s) as well for help Many thanks, ~Roger From: Donald Freeman <dbfre...@yahoo.com.INVALID> Sent: Monday, November 2, 2015 1:04 PM To: Commons Developers List; Commons Developers List Subject: Re: [COMPRESS] Compress GUI? Roger, I did go back and look at your previous email and had seen that you mentioned pivot. I started the initial workings of a project last night and started to read a little about pivot. I think I could pull it off given a few weeks time. Do you have any ideas of what you were thinking of from the design standpoint or should I just work something up and see where it goes? Thoughts??? From:"Roger Whitcomb" <roger.whitc...@actian.com> Date:Mon, Nov 2, 2015 at 2:41 PM Subject:Re: [COMPRESS] Compress GUI? Well, being that I'm the Apache Pivot PMC Chair, I was looking for "cross-fertilization" opportunities. So, my preferred GUI environment would be Apache Pivot. Of course, you're probably not familiar with it, but I think the resultant GUIs are easier to build and better-looking than Swing. And one of the original architects of Pivot then went on to work on JavaFX, so we're pretty sure that Pivot has a good pedigree ~Roger From: Donald Freeman <dbfre...@yahoo.com.INVALID> Sent: Saturday, October 31, 2015 5:07 AM To: Commons Developers List; Commons Developers List Subject: Re: [COMPRESS] Compress GUI? I could possibly come up with some time over the next several weeks to work on the UI. What technology were you thinking Swing, JavaFX??? I am not really that familiar with compress so I may need some help with the library itself. From:"Stefan Bodewig" <bode...@apache.org> Date:Sat, Oct 31, 2015 at 7:22 AM Subject:Re: [COMPRESS] Compress GUI? On 2015-10-30, Roger Whitcomb wrote: > Any thoughts? Anyone who might be interested in helping with such a > project? TBH, I hate doing GUI stuff. :-) I can easily see that a GUI for Compress would be nice, though. If people want to work on a GUI and need help dealing with the Compress library itself, I'll be happy to lend a hand. The GUI and the Compress library should be separate artifacts IMHO. Stefan - 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: [COMPRESS] Compress GUI?
Well, being that I'm the Apache Pivot PMC Chair, I was looking for "cross-fertilization" opportunities. So, my preferred GUI environment would be Apache Pivot. Of course, you're probably not familiar with it, but I think the resultant GUIs are easier to build and better-looking than Swing. And one of the original architects of Pivot then went on to work on JavaFX, so we're pretty sure that Pivot has a good pedigree ~Roger From: Donald Freeman <dbfre...@yahoo.com.INVALID> Sent: Saturday, October 31, 2015 5:07 AM To: Commons Developers List; Commons Developers List Subject: Re: [COMPRESS] Compress GUI? I could possibly come up with some time over the next several weeks to work on the UI. What technology were you thinking Swing, JavaFX??? I am not really that familiar with compress so I may need some help with the library itself. From:"Stefan Bodewig" <bode...@apache.org> Date:Sat, Oct 31, 2015 at 7:22 AM Subject:Re: [COMPRESS] Compress GUI? On 2015-10-30, Roger Whitcomb wrote: > Any thoughts? Anyone who might be interested in helping with such a > project? TBH, I hate doing GUI stuff. :-) I can easily see that a GUI for Compress would be nice, though. If people want to work on a GUI and need help dealing with the Compress library itself, I'll be happy to lend a hand. The GUI and the Compress library should be separate artifacts IMHO. Stefan - 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
[COMPRESS] Compress GUI?
Hi all, I was just looking at the GUI for 7-Zip today (had to use it) and it struck me that using Apache Pivot and Commons Compress, we (someone, me perhaps, with some help) could come up with an Apache Commons Zip GUI that would be even better looking, and be a viable alternative... Any thoughts? Anyone who might be interested in helping with such a project? Thanks, ~Roger Whitcomb Apache Pivot PMC Chair
RE: [ALL] Missing commit e-mails - INFRA-7716
It might just be that the backlog of emails hasn't cleared yet ... (see : https://blogs.apache.org/infra/entry/mail_outage ) They say it could take from 2-5 days after the 10th to get all the backlog delivered ... ~Roger -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, May 13, 2014 6:17 PM To: dev@commons.apache.org Subject: [ALL] Missing commit e-mails - INFRA-7716 I did a comparison of recent SVN log entries (since just before the mail outage) against the contents of the commits mail archive, and found that several e-mails seem to have got lost, so I raised INFRA -7716. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [lang]
Just wanted to mention that the Apache Pivot project (Java GUI framework) uses IAE for most/all cases of null or invalid input arguments (that is, cases where we check the input arguments), reserving NPE for basically the JVM to throw. ~Roger Whitcomb -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Wednesday, May 07, 2014 9:25 PM To: Commons Developers List Subject: Re: [lang] I have to say that if you look at the JDK for examples of how to code Java correctly you will be disappointed. There are lots and lots of classes that are really bad. Ralph On May 6, 2014, at 2:54 PM, Paul Benedict pbened...@apache.org wrote: This is not a matter of law. If Oracle/Sun set a direction on how to use NPE, it's a really good idea to follow them -- even if you don't agree, do it for the sake of consistency. I don't think using IAE is somehow better Java than what they are doing. And I give weight to what Joshua said because he's a former architect of that company. Lang3 was designed to throw NPE on invalid null arguments because that's what the gurus, like he, in our industry who publish best practices say it should. If your opinion bears greater weight than those set forth the best practices, then you win, but I don't advocate going back to IAE for nulls for the reasons stated. Cheers, Paul On Tue, May 6, 2014 at 4:40 PM, Duncan Jones dun...@wortharead.com wrote: On 6 May 2014 22:27, Michael Osipov 1983-01...@gmx.net wrote: Am 2014-05-06 15:27, schrieb Benedikt Ritter: Hi Thiago, 2014-05-06 14:53 GMT+02:00 Thiago Andrade thia...@gmail.com: Hello people, Analizing the JIRA issue https://issues.apache.org/jira/browse/LANG-1008the contributors noticed that NumberUtils.max/min methods all have the same problem: They all throw an IllegalArgumentException when according to the official documentation (Oracle|Sun) says that a NullPointerException must be thrown when an argument must not be null. This is not a problem imho. It is a question of API design. I don't now an offical documentation that say when IAE or NPE _must_ be thrown. Sun/Oracle at some point decided to throw NPE when ever a null reference is passed to a method that doesn't accept null inputs. I don't feel this is right, since a null input is also an illegal argument. Why make a differenciation? IMHO NPE should be reserved to the JVM, when a method is called on a null reference, but that's just my opinion. It *is* a problem because NullPointerException and IllegalArgumentException have concrete semantics layed out in the JDK's Javadocs. If you see how both are used in the JDK, you see that NPE and IAE are used properly and there is no such restriction to the JDK only. If you aread Effective Java, you'll see that you *have to* use NPE if a null argument is passed. One might remember the NullArgumentException back in Lang 2, it was removed because it is imperative to use NPE instead. Effective Java is a great book, but don't confuse Joshua's advice with law. Moreover, the Lang 3 package includes a great class, Validate, which does things right and now I can ask, why the hell is that not used throughout the entire library? +1 to this. We should update all of lang to use Validate once we've +nailed this issue. Duncan However according to Apache Commons Lang Developer Guide, these methods are all correct. This guide says that When throwing an exception to indicate a bad argument, always try to throw IllegalArgumentException, even if the argument was null. Do not throw NullPointerException.. Correct to the dev guide only -- not Java. Since [lang] is currently designed this way, I'd rather deal with this issue for 4.0. We can then revisit our initial decision to only throw IAE an maybe align it to what the JDK now does. If you want to file an issue, my opinion is, that it should be fix version 4.0. Changing the exceptions that are thrown now may break clients (although I think there are very few use cases where one should catch IAE or NPE). 4.0 has to use Validate throughout the entire package. NPE and IAE indicate a programming error in the client not adhering to the contract depicted by the Javadocs, so it is the client's problem to deal with them. With proper programming, you should not have to catch those exception at all. This mail was sent in order to discuss around and make decisions to solve this dilemma where the Java official specification says X and the Apache official specification says Y. Can you please provide a lnk to the official specification you're refering to? ;-) Read Effective Java on exceptions. Thiago provided a URL in the JIRA issue. Further good resources: 1. http://docs.oracle.com/javase/7/docs/api/java/lang/NullPointerExcepti on.html 2. http://docs.oracle.com/javase/tutorial
