[jira] [Commented] (MATH-1486) Add Automatic-Module-Name
[ https://issues.apache.org/jira/browse/MATH-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857825#comment-16857825 ] Stephen Colebourne commented on MATH-1486: -- [https://github.com/apache/commons-math/pull/107] > Add Automatic-Module-Name > - > > Key: MATH-1486 > URL: https://issues.apache.org/jira/browse/MATH-1486 > Project: Commons Math > Issue Type: Task >Affects Versions: 3.6.1 >Reporter: Stephen Colebourne >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Add an 'Automatic-Module-Name' to the manifest to support projects on Java 9 > or later. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MATH-1486) Add Automatic-Module-Name
Stephen Colebourne created MATH-1486: Summary: Add Automatic-Module-Name Key: MATH-1486 URL: https://issues.apache.org/jira/browse/MATH-1486 Project: Commons Math Issue Type: Task Affects Versions: 3.6.1 Reporter: Stephen Colebourne Add an 'Automatic-Module-Name' to the manifest to support projects on Java 9 or later. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1339) Some classes depend on the java.desktop profile
[ https://issues.apache.org/jira/browse/LANG-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244913#comment-16244913 ] Stephen Colebourne commented on LANG-1339: -- In all plans we're discussing, the existing classes should be deprecated, so that should just be done. The question then becomes whether to: 1) add a fixed version alongside the broken one now 2) alter the existing class incompatibly in v4 3) removed the existing class altogether in v4 If the functionality is to be kept, I'd choose option 1, as there is no guarantee that v4 will ever happen. > Some classes depend on the java.desktop profile > --- > > Key: LANG-1339 > URL: https://issues.apache.org/jira/browse/LANG-1339 > Project: Commons Lang > Issue Type: Task >Reporter: Benedikt Ritter > Labels: Java9 > Fix For: 3.8 > > > Commons Lang currently depends on java.desktop. This seems like an > unnecessary heavy dependency for a library like Commons Lang. We need to find > a way to fix this, without breaking bc. For more information see > https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LANG-1339) Some classes depend on the java.desktop profile
[ https://issues.apache.org/jira/browse/LANG-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244324#comment-16244324 ] Stephen Colebourne commented on LANG-1339: -- Personally I don't think that another package name fork of commons-lang is a good idea, as it just results in multiple copies of what are fundamentally the same classes on the classpath. Ignoring this issue means that there is no way to avoid the java.desktop dependency when using commons-lang v3.x forevermore. A better solution is to provide a way to use the functionality, but avoid the dependency. Then users can migrate across to the new code and the old code can just sit there are be ignored. See my last comment for details. > Some classes depend on the java.desktop profile > --- > > Key: LANG-1339 > URL: https://issues.apache.org/jira/browse/LANG-1339 > Project: Commons Lang > Issue Type: Task >Reporter: Benedikt Ritter > Labels: Java9 > Fix For: 3.8 > > > Commons Lang currently depends on java.desktop. This seems like an > unnecessary heavy dependency for a library like Commons Lang. We need to find > a way to fix this, without breaking bc. For more information see > https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (LANG-1363) Add module-info.java file
Stephen Colebourne created LANG-1363: Summary: Add module-info.java file Key: LANG-1363 URL: https://issues.apache.org/jira/browse/LANG-1363 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Priority: Minor Fix For: 3.x Pull Request #299 - https://github.com/apache/commons-lang/pull/299 - proposes adding a module-info.java file to lang, with the associated pom.xml and travis changes. The build still works on JDK 7 and 8 by excluding the module file where necessary. Releases will need to be done using JDK 9. Animal sniffer, clirr, [coveralls|https://github.com/trautonen/coveralls-maven-plugin/issues/112] and findbugs do not work. Animal sniffer is not needed anymore with Java 9. Findbugs is replaced by spotbugs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (LANG-1362) Fix tests for Java 9
Stephen Colebourne created LANG-1362: Summary: Fix tests for Java 9 Key: LANG-1362 URL: https://issues.apache.org/jira/browse/LANG-1362 Project: Commons Lang Issue Type: Bug Reporter: Stephen Colebourne Fix For: 3.7 On Java 9 I see DateUtilsTest fail. This is because "MST7MDT" zone is not formatted as "MST". I'm unclear as to why this is, but it is not relevant to what the test is trying to do. As such, I've changed the zone to "America/Denver" and changed the format letter from "z" to "XXX" to make it more reliable. The PR also uses try-finally when setting the default time-zone to avoid pollution of global state if a test fails (the pollution here made it look like 8 test failures when there was only in fact 1). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LANG-1339) Some classes depend on the java.desktop profile
[ https://issues.apache.org/jira/browse/LANG-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053991#comment-16053991 ] Stephen Colebourne commented on LANG-1339: -- The best option seems to be to abuse the "requires static" concept, making the "java.desktop" dependency optional. While the offending classes could be deprecated and replaced, there seems to be an unwillingness to do so without changing the package name (my view is that changing the package name again would be a mistake). > Some classes depend on the java.desktop profile > --- > > Key: LANG-1339 > URL: https://issues.apache.org/jira/browse/LANG-1339 > Project: Commons Lang > Issue Type: Task >Reporter: Benedikt Ritter > Labels: Java9 > Fix For: 3.7 > > > Commons Lang currently depends on java.desktop. This seems like an > unnecessary heavy dependency for a library like Commons Lang. We need to find > a way to fix this, without breaking bc. For more information see > https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LANG-816) introduce ConstantUtils class to prevent Javac from inlining constants
[
https://issues.apache.org/jira/browse/LANG-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13440102#comment-13440102
]
Stephen Colebourne commented on LANG-816:
-
I'd suggest adding this to ObjectUtils if it gets done.
introduce ConstantUtils class to prevent Javac from inlining constants
--
Key: LANG-816
URL: https://issues.apache.org/jira/browse/LANG-816
Project: Commons Lang
Issue Type: Wish
Reporter: Julius Davies
Priority: Trivial
ConstantUtils could contain a set of methods to ensure constants are not
inlined by javac.
For example, typically a developer might declare a constant like
{code}
public final static int MAGIC_NUMBER = 5;
{code}
Should a different jar file refer to this, and the MAGIC_NUMBER is changed a
later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to be
recompiled. This is because javac typically inlines the primitive or String
constant directly into the bytecode, and removes the reference to the
MAGIC_NUMBER field.
To help the other jar (so that it does not need to recompile when constants
are changed) the original developer can declare their constant using one of
the CONST() utility methods, instead:
{code}
public final static int MAGIC_NUMBER = CONST(5);
{code}
I imagine the code would look something like this:
{code}
public static boolean CONST(boolean v) { return v; }
public static byte CONST(byte v) { return v; }
public static char CONST(char v) { return v; }
public static short CONST(short v) { return v; }
public static int CONST(int v) { return v; }
public static long CONST(long v) { return v; }
public static float CONST(float v) { return v; }
public static double CONST(double v) { return v; }
public static T T CONST(T t) { return t; }
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-744) StringUtils throws java.security.AccessControlException on Google App Engine
[
https://issues.apache.org/jira/browse/LANG-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13091797#comment-13091797
]
Stephen Colebourne commented on LANG-744:
-
[lang] already handles something similar in SystemUtils, line 1266
http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/SystemUtils.java?revision=1160564view=markup
StringUtils throws java.security.AccessControlException on Google App Engine
Key: LANG-744
URL: https://issues.apache.org/jira/browse/LANG-744
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0.1
Environment: Google App Engine
Reporter: Clément Denis
Fix For: 3.0.2
In the static initializer of org.apache.commons.lang3.StringUtils, there is
an attempt to load the class sun.text.Normalizer.
Such a class is prohibited on Google App Engine, and the static intializer
throws a java.security.AccessControlException.
{code}
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.sun.text)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
at java.lang.Class.checkMemberAccess(Class.java:2164)
at java.lang.Class.getMethod(Class.java:1602)
at org.apache.commons.lang3.StringUtils.clinit(StringUtils.java:739)
{code}
The exception should be caught in the catch clauses around
loadClass(sun.text.Normalizer).
Commons lang 2 worked fine on GAE.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-702) New component for lang -- summarizer
[ https://issues.apache.org/jira/browse/LANG-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13040851#comment-13040851 ] Stephen Colebourne commented on LANG-702: - Anything that talks about customizable and strategy makes me doubt it for [lang]. The main problem in [lang] is restricting its size to the most important common utilities. This one doesn't look essential enough to me, and too many other people would probably want to do it in a different way. [functor]'s assessment may be very different. New component for lang -- summarizer Key: LANG-702 URL: https://issues.apache.org/jira/browse/LANG-702 Project: Commons Lang Issue Type: New Feature Components: General Affects Versions: 3.0 Reporter: Liviu Tudor Priority: Minor Labels: features, newbie Fix For: 3.x Attachments: patch_summarizer.diff Hi, I'm creating this as a patch request but I guess really initially I wanted to verify with everyone that commons lang is the place for this class hierarchy I'm proposing -- and if not please suggest whether it would be more appropriate to submit this to collections or one of the other Commons projects. (Or I accept as well the fact that it might not be good enough for any of the commons projects in which case please just let me know so I won't try to create new issues around this in the future.) Basically I've come across a pattern I find myself using a lot in my applications where I want a quick (and not so dirty) way of monitoring certain things in the application -- for instance, I want as a quick healthcheck a page to tell me how many requests we process over a 1 minute interval or so. While one can implement complex monitoring systems to achieve the same, a lot of the times, simply the fact that the number of successful transactions per minute goes down to 50% (after an application upgrade for instance) is a clear indicator to me that something isn't right so I can start investigating straight away and not wait for our monitoring systems to kick in one hour later or so and alert us of this. As such I have developed this component which I have called Summarizer (purely as my initial request was just to sum up some numbers over a period of time and reset it regularly -- but as my javadoc comments state, of course this doesn't have to be a simple arithmetic sum and can be extended to other operations). The diff I'm proposing here contains the base class and an example of the class using integers which just sums them up -- which is as I said the kind of implementation that I have found myself implementing a lot in my apps. I appreciate that the classes are not completely finished and there are no unit tests yet -- and that is because as I said at this stage I am trying to figure out whether this component would fit into the Commons Lang component or it would be more appropriate to commit this somewhere else. I would appreciate your input/comments on this so I know whether i'm on the right track on committing this here or should I move it elsewhere; I accept that perhaps the package names and the class names are not the best, and am willing to discuss with your main committers around this -- if this proves to be a valid component for commons. If you decide this is a good idea to proceed with then I can start adding unit tests and more comments/javadocs around it to make this into a usable class hierarchy. As suggested by your FAQ's I've created a diff from the root of the folder -- if it helps more if I just provide the 2 classes I can do so too -- just let me know and I can send you a zip with the 2 classes alone or so. Looking forward to your comments on this, Liv -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-684) Levenshtein Distance Within a Given Threshold
[ https://issues.apache.org/jira/browse/LANG-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13039170#comment-13039170 ] Stephen Colebourne commented on LANG-684: - Well, we should either move all Levenshtein distance to [codec] or add this. I've never used LD, but constraining the time itoperates in seems like a Good Idea to me. Levenshtein Distance Within a Given Threshold - Key: LANG-684 URL: https://issues.apache.org/jira/browse/LANG-684 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Eli Lindsey Priority: Minor Fix For: 3.x Attachments: LevenshteinDistanceWithThreshold.patch It'd be nice to have a function that calculates the Levenshtein distance only if it's within some integer threshold. Oftentimes you care less about the actual LD and more about it being within a certain range. This common, limited computation can be performed much faster than the normal unbounded LD method; instead of O(nm), you can do it in O(km) (n and m are string lengths, k is the threshold). Also, providing a function like this makes it easier for library users to rewrite the unbounded Levenshtein function to run in O(dm) time (d is the edit distance) if necessary. I'm attaching a patch that implements this function and adds appropriate test cases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-213) CollectionUtils API extension: algorithm methods accept an Iterator argument
[ https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038595#comment-13038595 ] Stephen Colebourne commented on COLLECTIONS-213: Dont forget that [collections] has ResettableIterator, so there is another case to consider. CollectionUtils API extension: algorithm methods accept an Iterator argument Key: COLLECTIONS-213 URL: https://issues.apache.org/jira/browse/COLLECTIONS-213 Project: Commons Collections Issue Type: Improvement Components: Core Reporter: Dusan Chromy Assignee: Brent Worden Fix For: 4.x Attachments: COLLECTIONS-213.patch, CollectionUtils.java, TestCollectionUtils.java, collections-4.0-213.diff I just finished the Iterator additions to CollectionUtils, including test cases and I am going to attach them to this issue very shortly (basically as soon as I figure out how attaching in JIRA works :) At first I was thinking for a while whether CollectionUtils is a good place to accomodate the methods with the new signature, until I noticed the collect method already accepts an Iterator argument. Following methods now accept an Iterator argument (besides collect): cardinality find forAllDo countMatches exists I also noticed cardinality used to throw a NPE if the collection argument was null. I see no reason why it should not return zero. The Iterator flavour does return zero and I also modified the Collection version to return zero (including Javadoc modification) for the sake of consistence. I stopped to think for a while before touching the method, but the fact that the Javadoc does not mention may not be null made me think the NPE is not thrown intentionally. And after all, cardinality(..) is nothing else than specialized countMatches(..), which returns 0 for null collection. However, feel free to reject the change to the cardinality(Object,Collection) method if you think otherwise. I worked on a fresh checkout from subversion and I just updated few minutes ago to make sure I have modified the latest version. Anyway, please double-check before commiting the changes. Cheers, Dusan I think that these methods would make useful additions to the API. I don't have the time to do much collections work these days, but if you want to code the methods with test cases and attach them to JIRA then that would be great. Stephen dusan.chr...@freenet.de wrote: I've been using some algorithm methods from the CollectionUtils, for example find(Collection, Predicate) exists(Collection, Predicate) countMatches(Collection, Predicate) forAllDo(Collection, Closure) However, I would also like to be able to use these algorithms with an Iterator: find(Iterator, Predicate) exists(Iterator, Predicate) countMatches(Iterator, Predicate) forAllDo(Iterator, Closure) The obvious workaround is to use IteratorUtils.toList(Iterator), however this comes at the cost of constructing a list object (an ArrayList presumably) which could be avoided, as the Iterator itself is sufficient for the above algorithms to work. What do you think? Is there any reason not to provide the algorithms for an Iterator? I personally think that the algorithms should have been there for Iterators in the first place, because every collection is Iterable (or has an Iterator, prior to JDK 5.0). If noone is interested or has time to implement these changes, I can also contribute to the project - but at the moment I just wanted to discuss the idea / check if this has been already considered or planned. Best Regards, Dusan Chromy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-213) CollectionUtils API extension: algorithm methods accept an Iterator argument
[ https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13037442#comment-13037442 ] Stephen Colebourne commented on COLLECTIONS-213: I believe am Iterable implementation that wraps an Iterator is a very good idea for [collections] and simplifying its API. CollectionUtils API extension: algorithm methods accept an Iterator argument Key: COLLECTIONS-213 URL: https://issues.apache.org/jira/browse/COLLECTIONS-213 Project: Commons Collections Issue Type: Improvement Components: Core Reporter: Dusan Chromy Assignee: Brent Worden Fix For: 4.x Attachments: COLLECTIONS-213.patch, CollectionUtils.java, TestCollectionUtils.java, collections-4.0-213.diff I just finished the Iterator additions to CollectionUtils, including test cases and I am going to attach them to this issue very shortly (basically as soon as I figure out how attaching in JIRA works :) At first I was thinking for a while whether CollectionUtils is a good place to accomodate the methods with the new signature, until I noticed the collect method already accepts an Iterator argument. Following methods now accept an Iterator argument (besides collect): cardinality find forAllDo countMatches exists I also noticed cardinality used to throw a NPE if the collection argument was null. I see no reason why it should not return zero. The Iterator flavour does return zero and I also modified the Collection version to return zero (including Javadoc modification) for the sake of consistence. I stopped to think for a while before touching the method, but the fact that the Javadoc does not mention may not be null made me think the NPE is not thrown intentionally. And after all, cardinality(..) is nothing else than specialized countMatches(..), which returns 0 for null collection. However, feel free to reject the change to the cardinality(Object,Collection) method if you think otherwise. I worked on a fresh checkout from subversion and I just updated few minutes ago to make sure I have modified the latest version. Anyway, please double-check before commiting the changes. Cheers, Dusan I think that these methods would make useful additions to the API. I don't have the time to do much collections work these days, but if you want to code the methods with test cases and attach them to JIRA then that would be great. Stephen dusan.chr...@freenet.de wrote: I've been using some algorithm methods from the CollectionUtils, for example find(Collection, Predicate) exists(Collection, Predicate) countMatches(Collection, Predicate) forAllDo(Collection, Closure) However, I would also like to be able to use these algorithms with an Iterator: find(Iterator, Predicate) exists(Iterator, Predicate) countMatches(Iterator, Predicate) forAllDo(Iterator, Closure) The obvious workaround is to use IteratorUtils.toList(Iterator), however this comes at the cost of constructing a list object (an ArrayList presumably) which could be avoided, as the Iterator itself is sufficient for the above algorithms to work. What do you think? Is there any reason not to provide the algorithms for an Iterator? I personally think that the algorithms should have been there for Iterators in the first place, because every collection is Iterable (or has an Iterator, prior to JDK 5.0). If noone is interested or has time to implement these changes, I can also contribute to the project - but at the moment I just wanted to discuss the idea / check if this has been already considered or planned. Best Regards, Dusan Chromy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-305) functors filtering on bean properties using(== ,!=, ,=..=. isNull, Like,..... )
[
https://issues.apache.org/jira/browse/COLLECTIONS-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13037443#comment-13037443
]
Stephen Colebourne commented on COLLECTIONS-305:
As of today and currently released components, this would reside in [beanutils].
functors filtering on bean properties using(== ,!=, ,=..=. isNull,
Like,. )
-
Key: COLLECTIONS-305
URL: https://issues.apache.org/jira/browse/COLLECTIONS-305
Project: Commons Collections
Issue Type: Improvement
Components: Functor
Affects Versions: 3.2
Reporter: Anil K.Kinge
Assignee: Brent Worden
Attachments: functors.propertypredicates.new.diff
In my current project I created a set of new Predicates that I call as
Property Predicates. These predicates can used to filter a collection based
on property values.
For example we have :
Class Foo{
String name;
Int age;
Address address;
}
Address{
String street;
String zip;
}
CollectionFoo myFoos ;
And we want to find all the Foo in myFoos with name that starts with A, and
age 40 and who are living at Zip 07095 we can create a Predicate like
follows:
Predicate p = new PropertyLikePredicate(name,A*)
.andGreaterThan(age,40)
.andEquals(address.zip,07095);
Note: Like supports wildcards '*' and '?'
What is even better is that these predicates work with collections too. What
I mean is if we have :
FooBar{
String name;
CollectionAddress addresses;
}
And you want to locate someone with a zip 07095 as part of anyof its'
addresses all we need is to create a predicate :
Predicate p = new PropertyEqualsPredicate(addresses[].zip,07095);
My Predicate chain currently supports the following features:
1.andEquals
2.orEquals
3.andNotEquals
4.orNotEquals
5.andLike
6.orLike
7.andGreatorThan
8.orGreatorThan
9.andGreatorThanOrEquals
10. orGreatorThanOrEquals
11. andLessThan
12. orLessThan
13. andLessThanOrEquals
14. orLessThanOrEquals
15. isNull
16. isNotNull
17. orNull
18. orNotNull
19. orNullOrEmpty
20. orNotNullOrEmpty
21. andNullOrEmpty
22. andNotNullOrEmpty
All features have accompanying testcases. In my opinion this is a powerful
addition to the functors and I would like to contribute this work to the
commons-collection.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-272) LineIterator could easily support Iterable
[ https://issues.apache.org/jira/browse/IO-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032124#comment-13032124 ] Stephen Colebourne commented on IO-272: --- Doing so would imply that the iterator is closed after use, but it isn't. That is why it never implemented iterator. LineIterator could easily support Iterable -- Key: IO-272 URL: https://issues.apache.org/jira/browse/IO-272 Project: Commons IO Issue Type: Improvement Reporter: Sebb Priority: Minor It could be useful to make LineIterator support IterableString, which is very easy to add. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-692) Add hashCodeMulti varargs method
Add hashCodeMulti varargs method Key: LANG-692 URL: https://issues.apache.org/jira/browse/LANG-692 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Stephen Colebourne Assignee: Stephen Colebourne Priority: Minor Fix For: 3.0 A hashCodeMulti(Object...) varargs method is useful as an alternative to HashCodeBuilder. This doesn't replace hashCode(Object) for performance and calculation reasons. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-692) Add hashCodeMulti varargs method
[ https://issues.apache.org/jira/browse/LANG-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne resolved LANG-692. - Resolution: Fixed Add hashCodeMulti varargs method Key: LANG-692 URL: https://issues.apache.org/jira/browse/LANG-692 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Stephen Colebourne Assignee: Stephen Colebourne Priority: Minor Fix For: 3.0 A hashCodeMulti(Object...) varargs method is useful as an alternative to HashCodeBuilder. This doesn't replace hashCode(Object) for performance and calculation reasons. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-688) Proposed code simplifications for BooleanUtils
[ https://issues.apache.org/jira/browse/LANG-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016727#comment-13016727 ] Stephen Colebourne commented on LANG-688: - isTrue(Boolean) handles null Proposed code simplifications for BooleanUtils -- Key: LANG-688 URL: https://issues.apache.org/jira/browse/LANG-688 Project: Commons Lang Issue Type: Improvement Components: lang.* Affects Versions: 3.0 Reporter: Matt Benson Assignee: Matt Benson Priority: Minor Fix For: 3.0 Attachments: LANG-688.patch.txt Patch forthcoming for team consideration. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LANG-492) Remove code handled now by the JDK
[ https://issues.apache.org/jira/browse/LANG-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13002566#comment-13002566 ] Stephen Colebourne commented on LANG-492: - Revert deletion of ArrayUtils.hashCode() as it did something different to the JDK method Remove code handled now by the JDK -- Key: LANG-492 URL: https://issues.apache.org/jira/browse/LANG-492 Project: Commons Lang Issue Type: Task Components: General Reporter: Henri Yandell Fix For: 3.0 enum, enums packages removed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COLLECTIONS-251) Replace getInstance() and decorate() methods with get{ClassName}()
[
https://issues.apache.org/jira/browse/COLLECTIONS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997719#comment-12997719
]
Stephen Colebourne commented on COLLECTIONS-251:
For the record, JSR-310 now uses 'of' prefix on classes:
LocalDate.of(2011, 6, 12);
OffsetDateTime.ofInstant(instant);
and short names on utility classes:
DateAdjusters.lastDayOfMonth();
There is a plan to then add a separate static imports utility class, which
remaps names like of to date. That class may not be in the core of JSR-310.
The short names like truePredicate() look reasonable here.
Replace getInstance() and decorate() methods with get{ClassName}()
--
Key: COLLECTIONS-251
URL: https://issues.apache.org/jira/browse/COLLECTIONS-251
Project: Commons Collections
Issue Type: Improvement
Components: Bag, BidiMap, Buffer, Collection, Comparator, Core,
Functor, Iterator, KeyValue, List, Map, Set
Affects Versions: 3.2
Reporter: Stephen Kestle
Fix For: 4.0-beta-1
Commons Collections uses the singleton getInstance() pattern and extends it
to allow parameters etc to be passed in. decorate() serves a similar purpose.
I propose replacing both of these with getClassName() for the following
reasons:
1. Static imports would mean that TruePredicate.getInstance() would be
replaced with getTruePredicate(). getInstance() cannot be statically
imported, because it is reduced to one class' getInstance(), where we are
likely using many.
2. It gives subclasses a way to avoid compiler issues - COLLECTIONS-243
compile problems are generally because the compiler can't choose between
CollectionT and SetT. Doing this change completely avoids this issue -
even if there is a workaround, this makes life a lot easier (different
compilers - eclipse - will allow things that the Sun one won't).
2.1 Overridden and overloaded static methods are a really bad idea
2.2 No confusion about what class is being instantiated
2.3 As our methods become more useful in the generic sense, the compiler
issues increase until you hit something that just won't work
3. Simple migration path - those using TruePredicate.getInstance() can switch
to PredicateUtils.truePredicate() before updating to this version.
4. Allows a more consistent user environment. Following the current pattern
means that most people will have MyTransformer.getInstance(), while using
TransformerUtils.nopTransformer().
Our work will be made a lot easier if we make this change.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LANG-624) SystemUtils.getJavaVersionAsFloat throws StringIndexOutOfBoundsException on Android runtime/Dalvik VM
[
https://issues.apache.org/jira/browse/LANG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985264#action_12985264
]
Stephen Colebourne commented on LANG-624:
-
We shouldn't remove the float/int methods. They are the useful ones!
SystemUtils.getJavaVersionAsFloat throws StringIndexOutOfBoundsException on
Android runtime/Dalvik VM
-
Key: LANG-624
URL: https://issues.apache.org/jira/browse/LANG-624
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 2.5
Reporter: Travis Truman
Fix For: 3.0
Attachments: AndriodJavaVersion.png
Can be replicated in the Android emulator quite easily.
Stack trace:
{noformat}
at
org.apache.commons.lang.builder.ToStringBuilder.clinit(ToStringBuilder.java:98)
E/AndroidRuntime( 1681): ... 17 more
E/AndroidRuntime( 1681): Caused by: java.lang.ExceptionInInitializerError
E/AndroidRuntime( 1681): at
org.apache.commons.lang.builder.ToStringStyle$MultiLineToStringStyle.init(ToStringStyle.java:2276)
E/AndroidRuntime( 1681): at
org.apache.commons.lang.builder.ToStringStyle.clinit(ToStringStyle.java:94)
E/AndroidRuntime( 1681): ... 18 more
E/AndroidRuntime( 1681): Caused by: java.lang.StringIndexOutOfBoundsException
E/AndroidRuntime( 1681): at java.lang.String.substring(String.java:1571)
E/AndroidRuntime( 1681): at
org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1153)
E/AndroidRuntime( 1681): at
org.apache.commons.lang.SystemUtils.clinit(SystemUtils.java:818)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-667) Add a Null-safe compare() method to ObjectUtils
[ https://issues.apache.org/jira/browse/LANG-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978733#action_12978733 ] Stephen Colebourne commented on LANG-667: - I support this change, its a useful feature that is clearly documented and no threat to the Comparable contract. Add a Null-safe compare() method to ObjectUtils --- Key: LANG-667 URL: https://issues.apache.org/jira/browse/LANG-667 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 2.5 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 3.0 Add a Null-safe compare() method to ObjectUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-323) Behavior of constructors CaseInsensitiveMap inconsistent with standard Java HashMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978736#action_12978736 ] Stephen Colebourne commented on COLLECTIONS-323: The behaviour should match the JDK classes, whatever that is. Behavior of constructors CaseInsensitiveMap inconsistent with standard Java HashMap --- Key: COLLECTIONS-323 URL: https://issues.apache.org/jira/browse/COLLECTIONS-323 Project: Commons Collections Issue Type: Bug Components: Map Affects Versions: 3.2 Environment: Any Reporter: Maarten Brak Priority: Minor Fix For: 4.x Original Estimate: 24h Remaining Estimate: 24h The constructor CaseInsensitiveMap(int initialCapacity) throws an IllegalArgumentException if the initial capacity is less than one. This is inconsistent with the standard Java HashMap constructor HashMap(int initialCapacity), which throws an if IllegalArgumentException if the initial capacity is negative. Thus: new HashMap(0) == no exception new CaseInsensitiveMap(0) == IllegalArgumentException. This inconsistency is confusing. Actions: - Change Javadoc (this shouldn't be a problem in practice since surely there is no code around depending on the fact that the constructor throws an IllegalArgumentException :-)) - Change code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-663) org.apache.commons.lang3.math.Fraction does not always succeed in multiplyBy and divideBy
[
https://issues.apache.org/jira/browse/LANG-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12976866#action_12976866
]
Stephen Colebourne commented on LANG-663:
-
Commons Math is a specialist library, Lang is a general purpose one. Fraction
is definitely a general purpose concept, and so shoudl remain in Lang. Of
course any bugs should be fixed, but remembering the general-purpose, rather
than mathematical, focus.
org.apache.commons.lang3.math.Fraction does not always succeed in multiplyBy
and divideBy
-
Key: LANG-663
URL: https://issues.apache.org/jira/browse/LANG-663
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.0
Reporter: Christian Semrau
Priority: Minor
Fix For: 3.0
The Fraction.multiplyBy and divideBy methods fail sometimes when the
arguments are not reduced.
{code:title=FunctionTest.java|borderStyle=solid}
public void testMultiply() {
// ...
f1 = Fraction.getFraction(Integer.MAX_VALUE, Integer.MAX_VALUE);
f2 = Fraction.getFraction(42, 1);
f = f1.multiplyBy(f2);
assertEquals(42, f.getNumerator());
assertEquals(1, f.getDenominator());
public void testDivide() {
// ...
f1 = Fraction.getFraction(Integer.MAX_VALUE, Integer.MAX_VALUE);
f2 = Fraction.getFraction(42, 1);
f = f1.divideBy(f2);
assertEquals(1, f.getNumerator());
assertEquals(42, f.getDenominator());
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-363) TransformedMap is Serializable but its superclass doesn't define an accessible void constructor
[
https://issues.apache.org/jira/browse/COLLECTIONS-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12973162#action_12973162
]
Stephen Colebourne commented on COLLECTIONS-363:
All the serializable collections are supposed to have a serialization test,
with a .obj file checked into the repo (see the data folder). If you could
upload a second patch with the obj file and test that uses it, that would be
useful.
TransformedMap is Serializable but its superclass doesn't define an
accessible void constructor
---
Key: COLLECTIONS-363
URL: https://issues.apache.org/jira/browse/COLLECTIONS-363
Project: Commons Collections
Issue Type: Bug
Components: Map
Affects Versions: 3.2
Reporter: Sebb
Attachments: COLLECTIONS-363.patch
TransformedMap is Serializable but its superclass doesn't define an
accessible void constructor.
For example, the following test fails:
{code}
public void testSerialisation() throws Exception {
TransformedMapString, String, String, String map =
TransformedMap.decorate(
new HashMapString, String(), NOPTransformer.String
getInstance(), NOPTransformer.String getInstance());
ByteArrayOutputStream bytes = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(bytes);
out.writeObject(map); // fails with java.io.InvalidClassException:
org.apache.commons.collections.splitmap.TransformedMap; no valid constructor
out.close();
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-588) Create a basic PairL, R class
[ https://issues.apache.org/jira/browse/LANG-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12836146#action_12836146 ] Stephen Colebourne commented on LANG-588: - I should note that EnumSet and JSR-310 use Classname.of - its becoming a new standard. The benefit of static imports seems to wane by comparison. So, +1 to Pair.of() As explained above this class shouldn't cache the hash code, as mutable objects might be stashed within. I should say that I find the L/R notation perfectly acceptable for this class - it doesn't overly imply anything to me. Create a basic PairL, R class --- Key: LANG-588 URL: https://issues.apache.org/jira/browse/LANG-588 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Matt Benson Fix For: 3.0 Attachments: Pair.java, PairTest.java [lang] is the perfect place to provide a basic typed Pair class. I have written such a class for my employer (who hasn't?) but can/will rewrite blind to avoid IP issues. I think it's also nice to go ahead and extend this to MatchedPairT extends PairT, T as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-316) Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder
[ https://issues.apache.org/jira/browse/LANG-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791274#action_12791274 ] Stephen Colebourne commented on LANG-316: - I don't like this idea for the reasons Hen has found. The equalsIgnoreCase implementation is complex and hash code would be messed up. Its also a feature I've never needed. Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder - Key: LANG-316 URL: https://issues.apache.org/jira/browse/LANG-316 Project: Commons Lang Issue Type: New Feature Components: lang.builder.* Affects Versions: 2.3 Environment: Any Reporter: Nelson Carpentier Priority: Minor Fix For: 3.0 Attachments: lang_20070206.diff, lang_20070529.diff Sometimes I want a String property containing ThisString to be seen as equal to THISstring. EqualsBuilder (and HashCodeBuilder) should be enhanced to optionally handle this requirement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-565) Does StrSubstitutor really need setter methods for the fields that are settable via constructors?
[ https://issues.apache.org/jira/browse/LANG-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790481#action_12790481 ] Stephen Colebourne commented on LANG-565: - We tend to have get/set to support bean-based tooling, as part of [lang]s mission to not be a framework. I'm not sure being thread-safe helps StrSubstitutor as it is intended to be used from a singe thread. Does StrSubstitutor really need setter methods for the fields that are settable via constructors? - Key: LANG-565 URL: https://issues.apache.org/jira/browse/LANG-565 Project: Commons Lang Issue Type: Improvement Reporter: Sebb Does StrSubstitutor really need setter methods for the fields that are settable via constructors? If these setters could be dropped, the instance variables could be made final. I think this would then make the class thread-safe, provided that the Map used by StrLookup is thread-safe. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-537) Add ArrayUtils.toArray to create generic arrays
[
https://issues.apache.org/jira/browse/LANG-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778775#action_12778775
]
Stephen Colebourne commented on LANG-537:
-
I get it now, and looks good.
However, the tests needs strengthening.
{code}
Object obj = ArrayUtils.toArray(foo, bar);
// does this compile?
// what is the actual type of obj? String[] ?
{code}
There should be tests with other types, and combinations of types
{code}
Object obj = ArrayUtils.toArray(new Integer(6), new Short(6));
// does this compile?
// what is the actual type of obj? Number[] ?
{code}
Add ArrayUtils.toArray to create generic arrays
---
Key: LANG-537
URL: https://issues.apache.org/jira/browse/LANG-537
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Joerg Schaible
Assignee: Joerg Schaible
Fix For: 3.0
{code:java}
/**
* Create a type-safe generic array.
*
* pArrays are covariant i.e. they cannot be created from a generic
type:/p
*
* pre
public static lt;Tgt; T[] toArray(int size)
{
return T[size]; // compiler error here
}
public static lt;Tgt; T[] toArray(int size)
{
return (T[])Object[size]; // ClassCastException at runtime
}
* /pre
*
* pTherefore new arrays of generic types can be created with this method,
e.g. an arrays of Strings:/p
*
* pre
String[] array = ArrayUtils.toArray(1, 2);
String[] emptyArray = ArrayUtils.lt;Stringgt;toArray();
* /pre
*
* @param T the array's element type
* @param items the items of the array
* @return the array
* @author Jouml;rg Schaible
* @since 3.0
*/
public static T T[] toArray(final T... items)
{
return items;
}
{code}
Tests:
{code:java}
/**
* Tests generic array creation with specified type.
*/
public void testArrayCreation()
{
final String[] array = ArrayUtils.toArray(foo, bar);
assertEquals(2, array.length);
assertEquals(foo, array[0]);
assertEquals(bar, array[1]);
}
/**
* Tests generic array creation with generic type.
*/
public void testIndirectArrayCreation()
{
final String[] array = toArray(foo, bar);
assertEquals(2, array.length);
assertEquals(foo, array[0]);
assertEquals(bar, array[1]);
}
/**
* Tests generic empty array creation with generic type.
*/
public void testEmptyArrayCreation()
{
final String[] array = ArrayUtils.StringtoArray();
assertEquals(0, array.length);
}
/**
* Tests indirect generic empty array creation with generic type.
*/
public void testIndirectEmptyArrayCreation()
{
final String[] array = toArray();
assertEquals(0, array.length);
}
private static T T[] toArray(final T... items)
{
return ArrayUtils.toArray(items);
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-290) EnumUtils for JDK 5.0
[
https://issues.apache.org/jira/browse/LANG-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Colebourne closed LANG-290.
---
Resolution: Fixed
Renamed isEnum to isValidEnum.
Don't believe that sizeOf is sufficiently commonly needed, and is easy to
access by getting the list/array and calling size/length.
EnumUtils for JDK 5.0
-
Key: LANG-290
URL: https://issues.apache.org/jira/browse/LANG-290
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Henri Yandell
Fix For: 3.0
Below is an EnumUtils for JDK 1.5. It's also found in the enums.EnumUtils
javadoc:
import java.util.*;
public class EnumUtils {
public static Enum getEnum(Class enumClass, String token) {
return Enum.valueOf(enumClass, token);
}
public static Map getEnumMap(Class enumClass) {
HashMap map = new HashMap();
Iterator itr = EnumUtils.iterator(enumClass);
while(itr.hasNext()) {
Enum enm = (Enum) itr.next();
map.put( enm.name(), enm );
}
return map;
}
public static List getEnumList(Class enumClass) {
return new ArrayList( EnumSet.allOf(enumClass) );
}
public static Iterator iterator(Class enumClass) {
return EnumUtils.getEnumList(enumClass).iterator();
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-307) CloneUtils - utility class to enable cloning via various different mechanisms
[ https://issues.apache.org/jira/browse/LANG-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12772329#action_12772329 ] Stephen Colebourne commented on LANG-307: - Need to decide if we want to do this or not. I'm not overly excited by it. The patch would need rewriting to accept it. CloneUtils - utility class to enable cloning via various different mechanisms - Key: LANG-307 URL: https://issues.apache.org/jira/browse/LANG-307 Project: Commons Lang Issue Type: New Feature Reporter: Henri Yandell Fix For: 3.0 Attachments: lang-307.patch Taken from the tasks.html. No idea if we want to do it or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-546) Add methods to Validate to check whether the index is valid for the array/list/string
[ https://issues.apache.org/jira/browse/LANG-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne closed LANG-546. --- Resolution: Fixed commit -m LANG-546 - Validate.validIndex() /dev/commons/lang/src/java/org/apache/commons/lang/Validate.java /dev/commons/lang/src/test/org/apache/commons/lang/ValidateTest.java Sending /dev/commons/lang/src/java/org/apache/commons/lang/Validate.java Sending /dev/commons/lang/src/test/org/apache/commons/lang/ValidateTest.java Transmitting file data ... Committed revision 831689. Add methods to Validate to check whether the index is valid for the array/list/string - Key: LANG-546 URL: https://issues.apache.org/jira/browse/LANG-546 Project: Commons Lang Issue Type: New Feature Reporter: Stephen Colebourne Priority: Minor Fix For: 3.0 Attachments: ValidateValidIndex.patch Validate should have methods to check whether the index to an array/collection/string is a valid index: public void validIndex(Object[] array, int index) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-493) Remove code that does not hold enough value to remain
[ https://issues.apache.org/jira/browse/LANG-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12772342#action_12772342 ] Stephen Colebourne commented on LANG-493: - commit -m LANG-493 - Remove allElementsOfType as generics handles this pretty well now /dev/commons/lang/src/java/org/apache/commons/lang/Validate.java /dev/commons/lang/src/test/org/apache/commons/lang/ValidateTest.java Sending /dev/commons/lang/src/java/org/apache/commons/lang/Validate.java Sending /dev/commons/lang/src/test/org/apache/commons/lang/ValidateTest.java Transmitting file data ... Committed revision 831709. Remove code that does not hold enough value to remain - Key: LANG-493 URL: https://issues.apache.org/jira/browse/LANG-493 Project: Commons Lang Issue Type: Task Reporter: Henri Yandell Fix For: 3.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-487) ToStringBuilder is thread-hostile
[ https://issues.apache.org/jira/browse/LANG-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770232#action_12770232 ] Stephen Colebourne commented on LANG-487: - Variable made volatile. I propose we close this call. ToStringBuilder is thread-hostile - Key: LANG-487 URL: https://issues.apache.org/jira/browse/LANG-487 Project: Commons Lang Issue Type: Bug Reporter: Sebb Fix For: 3.0 ToStringBuilder is thread-hostile due to the use of the static defaultStyle variable. Adding synchronization won't solve this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-543) Consider making StrBuilder depend on AbstractStringBuilder
[ https://issues.apache.org/jira/browse/LANG-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne closed LANG-543. --- Resolution: Won't Fix Fix Version/s: (was: 3.0) Assignee: Stephen Colebourne AbstractStringBuilder is package scoped and cannot be subclassed. Consider making StrBuilder depend on AbstractStringBuilder -- Key: LANG-543 URL: https://issues.apache.org/jira/browse/LANG-543 Project: Commons Lang Issue Type: Task Reporter: Henri Yandell Assignee: Stephen Colebourne -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (LANG-290) EnumUtils for JDK 5.0
[
https://issues.apache.org/jira/browse/LANG-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Colebourne reopened LANG-290:
-
EnumUtils for JDK 5.0
-
Key: LANG-290
URL: https://issues.apache.org/jira/browse/LANG-290
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Henri Yandell
Fix For: 3.0
Below is an EnumUtils for JDK 1.5. It's also found in the enums.EnumUtils
javadoc:
import java.util.*;
public class EnumUtils {
public static Enum getEnum(Class enumClass, String token) {
return Enum.valueOf(enumClass, token);
}
public static Map getEnumMap(Class enumClass) {
HashMap map = new HashMap();
Iterator itr = EnumUtils.iterator(enumClass);
while(itr.hasNext()) {
Enum enm = (Enum) itr.next();
map.put( enm.name(), enm );
}
return map;
}
public static List getEnumList(Class enumClass) {
return new ArrayList( EnumSet.allOf(enumClass) );
}
public static Iterator iterator(Class enumClass) {
return EnumUtils.getEnumList(enumClass).iterator();
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-290) EnumUtils for JDK 5.0
[
https://issues.apache.org/jira/browse/LANG-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770322#action_12770322
]
Stephen Colebourne commented on LANG-290:
-
Added getEnumList(), isEnum(), getEnum(), and fixed bug with generics of
getEnumMap().
commit -m LANG-290 - Add more enum utility methods
/dev/commons/lang/src/java/org/apache/commons/lang/EnumUtils.java
/dev/commons/lang/src/test/org/apache/commons/lang/EnumUtilsTest.java
Sending
/dev/commons/lang/src/java/org/apache/commons/lang/EnumUtils.java
Sending
/dev/commons/lang/src/test/org/apache/commons/lang/EnumUtilsTest.java
Transmitting file data ...
Committed revision 830038.
EnumUtils for JDK 5.0
-
Key: LANG-290
URL: https://issues.apache.org/jira/browse/LANG-290
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Henri Yandell
Fix For: 3.0
Below is an EnumUtils for JDK 1.5. It's also found in the enums.EnumUtils
javadoc:
import java.util.*;
public class EnumUtils {
public static Enum getEnum(Class enumClass, String token) {
return Enum.valueOf(enumClass, token);
}
public static Map getEnumMap(Class enumClass) {
HashMap map = new HashMap();
Iterator itr = EnumUtils.iterator(enumClass);
while(itr.hasNext()) {
Enum enm = (Enum) itr.next();
map.put( enm.name(), enm );
}
return map;
}
public static List getEnumList(Class enumClass) {
return new ArrayList( EnumSet.allOf(enumClass) );
}
public static Iterator iterator(Class enumClass) {
return EnumUtils.getEnumList(enumClass).iterator();
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-548) Use Iterable on API instead of Collection
Use Iterable on API instead of Collection - Key: LANG-548 URL: https://issues.apache.org/jira/browse/LANG-548 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Fix For: 3.0 Use Iterable on API instead of Collection. This permits a greater range of input objects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-548) Use Iterable on API instead of Collection
[ https://issues.apache.org/jira/browse/LANG-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770345#action_12770345 ] Stephen Colebourne commented on LANG-548: - StringUtils.join commit -m LANG-548 - Use Iterable instead of Collection /dev/commons/lang/src/java/org/apache/commons/lang/StringUtils.java /dev/commons/lang/src/test/org/apache/commons/lang/StringUtilsTest.java Sending /dev/commons/lang/src/java/org/apache/commons/lang/StringUtils.java Sending /dev/commons/lang/src/test/org/apache/commons/lang/StringUtilsTest.java Transmitting file data ... Committed revision 830042. Use Iterable on API instead of Collection - Key: LANG-548 URL: https://issues.apache.org/jira/browse/LANG-548 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Fix For: 3.0 Use Iterable on API instead of Collection. This permits a greater range of input objects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-467) EqualsBuilder and HashCodeBuilder treat java.math.BigDecimal inconsistantly and break general contract of hashCode
[
https://issues.apache.org/jira/browse/LANG-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Colebourne updated LANG-467:
Priority: Major (was: Minor)
We can't have EqualsBuilder and HashCodeBuilder out of line.
My preferred fix would be to revert the invalid change to EqualsBuilder.
EqualsBuilder and HashCodeBuilder treat java.math.BigDecimal inconsistantly
and break general contract of hashCode
--
Key: LANG-467
URL: https://issues.apache.org/jira/browse/LANG-467
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.4
Reporter: David Jones
Fix For: 3.0
A POJO with a BigDecimal field and equals() and hashCode() methods
implemented using EqualsBuilder and HashCodeBuilder breaks the general
contract of Object.hashCode();
EqualsBuilder treats BigDecimal specially by comparing it using
BigDecimal.compareTo() == 0 rather than BigDecimal.equals()
Using BigDecimal.compareTo() ignores the scale of the BigDecimal()
However the append(Object o) method of HashCodeBuilder uses
BigDecimal.hashCode() in the case that o is a BigDecimal, which takes the
scale into account when generating the hashCode.
The following test case shows the problem!
{code:title=TestApacheCommonsLangHashCodeBuilder.java|borderStyle=solid}
// package declaration and imports not shown
public class TestApacheCommonsLangHashCodeBuilder extends TestCase {
public void testHashCode() {
MyPojo myPojo1 = new MyPojo(new String(foo), new
BigDecimal(10.2));
MyPojo myPojo2 = new MyPojo(new String(foo), new
BigDecimal(10.20));
// equals method ignores the scale of the big decimal
// so this test passes
assertTrue(myPojo1.equals(myPojo2));
// however in the case the equals returns true the
// hashCode must be the same according to the contract
// TEST FAILS AT THIS LINE
assertEquals(myPojo1.hashCode(), myPojo2.hashCode());
}
private class MyPojo {
private String name;
private BigDecimal value;
public MyPojo(String name, BigDecimal value) {
this.name = name;
this.value = value;
}
public String getName() {
return name;
}
public BigDecimal getValue() {
return value;
}
/**
* equals method implemented using EqualsBuilder
* as documented by apache commons
*/
@Override public boolean equals(Object obj) {
if(this == obj) {
return true;
}
if(!(obj instanceof MyPojo)) {
return false;
}
MyPojo other = (MyPojo) obj;
return new EqualsBuilder()
.append(name, other.getName())
.append(value, other.getValue())
.isEquals();
}
/**
* hashCode method implemented using HashCodeBuilder
* as documented by apache commons
*/
@Override public int hashCode() {
HashCodeBuilder hcb = new HashCodeBuilder(17, 31);
return hcb
.append(name)
.append(value)
.toHashCode();
}
}
}
{code}
Note that the only reason I haven't provided a patch is because I could not
think of one which I thought was reasonable.
*Option 1*
Always set the scale to some value and then get the hashCode()
Example change in HashCodeBuilder.append(Object) add the following:
{code}
else if (object instanceof BigDecimal) {
append(((BigDecimal) object).setScale(DEFAULT_BIGDECIMAL_SCALE,
RoundingMode.DOWN).hashCode());
}
{code}
However what is a reasonable scale for calculating this hashCode? I cannot
see a reasonanble scale to choose, that depends on the circumstance
*Option 2*
stripTrailingZeros() before calculating the hashCode()
Example change in HashCodeBuilder.append(Object) add the following:
{code}
else if (object instanceof BigDecimal) {
append(((BigDecimal) object).stripTrailingZeros().hashCode());
}
{code}
The performance of this method under different circumstances is not
documented.
*Option 3*
Document the problem and propose that the client solves the problem.
For example change HashCodeBuilder documentation as follows
{code}
/*
* ...
* public class Person {
* String name;
* int age;
* boolean smoker;
* BigDecimal netWorth;
* ...
*
* public int hashCode() {
* // you pick a hard-coded, randomly chosen, non-zero, odd number
* // ideally different for each class
[jira] Created: (LANG-545) Add ability to create a Future for a constant
Add ability to create a Future for a constant - Key: LANG-545 URL: https://issues.apache.org/jira/browse/LANG-545 Project: Commons Lang Issue Type: New Feature Reporter: Stephen Colebourne Assignee: Stephen Colebourne Priority: Minor Fix For: 3.0 The concurrent Future interface is a nice way to gain access to an object at some future point in time. However, sometimes you need an implementation that isn't used for concurrency, but is used to avoid a null check or for testing. Add a ConstantFuture class that implements the Future interface and returns the constant value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-545) Add ability to create a Future for a constant
[ https://issues.apache.org/jira/browse/LANG-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated LANG-545: Attachment: ConstantFuture.patch Add ability to create a Future for a constant - Key: LANG-545 URL: https://issues.apache.org/jira/browse/LANG-545 Project: Commons Lang Issue Type: New Feature Reporter: Stephen Colebourne Assignee: Stephen Colebourne Priority: Minor Fix For: 3.0 Attachments: ConstantFuture.patch The concurrent Future interface is a nice way to gain access to an object at some future point in time. However, sometimes you need an implementation that isn't used for concurrency, but is used to avoid a null check or for testing. Add a ConstantFuture class that implements the Future interface and returns the constant value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-546) Add methods to Validate to check whether the index is valid for the array/list/string
Add methods to Validate to check whether the index is valid for the array/list/string - Key: LANG-546 URL: https://issues.apache.org/jira/browse/LANG-546 Project: Commons Lang Issue Type: New Feature Reporter: Stephen Colebourne Priority: Minor Fix For: 3.0 Validate should have methods to check whether the index to an array/collection/string is a valid index: public void validIndex(Object[] array, int index) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-546) Add methods to Validate to check whether the index is valid for the array/list/string
[ https://issues.apache.org/jira/browse/LANG-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated LANG-546: Attachment: ValidateValidIndex.patch Add methods to Validate to check whether the index is valid for the array/list/string - Key: LANG-546 URL: https://issues.apache.org/jira/browse/LANG-546 Project: Commons Lang Issue Type: New Feature Reporter: Stephen Colebourne Priority: Minor Fix For: 3.0 Attachments: ValidateValidIndex.patch Validate should have methods to check whether the index to an array/collection/string is a valid index: public void validIndex(Object[] array, int index) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-547) The field FastDateFormat.UnpaddedNumberField.INSTANCE_YEAR is never read locally
[ https://issues.apache.org/jira/browse/LANG-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne closed LANG-547. --- Resolution: Fixed Assignee: Stephen Colebourne commit -m LANG-547 - Remove unused field /commons/lang/src/java/org/apache/commons/lang/time/FastDateFormat.java Sending /commons/lang/src/java/org/apache/commons/lang/time/FastDateFormat.java Transmitting file data ... Committed revision 829385. The field FastDateFormat.UnpaddedNumberField.INSTANCE_YEAR is never read locally Key: LANG-547 URL: https://issues.apache.org/jira/browse/LANG-547 Project: Commons Lang Issue Type: Improvement Reporter: Sebb Assignee: Stephen Colebourne Fix For: 3.0 The field FastDateFormat.UnpaddedNumberField.INSTANCE_YEAR is never read locally and could be deleted -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-285) Wish : method unaccent
[ https://issues.apache.org/jira/browse/LANG-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12733065#action_12733065 ] Stephen Colebourne commented on LANG-285: - I'd avoid a hard 1.6 dependency right now, as we're only just moving up from a 1.4 dependency. If the 1.6 dependency is optional (via reflection?) then that would be fine. Wish : method unaccent -- Key: LANG-285 URL: https://issues.apache.org/jira/browse/LANG-285 Project: Commons Lang Issue Type: New Feature Reporter: Guillaume Coté Priority: Minor Fix For: 3.0 Attachments: LANG-285-unaccent-using-Collator.patch, MapBuilder.java, unaccent.patch, UnnacentMap.java I would like to add a method that replace accented caracter by unaccented one. For example, with the input String L'été où j'ai dû aller à l'île d'Anticosti commenca tôt, the method would return L'ete ou j'ai du aller à l'ile d'Anticosti commenca tot. I suggest to call that method unaccent and to add it in StringUtils. If we cannot covert all case, the first version could only covert iso-8859-1. If you are willing to go forward with that idea, I am willing to contribute a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-311) isEqualSet method in SetUtils could rehash the two input sets before it does the containsAll comparison
[
https://issues.apache.org/jira/browse/COLLECTIONS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663197#action_12663197
]
Stephen Colebourne commented on COLLECTIONS-311:
Javadoc from the JDK
Note: Great care must be exercised if mutable objects are used as set
elements. The behavior of a set is not specified if the value of an object is
changed in a manner that affects equals comparisons while the object is an
element in the set. A special case of this prohibition is that it is not
permissible for a set to contain itself as an element.
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Set.html
While I understand that this caused you many difficulties, it is fundamentally
an invalid use of a Set (or Map key) to mutate the object after adding it.
isEqualSet method in SetUtils could rehash the two input sets before it does
the containsAll comparison
---
Key: COLLECTIONS-311
URL: https://issues.apache.org/jira/browse/COLLECTIONS-311
Project: Commons Collections
Issue Type: Improvement
Components: Set
Affects Versions: 3.2
Reporter: Michael Qiu
Hey Guys
I had an interesting problem recently where I was comparing 2 sets and the
equals method was returning false... maybe it might be easier to understand
if I explain using pseudo code:
{code}
set1.equals(set2) = false
set1.get(0).equals(set2.get(0)) = true
set1.get(1).equals(set2.get(1)) = true
set1.get(0).hashCode() == set2.get(0).hashCode() = true
set1.get(1).hashCode() == set2.get(1).hashCode() = true
{code}
So, objects in the two sets are equals, the hashCode of the objects in the
two sets are equals, however the equals comparison at the set level was not
equals.
After some time, we figured out that the problem was that the object inside
the set was getting modified after it was put into the set. So the new
hashCode of the object has changed. However the bucket of the set that it's
in hasn't changed. When another piece of code calls the contains method, it
looks for the equivalent object in a bucket according to the new hashCode.
When it doesn't find it, and it returns false.
I would like to suggest that the SetUtils.isEqualSet method rehashes contents
of the sets given in the parameters before it does the containsAll comparison
to avoid the problem caused by this scenario.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-393) EqualsBuilder don't compare BigDecimals correctly
[ https://issues.apache.org/jira/browse/LANG-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636187#action_12636187 ] Stephen Colebourne commented on LANG-393: - I hadn't spotted this one. While I understand the motivation, I do think that EqualsBuilder should use .equals(). There are people who will consider that to be the only valid equals comparison (all the state of the object being equal). EqualsBuilder don't compare BigDecimals correctly -- Key: LANG-393 URL: https://issues.apache.org/jira/browse/LANG-393 Project: Commons Lang Issue Type: Bug Affects Versions: 2.3 Reporter: Luis Henriques Priority: Minor Fix For: 2.4 Attachments: LANG-393.patch When comparing a BigDecimal, the comparing is made using equals, not compareTo, which is more appropriate in the case of BigDecimal. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-458) Add methods to return boolean from Validate.java instead of throwing IllegalArgumentException
[
https://issues.apache.org/jira/browse/LANG-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632944#action_12632944
]
Stephen Colebourne commented on LANG-458:
-
I would say that this class has a single purpose at present, and that is to act
as an guard on entry to a method, with an exception being the result. We should
not add isXxx methods returning a boolean to Validate.
Furthermore, I'm not sure there is any need for a class in [lang] that has
those boolean return types. The majority of the functions of Validate that
would be converted are available elsewhere, such as StringUtils.isEmpty, or
CollectionUtils.isEmpty.
Add methods to return boolean from Validate.java instead of throwing
IllegalArgumentException
-
Key: LANG-458
URL: https://issues.apache.org/jira/browse/LANG-458
Project: Commons Lang
Issue Type: Improvement
Environment: software
Reporter: Viraj Turakhia
Priority: Minor
Attachments: code_diff.txt, test_diff.txt
I am using Validate.java since long and find it difficult to use when I just
want to validate collections or string.
With current interface, I go like this:
while(cnt list.size()) {
List list1 = list.get(cnt);
try {
Validate.notEmpty(list1);
} catch(IllegalArgumentException e) {
continue;
}
}
much better approach is:
while(cnt list.size()) {
List list1 = list.get(cnt);
try {
if(! Validate.notEmpty(list1)) {
continue;
}
}
If you all agree with this change, I am willing to submit a patch for this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-246) LoopingListIterator behaves unexpected on next and previous mixed
[
https://issues.apache.org/jira/browse/COLLECTIONS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589041#action_12589041
]
Stephen Colebourne commented on COLLECTIONS-246:
Could everyone please read the javadoc for ListIterator.
http://java.sun.com/javase/6/docs/api/java/util/ListIterator.html#previous()
next() followed by previous() return the same value.
LoopingListIterator behaves unexpected on next and previous mixed
-
Key: COLLECTIONS-246
URL: https://issues.apache.org/jira/browse/COLLECTIONS-246
Project: Commons Collections
Issue Type: Bug
Components: Iterator
Affects Versions: 3.2
Environment: JDK 1.4.2_12
Common Collections 3.2
Reporter: Frank Hefter
Priority: Blocker
Fix For: 3.3
Attachments: LoopingListIterator.java, LoopingListIterator.java,
LoopingListIteratorTest.java
Using ArrayList as the backing list.
This combination at least returns unexpected results as you can see in the
testcase below.
I used this for a list navigator in a web frontend and had trouble with users.
I suspect java.util.AbstrList$ListItr (role of cursor var seems to be wrong
implemented ) to cause this problem. If so maybe we have to implement it in a
different way.
Testcase (it runs without hassle but the comments show whats wrong):
---
import java.util.ArrayList;
import junit.framework.TestCase;
import org.apache.commons.collections.iterators.LoopingListIterator;
public class SelectionControllerTest extends TestCase {
public void testSelectorForApache() {
ArrayList al = new ArrayList();
al.add(0); al.add(1); al.add(2);
LoopingListIterator it = new LoopingListIterator(al);
assertEquals(0, it.next()); // This is OK
// here I am on 0
assertEquals(0, it.previous()); // Wrong ! This should be 2!
// here I am on 0 too! This is wrong.
assertEquals(2, it.previous());
assertEquals(1, it.previous());
assertEquals(0, it.previous());
assertEquals(2, it.previous());
// here I am on 2
assertEquals(2, it.next()); // Wrong ! This should be 0!
// here I am on 2 too! This is wrong.
assertEquals(0, it.next());
assertEquals(1, it.next());
// here I am on 1
assertEquals(1, it.previous()); // Wrong ! This should be 0!
}
}
---
Thanks for your help.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-265) TreeBag allows uncomparable item to be added, breaking toString
[ https://issues.apache.org/jira/browse/COLLECTIONS-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579182#action_12579182 ] Stephen Colebourne commented on COLLECTIONS-265: Yes, an exception on add() makes most sense. However, if there is a Comparator then the instanceof check should not happen. TreeBag allows uncomparable item to be added, breaking toString --- Key: COLLECTIONS-265 URL: https://issues.apache.org/jira/browse/COLLECTIONS-265 Project: Commons Collections Issue Type: Bug Components: Bag Affects Versions: 3.2 Reporter: David Saff Priority: Minor Fix For: 3.3 Attachments: TreeBag.pat The following code throws an exception not when the Object is added, but when toString is called: TreeBag bag = new TreeBag(); bag.add(new Object()); bag.toString(); Trace: java.lang.ClassCastException: java.lang.Object at java.util.TreeMap.compare(TreeMap.java:1093) at java.util.TreeMap.getEntry(TreeMap.java:347) at java.util.TreeMap.get(TreeMap.java:265) at org.apache.commons.collections.bag.AbstractMapBag.getCount(AbstractMapBag.java:116) at org.apache.commons.collections.bag.AbstractMapBag.toString(AbstractMapBag.java:581) [...] In a client program, toString should never throw an exception--it makes debugging much harder, for one thing. I believe that TreeBag should defend against the addition of uncomparable objects, so that toString will never throw an exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557174#action_12557174 ] Stephen Colebourne commented on IO-153: --- I've checked this, and I'm happy. Thanks. FileWriter that accepts an encoding --- Key: IO-153 URL: https://issues.apache.org/jira/browse/IO-153 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Stephen Colebourne Priority: Minor Fix For: 1.4 Attachments: FileWriterWithEncoding.java, io-FileWriterWithEncoding.patch Amazingly, even in JDK6 there are no constructors on FileWriter that accept an encoding. Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) [io] add a convenience FileUtils.move(File src, File dest)
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556645#action_12556645
]
Stephen Colebourne commented on IO-77:
--
The answer to this is not to start a holy war, but to evaluate what the rest of
[io] does now, and apply the consistency rule. IIRC that means NPE, but my
memory could be faulty.
(please bear in mind that commons-io is written, like lang and collections, to
simulate the behaviour of the JDK itself in many respects)
[io] add a convenience FileUtils.move(File src, File dest)
--
Key: IO-77
URL: https://issues.apache.org/jira/browse/IO-77
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 1.0
Environment: Operating System: other
Platform: Other
Reporter: nicolas de loof
Priority: Minor
Fix For: 1.4
Attachments: IO-77.patch, patch_io.txt
I'm using FileUtils as it partially solves the missing move method for File,
that is so simple to do in unix shell.
A full implementation in FileUtils may be great :
static boolean FileUtils.move(File src, File dest)
throws IOException
{
boolean rename = src.renameTo(dest);
if (!rename)
{
copyFile(file, dest);
file.delete();
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated IO-153: -- Attachment: io-FileWriterWithEncoding.patch Class and test case FileWriter that accepts an encoding --- Key: IO-153 URL: https://issues.apache.org/jira/browse/IO-153 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Stephen Colebourne Priority: Minor Fix For: 1.4 Attachments: io-FileWriterWithEncoding.patch Amazingly, even in JDK6 there are no constructors on FileWriter that accept an encoding. Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IO-153) FileWriter that accepts an encoding
FileWriter that accepts an encoding --- Key: IO-153 URL: https://issues.apache.org/jira/browse/IO-153 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Stephen Colebourne Priority: Minor Fix For: 1.4 Attachments: io-FileWriterWithEncoding.patch Amazingly, even in JDK6 there are no constructors on FileWriter that accept an encoding. Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMMONSSITE-21) commons-parent-6 pom changes
[ https://issues.apache.org/jira/browse/COMMONSSITE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556205#action_12556205 ] Stephen Colebourne commented on COMMONSSITE-21: --- FWIW, I strongly prefer the .txt suffix, as it is much, much more friendly to Windows. The ASF policy was clearly written by a someone who only uses Unix. I also believe that the files should be in svn (at the root of the project/component) If the result of this is that maven-remote-resources-plugin is broken, well so be it. commons-parent-6 pom changes Key: COMMONSSITE-21 URL: https://issues.apache.org/jira/browse/COMMONSSITE-21 Project: Commons All Issue Type: Improvement Components: Commons Parent Pom Reporter: Niall Pemberton Attachments: commons-valdiator-generated-NOTICE.txt, COMMONSSITE-21-commons-parent-pom-v1.patch, COMMONSSITE-21-commons-parent-pom-v2.patch Opening this ticket to discuss changes for Version 6 of the commons-parent pom. See thread: http://tinyurl.com/39eo9z for related discussion/issues -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-143) [PATCH] Added Singleton Constants in several stream classes
[ https://issues.apache.org/jira/browse/IO-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555875#action_12555875 ] Stephen Colebourne commented on IO-143: --- +1 on singleton constants. You don't have to use them in [io], but if you want to, you can. Its also consistant with the rest of [io] [PATCH] Added Singleton Constants in several stream classes --- Key: IO-143 URL: https://issues.apache.org/jira/browse/IO-143 Project: Commons IO Issue Type: Improvement Components: Streams/Writers Environment: jvm compliant os Reporter: Nikunj Trivedi Assignee: Niall Pemberton Fix For: 1.4 Attachments: closed_input_stream.patch, closed_output_stream.patch, null_output_stream.patch, null_writer.patch, singleton.patch I have added singleton constants in following four classes which should have been singleton. ClosedInputStream ClosedOutputStream NullOutputStream NullWriter We may also make it a singleton by keeping constructor private, if required. Please comment/commit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-145) File Comparator implementations
[ https://issues.apache.org/jira/browse/IO-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549369 ] Stephen Colebourne commented on IO-145: --- I support the addition of these as a new subpackage of [io]. I also support the provision of 'REVERSE' constants, however I would prefer to see any reverse implementation as package scoped. The JDK supplies the implementation itself as from Java 5 (on Collections). This code is also Java 5 specific. If it is to go in the 1.x branch of [io] then the generics need removing. Personally, I think it might be worth just applying the classes to the new java 5 project/branch. File Comparator implementations --- Key: IO-145 URL: https://issues.apache.org/jira/browse/IO-145 Project: Commons IO Issue Type: New Feature Affects Versions: 1.3.2 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: AFTER-1.4 Attachments: DefaultFileComparator.java, ExtensionFileComparator.java, LastModifiedFileComparator.java, LengthFileComparator.java, NameFileComparator.java, PathFileComparator.java, ReverseFileComparator.java Add file comparator implementations - prompted by IO-142 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-143) [PATCH] Added Singleton Constants in several stream classes
[ https://issues.apache.org/jira/browse/IO-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549000 ] Stephen Colebourne commented on IO-143: --- IIRC, [io] now uses singletons with meaningful names, so that they can be statically imported. [PATCH] Added Singleton Constants in several stream classes --- Key: IO-143 URL: https://issues.apache.org/jira/browse/IO-143 Project: Commons IO Issue Type: Improvement Components: Streams/Writers Affects Versions: 1.4, AFTER-1.4 Environment: jvm compliant os Reporter: Nikunj Trivedi Fix For: 1.4, AFTER-1.4 Attachments: closed_input_stream.patch, closed_output_stream.patch, null_output_stream.patch, null_writer.patch I have added singleton constants in following four classes which should have been singleton. ClosedInputStream ClosedOutputStream NullOutputStream NullWriter We may also make it a singleton by keeping constructor private, if required. Please comment/commit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-276) *Utils methods should not be extensible or able to be instantiated.
[
https://issues.apache.org/jira/browse/COLLECTIONS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541662
]
Stephen Colebourne commented on COLLECTIONS-276:
I disagree. Not everyone turns on the compiler warning you mention, and the
technique of using the subclass to access the static methods of the superclass
is perfectly reasonable.
One of the things that I find about open source is not closing down options
unless you have to. You never know what a user will choose to do with our
classes. In this case, subclassing causes us no harm, so we should allow it.
*Utils methods should not be extensible or able to be instantiated.
---
Key: COLLECTIONS-276
URL: https://issues.apache.org/jira/browse/COLLECTIONS-276
Project: Commons Collections
Issue Type: Improvement
Affects Versions: Generics
Reporter: Stephen Kestle
Priority: Minor
Fix For: Generics
I don't see any good reason why this CollectionUtils (and others) isn't final
with a private constructor. There are no non-static methods, and any
extension of them is going to have to call through to the super to avoid
compiler warnings.
e.g. MyCollectionUtils.select() will provoke the warning that static methods
should be called directly (on CollectionUtils).
Which would mean
MyCollectionUtils{
public static Collection select(){
return CollectionUtils.select();
}
Which really defeats the purpose. In Java5, we have static imports now -
these provide more benefit than previous extension did anyhow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-275) IndexedCollection would be a useful addition to Commons Collections
[ https://issues.apache.org/jira/browse/COLLECTIONS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541034 ] Stephen Colebourne commented on COLLECTIONS-275: This could not be implemented. The Collection and Map interfaces cannot be implemented by the same class due to to clashing return types on remove(Object) IndexedCollection would be a useful addition to Commons Collections --- Key: COLLECTIONS-275 URL: https://issues.apache.org/jira/browse/COLLECTIONS-275 Project: Commons Collections Issue Type: New Feature Components: Collection Reporter: Stephen Kestle Fix For: Generics I propose that an IndexedCollection is added, which has the following properties * IndexedCollectionK,C implements CollectionC, MapK,C * Contains a TransformerC,K for determining the keys * Presents as an unmodifiableMap (all manipulation must be done through the collection) * It will need constructors for unique indexes (Map) and non-unique (MapK,CollectionV / MultiMap). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-52) [lang] Validate.notNull should throw NullArgumentException
[ https://issues.apache.org/jira/browse/LANG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540156 ] Stephen Colebourne commented on LANG-52: I won't block the change, but I personally disagree with it for compatibility reasons. [lang] Validate.notNull should throw NullArgumentException -- Key: LANG-52 URL: https://issues.apache.org/jira/browse/LANG-52 Project: Commons Lang Issue Type: Bug Environment: Operating System: All Platform: All Reporter: Jörg Gottschling Priority: Trivial Fix For: 2.4 Attachments: LANG-52.patch Validate.notNull throws a IllegalArgumentException but should throw a NullArgumentException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-52) [lang] Validate.notNull should throw NullArgumentException
[
https://issues.apache.org/jira/browse/LANG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539917
]
Stephen Colebourne commented on LANG-52:
Just so we are clear. This change could break compatibility:
try {
. Validate.notNull(obj);
. someMethodThatMightThrowNullArgumentException()
} catch (NullArgumentException ex) {
. System.out.println(A);
} catch (IllegalArgumentException ex) {
. System.out.println(B);
}
Making this change will cause the code to print A instead of B.
[lang] Validate.notNull should throw NullArgumentException
--
Key: LANG-52
URL: https://issues.apache.org/jira/browse/LANG-52
Project: Commons Lang
Issue Type: Bug
Environment: Operating System: All
Platform: All
Reporter: Jörg Gottschling
Priority: Trivial
Fix For: 2.4
Attachments: LANG-52.patch
Validate.notNull throws a IllegalArgumentException but should throw a
NullArgumentException
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-331) Fix for LANG-259 broke ValuedEnum.compareTo() on subclassed enumerations
[ https://issues.apache.org/jira/browse/LANG-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537888 ] Stephen Colebourne commented on LANG-331: - The whole cross ClassLoader thing for enums was a Bad Idea :-( Fix for LANG-259 broke ValuedEnum.compareTo() on subclassed enumerations Key: LANG-331 URL: https://issues.apache.org/jira/browse/LANG-331 Project: Commons Lang Issue Type: Bug Reporter: Michael Sclafani Fix For: 2.4 Attachments: LANG-331-test.patch, LANG-331.patch I have a ValuedEnum abstract subclass that I further subclass to attach useful implementation behaviors. The base class overrides getEnumClass(). The fix for LANG-259 broke compareTo() since it compares getClass(), not getEnumClass(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-128) NPE on FilenameUtils.equalsNormalizedOnSystem()
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534606 ] Stephen Colebourne commented on IO-128: --- For equals() the general contract is that if they are not equal then it returns false. object.equals(null) returns false for example. I don't think using the un-normalized name is the right way to go. The second question is whether normalize is trying to extract a UNC name, and if it decides it isn't then what to do. I suspect that its best to try and remove the UNC prefix, and if not then treat as per any other filename (ie. remove the double slash.) NPE on FilenameUtils.equalsNormalizedOnSystem() --- Key: IO-128 URL: https://issues.apache.org/jira/browse/IO-128 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2 Reporter: Antonio Gallardo Assignee: Niall Pemberton Fix For: 1.4 The following code in commons-io (1.3.2) throws an NPE exception: org.apache.commons.io.FilenameUtils .equalsNormalizedOnSystem( //a.html, //ab.html); And here is the exception: java.lang.NullPointerException: The strings must not be null at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141) at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984) at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956) at CodeSnippet_32.run(CodeSnippet_32.java:4) at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54) at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35) I think it is wrong a message The strings must not be null, since there is not a null string involved in the call. Interesting is if both or 1 of the strings is null, it did not throws an exception. Additional comment from Niall Pemberton (on the dev mail list): The problem is that the FilenameUtils's normalize(String) method returns null if it thinks the file names are invalid - which in your case it seems to be doing so for both file names. So I guess theres two issues here - you're right the error is misleading and FilenameUtils should check the names again after calling normalize() for nulls and throw a more appropriate message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-127) Move to a minimum of JDK 1.4
[ https://issues.apache.org/jira/browse/IO-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534341 ] Stephen Colebourne commented on IO-127: --- Jorg Schaible suggested[2] that the compiler options be kept at JDK 1.3 so that, apart from new JDK 1.4 dependant features, Commons IO would still operate under JDK 1.3. If this can be achieved, I withdraw any previous opposition to this idea, as I think this is a very pragmatic approach. Move to a minimum of JDK 1.4 Key: IO-127 URL: https://issues.apache.org/jira/browse/IO-127 Project: Commons IO Issue Type: Task Reporter: Niall Pemberton Priority: Minor Fix For: 1.4 There was a discussion a while back on moving Commons IO to a minimum JDK version of 1.4 - see [1] below. The majority view was this was a good idea. Jorg Schaible suggested[2] that the compiler options be kept at JDK 1.3 so that, apart from new JDK 1.4 dependant features, Commons IO would still operate under JDK 1.3. This seems like a good idea and resolves the issue of whether this would require a major version change. There was also a view that we should move to JDK 1.5 instead - I have no issue with that, but would advocate that theres no point in doing so until there are people wanting to commit JDK 1.5 dependant features. This change is targeted at Commons IO 1.4 - and a Commons IO 1.3 branch has been created for anyone still desiring future JDK 1.3 only releases. [1] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-127) Move to a minimum of JDK 1.4
[ https://issues.apache.org/jira/browse/IO-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534368 ] Stephen Colebourne commented on IO-127: --- It would be ideal if part of the ant script could test 1.3 compatibility, but this all looks good anyway. Move to a minimum of JDK 1.4 Key: IO-127 URL: https://issues.apache.org/jira/browse/IO-127 Project: Commons IO Issue Type: Task Reporter: Niall Pemberton Priority: Minor Fix For: 1.4 There was a discussion a while back on moving Commons IO to a minimum JDK version of 1.4 - see [1] below. The majority view was this was a good idea. Jorg Schaible suggested[2] that the compiler options be kept at JDK 1.3 so that, apart from new JDK 1.4 dependant features, Commons IO would still operate under JDK 1.3. This seems like a good idea and resolves the issue of whether this would require a major version change. There was also a view that we should move to JDK 1.5 instead - I have no issue with that, but would advocate that theres no point in doing so until there are people wanting to commit JDK 1.5 dependant features. This change is targeted at Commons IO 1.4 - and a Commons IO 1.3 branch has been created for anyone still desiring future JDK 1.3 only releases. [1] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-266) Issue with MultiKey when serialized/deserialized via RMI
[ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527984 ] Stephen Colebourne commented on COLLECTIONS-266: Serialization is actually quite clever. You can change a field to transient, and keep the same serialVersionUID without a problem IIRC. And in this case, it doesn't matter if the serialVersionUID is changed, as the current code is broken. Issue with MultiKey when serialized/deserialized via RMI Key: COLLECTIONS-266 URL: https://issues.apache.org/jira/browse/COLLECTIONS-266 Project: Commons Collections Issue Type: Bug Components: KeyValue Affects Versions: 3.2 Reporter: Julien Buret Priority: Minor Fix For: 3.3 Attachments: COLLECTIONS-266.patch, MultiKey.java, TestCollections266.java, TestCollections266.java, TestCollections266.java This is because the hash code of MultiKey is calculated only once. So if the MultiKey is deserialized in an other jvm, and if one at least of the subkeys defines its hash code with System.identityHashCode() (for example all the enums does), then the hash code of the MultiKey is no longer valid, and you can't retreive the key in your Map. I fixed it by making the cached hash code field transient, and by recalculating the hash code during deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-355) StrBuilder should implement CharSequence and Appendable
StrBuilder should implement CharSequence and Appendable --- Key: LANG-355 URL: https://issues.apache.org/jira/browse/LANG-355 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Priority: Minor Fix For: LangTwo 1.0 StrBuilder should implement CharSequence and Appendable, which were introduced in JDK1.4 and JDK1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
