[jira] [Created] (NET-583) FTPClient.getReplyString() returns wrong value after connect()
Holger Rehn created NET-583: --- Summary: FTPClient.getReplyString() returns wrong value after connect() Key: NET-583 URL: https://issues.apache.org/jira/browse/NET-583 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.3 Reporter: Holger Rehn If the FTPClient's automatic server encoding detection is enabled, a FEAT command is issued in method _connectAction_() [indirectly via hasFeature(String)]. After that, the _replyCode and _replyLines fields are stored back to their previous values in _connectAction_(), but the _newReplyString flag isn't set to true. Because of that, you will then get back the reply to the FEAT command from getReplyString(), instead of the server's welcome message. Furthermore, you may get back a reply code that doesn't match that reply string. We have encountered a case when we got back reply code 220 after FTPClient.connect(), but reply string was "530 Not logged in.". This error can easily be fixed by adding the following line to FTPClient.java around line 944: _newReplyString = true; Patch: === --- src/org/apache/commons/net/ftp/FTPClient.java +++ src/org/apache/commons/net/ftp/FTPClient.java (working copy) @@ -941,6 +941,7 @@ _replyLines.clear(); _replyLines.addAll(oldReplyLines); _replyCode = oldReplyCode; + _newReplyString = true; } } -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DAEMON-340) Stop Service Shows Error 1053
Noorulla created DAEMON-340: --- Summary: Stop Service Shows Error 1053 Key: DAEMON-340 URL: https://issues.apache.org/jira/browse/DAEMON-340 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.15 Environment: OS Verson : WINDOWS 2008 R2 Service Pack : Service Pack1 Reporter: Noorulla Hello Thanks in Advance Created java window service using Java common demons it works fine (Start /Stop) in My system which having the OS Windows 7 / Service Pack 1 but when I deploy in server having OS as Windows 2008 /service Pack 1 it shows below error message when stop the service from Windows Service Windows could not stop the service on Local Computer Error 1053: The Service did not respond to start or control request in a timely fashion could you please help me to resolve the issues Thanks Noorulla -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCS-155) baclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream
Romain Manni-Bucau created JCS-155: -- Summary: baclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream Key: JCS-155 URL: https://issues.apache.org/jira/browse/JCS-155 Project: Commons JCS Issue Type: Bug Affects Versions: jcs-2.0-beta-1 Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.0-beta-2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCS-155) blacklist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream
[ https://issues.apache.org/jira/browse/JCS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-155: --- Summary: blacklist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream (was: blaclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream) > blacklist > org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan > in our custom ObjectInputStream > > > Key: JCS-155 > URL: https://issues.apache.org/jira/browse/JCS-155 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-2.0-beta-1 >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.0-beta-2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCS-155) blaclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream
[ https://issues.apache.org/jira/browse/JCS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-155: --- Summary: blaclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream (was: baclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream) > blaclist > org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan > in our custom ObjectInputStream > --- > > Key: JCS-155 > URL: https://issues.apache.org/jira/browse/JCS-155 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-2.0-beta-1 >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.0-beta-2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCS-155) baclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream
[ https://issues.apache.org/jira/browse/JCS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-155. Resolution: Fixed > baclist > org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan > in our custom ObjectInputStream > -- > > Key: JCS-155 > URL: https://issues.apache.org/jira/browse/JCS-155 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-2.0-beta-1 >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.0-beta-2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[ https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michele Vivoda updated JXPATH-183: -- Attachment: JXPath183Test.java I attach a test case that shows the issue > XMLGregorianCalendar existence adding a lot of performance penalty > -- > > Key: JXPATH-183 > URL: https://issues.apache.org/jira/browse/JXPATH-183 > Project: Commons JXPath > Issue Type: Improvement >Affects Versions: 1.3 > Environment: Windows 7, Amazon Unix, Weblogic >Reporter: Ganna Shmatova > Labels: performance > Attachments: JXPath183Test.java > > > We're using JXPath to parse some input from a client. When they give us a > valid date it gets transformed from a SOAP message into Java objects. When > this happens JXPath queries suddenly take 1-8 seconds more (depending on > system -- the optimized system it's 1 second, dev & test machines it's 8). > Kicker is, we don't even look for this field. Just its existence does it. > (we've quickfixed to omit the xml tags before the string is parsed into Java > for now) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029885#comment-15029885
]
Michele Vivoda edited comment on JXPATH-183 at 11/27/15 1:58 PM:
-
I attach a test case that more or less shows the issue
What shows the test is that {{//*}} traverses also the properties of Calendar
*(124 values) and XMLGregorianCalendar (18 values), I thought that registering
them as Atomic would have changed this, since they are not present in the list
of atomic classes of {{JXPathIntrospector}} but this is not the case. A Long is
not traversed, but this probably happens only because it has no properties
starting with {{getXXX}}
was (Author: vivodamich...@hotmail.com):
I attach a test case that shows the issue
> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
> Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
> Labels: performance
> Attachments: JXPath183Test.java
>
>
> We're using JXPath to parse some input from a client. When they give us a
> valid date it gets transformed from a SOAP message into Java objects. When
> this happens JXPath queries suddenly take 1-8 seconds more (depending on
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java
> for now)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IMAGING-176) TiffImageParser.getImageInfo() throws exception when "Compression" field is missing
Gabriel Axel created IMAGING-176: Summary: TiffImageParser.getImageInfo() throws exception when "Compression" field is missing Key: IMAGING-176 URL: https://issues.apache.org/jira/browse/IMAGING-176 Project: Commons Imaging Issue Type: Bug Components: Format: TIFF Affects Versions: 0.97, 1.0 Reporter: Gabriel Axel A solution that worked for my case was to default to no compression. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-176) TiffImageParser.getImageInfo() throws exception when "Compression" field is missing
[ https://issues.apache.org/jira/browse/IMAGING-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Axel updated IMAGING-176: - Description: A solution that worked for my case was to default to no compression. https://github.com/apache/commons-imaging/pull/19 was:A solution that worked for my case was to default to no compression. > TiffImageParser.getImageInfo() throws exception when "Compression" field is > missing > --- > > Key: IMAGING-176 > URL: https://issues.apache.org/jira/browse/IMAGING-176 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 0.97, 1.0 >Reporter: Gabriel Axel > > A solution that worked for my case was to default to no compression. > https://github.com/apache/commons-imaging/pull/19 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-299) ExtendedProperties.convertProperties loses non-String values
[
https://issues.apache.org/jira/browse/COLLECTIONS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-299.
---
> ExtendedProperties.convertProperties loses non-String values
>
>
> Key: COLLECTIONS-299
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-299
> Project: Commons Collections
> Issue Type: Bug
> Components: Core
>Reporter: Simon Kitching
>
> A Properties object normally has Strings as its values. But it does partially
> support non-String-typed values via the raw put and get methods inherited
> from Hashtable. And other Properties methods are aware that the value might
> not be a String; see documentation for methods propertyNames() and
> stringPropertyNames() for example.
> ExtendedProperties.convertProperties does this:
> {code}
> for (Enumeration e = props.propertyNames(); e.hasMoreElements();) {
> String s = (String) e.nextElement();
> c.setProperty(s, props.getProperty(s));
> }
> {code}
> Properties.propertyNames() returns the names of all keys in the set,
> regardless of the associated value's type. But Properties.getProperty(key)
> returns null if the value type is not a String. The call to c.setProperty
> invokes setPropertyInternal, which can pass this null value to Hashtable.put,
> which then throws a NullPointerException.
> It's rather puzzling to have a valid (string-key, non-string-value) entry in
> the Properties object and get a NullPointerException.
> Perhaps the call
> props.getProperty(s)
> can be changed to
> props.get(s)
> Alternately, at least documenting that this method does not support
> non-string values in the input Properties object would be useful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-531) Generic Wildcards specified in CollectionUtils#isEqualCollection(Collection, Collection, Equator) may throw ClassCastException in certain cases
[
https://issues.apache.org/jira/browse/COLLECTIONS-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-531.
---
> Generic Wildcards specified in CollectionUtils#isEqualCollection(Collection,
> Collection, Equator) may throw ClassCastException in certain cases
> ---
>
> Key: COLLECTIONS-531
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-531
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.0
>Reporter: Dipanjan Laha
>Priority: Minor
> Fix For: 4.1
>
> Attachments: IsEqualCollectionTest.java
>
>
> CollectionUtils#isEqualCollection(Collection, Collection, Equator) is defined
> as
> {code}
> public static boolean isEqualCollection(final Collection a, final
> Collection b, final Equator equator) {
> ...
> }
> {code}
> This makes it possible to invoke it with a code like
> {code}
> public static class IntegerEquator implements Equator {
> public boolean equate(Integer o1, Integer o2) {
> return o1.intValue() == o2.intValue();
> }
> public int hash(Integer o) {
> return o.intValue();
> }
> }
> @Test
> public void test() {
> List longList = Arrays.asList(1L, 2L);
> List intList = Arrays.asList(1, 2);
> assertTrue(CollectionUtils.isEqualCollection(longList, intList, new
> IntegerEquator()));
> }
> {code}
> which compiles perfectly but throws a ClassCastException as Long cannot be
> cast to an Integer. However, the generics should be defined such that this is
> stopped at compile time itself.
> If we modify the method to something like
> {code}
> public static boolean isEqualCollection(final Collection a,
> final Collection b, final Equator equator) {
> ...
> }
> {code}
> the above example would give a compile time error. imho we should modify this
> method with bounded wildcards. I don't think this change would break any
> existing binaries if the method is being used correctly, otherwise it is
> probably throwing ClassCastExceptions anyway.
> Test case attached
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-570) All decorators shall throw a NullPointerException if the decorated argument is null
[ https://issues.apache.org/jira/browse/COLLECTIONS-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-570. --- > All decorators shall throw a NullPointerException if the decorated argument > is null > --- > > Key: COLLECTIONS-570 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-570 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Thomas Neidhart >Priority: Minor > Fix For: 4.1 > > > To be consistent, the constructor shall throw a NullPointerException instead > of a IllegalArgumentException if the argument is null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-524) ListOrderedSet can have duplicates
[ https://issues.apache.org/jira/browse/COLLECTIONS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-524. --- > ListOrderedSet can have duplicates > -- > > Key: COLLECTIONS-524 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-524 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 3.2.1, 4.0 > Environment: tomcat 7, linux >Reporter: J Goodfellow > Fix For: 4.1 > > > The static method, > org.apache.commons.collections.set.ListOrderedSet.decorate(List list), has a > comment "If the list contains duplicates, the duplicates are removed". It > does not remove duplicates and will leave you in an inconsistent state if > your list has duplicates. (i.e. the .size() result is smaller than the > number of iterations from the iterator) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-508) MultiMap's methods are not strongly typed even though the interface supports generics
[ https://issues.apache.org/jira/browse/COLLECTIONS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-508. --- > MultiMap's methods are not strongly typed even though the interface supports > generics > - > > Key: COLLECTIONS-508 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-508 > Project: Commons Collections > Issue Type: Improvement > Components: Map >Affects Versions: 4.0 >Reporter: Dipanjan Laha >Assignee: Dipanjan Laha > Fix For: 4.1 > > Attachments: MultiValuedMap.patch, MultiValuedMap_10.patch, > MultiValuedMap_2.patch, MultiValuedMap_3.patch, MultiValuedMap_4.patch, > MultiValuedMap_5.patch, MultiValuedMap_6.patch, MultiValuedMap_7.patch, > MultiValuedMap_8.patch, MultiValuedMap_9.patch, > TransformedMultiValuedMap.patch > > > Recently I had the need of using a MultiMap in one of my projects. While > using the same, I found that the MultiMap interface has methods that are not > strongly typed even though the interface supports generics. For example if I > have a MultiMap like so > MultiMap multiMap = new MultiValueMap(); > where User is a custom Class, then the get(key) method would return me an > Object which I would need to cast to a Collection like so > Collection userCol = (Collection) multiMap.get(key); > I understand that this limitation comes from that fact that the MultiMap > extends IterableMap which in turn extends Map and other interfaces. Hence the > MultiMap cannot have a get method which returns a Collection instead of > Object as that would mean implementing IterableMap with the Generics set to > be >. In that case the put method's signature would become > public Collection put(K key, Collection value); > which we do not want.The same problem would arise with other methods as well, > ex: containsValue method. > My proposal is why carry on the signatures of a Map and put it on MultiMap. > Where as I do agree that it is a Map after all and has very similar > implementation and functionality, it is very different at other levels. And > even though the MultiMap interface supports generics, the methods are not > strongly typed, which defeats the purpose of having generics. So why can't we > have a separate set of interfaces for MultiMap which do not extend Map. That > way we can have strongly typed methods on the MultiMap. > I have included a a patch for these changes. It is not fully complete and has > some gaps in some TestCases and the documentation but gives a fairly good > idea of what I am talking about. Please let me know your thoughts on taking > this approach. Then i will improve the implementation and submit another > patch. > The other way could be that we let MultiMap extend the interfaces it does > today, but with proper types rather than Object. I mean something like this > public interface MultiMap extends IterableMap> instead > of > public interface MultiMap extends IterableMap > And then have a separate set of methods on the MultiMap interface which > supports the specific MultiMap functionality. For example, the put method > with the above implementation would become > Collection put(K key, Collection value) > and we can have another method as > V putValue(K key, V value) > This way the functionality of Map is preserved along with strongly typed > MultiMap methods. If you feel that this approach is better than the earlier > one, i will implement the same and submit a patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-556) Add an IdentityHashSet
[ https://issues.apache.org/jira/browse/COLLECTIONS-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-556. --- > Add an IdentityHashSet > -- > > Key: COLLECTIONS-556 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-556 > Project: Commons Collections > Issue Type: New Feature >Reporter: Thomas Neidhart > Fix For: 4.1 > > > The default JDK does not provide an IdentityHashSet which can be quite handy > sometimes. > collections already has a MapBackedSet, so we could easily provide one by > wrapping an IdentityHashMap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-565) Add support for NavigableSet interface
[ https://issues.apache.org/jira/browse/COLLECTIONS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-565. --- > Add support for NavigableSet interface > -- > > Key: COLLECTIONS-565 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-565 > Project: Commons Collections > Issue Type: New Feature >Reporter: Thomas Neidhart > Fix For: 4.1 > > > As we moved on to Java 6 we can now add appropriate decorators for > NavigableMap and NavigableSet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-511) CollectionUtils.bisect(...), this would be a combination of Select and SelectRejected
[
https://issues.apache.org/jira/browse/COLLECTIONS-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-511.
---
> CollectionUtils.bisect(...), this would be a combination of Select and
> SelectRejected
> -
>
> Key: COLLECTIONS-511
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-511
> Project: Commons Collections
> Issue Type: New Feature
> Components: Collection
>Reporter: Nathan Blomquist
>Priority: Trivial
> Fix For: 4.1
>
> Attachments: collections-511-proposal.diff
>
>
> I recently needed a way to use a Predicate to select things from a list, but
> I also wanted to know which ones failed the predicate test.
> I wanted the following, but with one iteration instead of two:
> {code}
> List originalList = (...)
> Predicate p = (...)
> Collection selected = CollectionUtils.select(originalList, p);
> Collection rejected = CollectionUtils.selectRejected(originalList, p);
> // handle the selected cases (save them or whatnot)
> // now throw an error message or handle the rejected cases
> {code}
> This is what I came up with based on the CollectionUtils.select(...) method:
> {code:java}
> public static > void bisect(
> final Iterable inputCollection,
> final Predicate predicate,
> final R selectedCollection,
> final R rejectedCollection) {
> if (inputCollection != null && predicate != null) {
> for (final O item : inputCollection) {
> if (predicate.evaluate(item)) {
> selectedCollection.add(item);
> }else{
> rejectedCollection.add(item);
> }
> }
> }
> }
>
> public static void main(String[] args){
> // this will test the bisection code
> List original = Arrays.asList(
> "testString1",
> "testString2",
> "testString3",
> "String1",
> "String2",
> "String3",
> "testString4",
> "String4",
> "testString5"
> );
>
> List selected = new ArrayList();
> List rejected = new ArrayList();
>
> Predicate beginsWithTestPredicate =
> new Predicate() {
> public boolean evaluate(String object) {
> return object.startsWith("test");
> }
> };
>
> bisect(original, beginsWithTestPredicate, selected, rejected);
>
> System.out.println("Size of selected (should be 5):"
> + selected.size());
> System.out.println("Size of rejected (should be 4):"
> + rejected.size());
> }
> {code}
> This will of course throw a NullPointerException if either output collection
> is null. This seems appropriate since we need to return two outputs anyway.
> Not sure if *bisect* is the best name, but this method will split the
> original into two pieces. https://www.google.com/#q=define+bisect
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-557) LRUMap memory usage vs size
[ https://issues.apache.org/jira/browse/COLLECTIONS-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-557. --- > LRUMap memory usage vs size > --- > > Key: COLLECTIONS-557 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-557 > Project: Commons Collections > Issue Type: Improvement > Components: Map >Affects Versions: 3.2.1 >Reporter: Philippe Mouawad > Labels: MEMORY > Fix For: 4.1 > > > Hello, > Currently LRUMap uses maxSize parameter to configure its maxSize. > This is not great for its memory usage. > For example I have a use case where I can't really guess the target maxSize > of LRUMap so I have put a big number . > In reality I end up having 380 elements but LRUMap uses 33 Mb of memory > because it allocates (as capacity) LOAD_FACTORxsupposed max size. > It would be nice to have the possibility to set maxSize apart making it > unrelated to capacity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-536) (Code style) map.size() call in MapUtils.putAll()
[
https://issues.apache.org/jira/browse/COLLECTIONS-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-536.
---
> (Code style) map.size() call in MapUtils.putAll()
> -
>
> Key: COLLECTIONS-536
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-536
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Affects Versions: 3.2.1, 4.0
> Environment: Any
>Reporter: Tagir Valeev
>Priority: Trivial
> Labels: performance
> Fix For: 4.1
>
>
> In class org.apache.commons.collections(4).MapUtils there's a method
> putAll(final Map map, final Object[] array) which starts with
> {noformat}
> map.size(); // force NPE
> {noformat}
> Actually map.size() is not that harmless call for any map. For example,
> consider java.util.concurrent.ConcurrentHashMap size() implementation:
> depending on the circumstances it may take even more time than the rest of
> the putAll method (at least prior to JDK 8). Things are even worse for
> ConcurrentSkipListMap: its size() method iterates over all the map elements.
> Thus I'd suggest to replace this call with more conventional check like:
> {noformat}
> if(map == null) {
> throw new NullPointerException();
> }
> {noformat}
> If you still want to save bytes, you may use {{map.getClass()}}. It's final,
> so it will never be overridden to do something strange and it's even used by
> JavaC for the same purpose (to trigger NPE). For example, if you compile and
> disassemble this code:
> {noformat}
> public class Outer {
> public class Inner {}
> public void test(Outer n) { n.new Inner(); }
> }
> {noformat}
> You will see a getClass() call which is used to trigger NPE.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-540) Duplication of code in CollectionUtils
[
https://issues.apache.org/jira/browse/COLLECTIONS-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-540.
---
> Duplication of code in CollectionUtils
> --
>
> Key: COLLECTIONS-540
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-540
> Project: Commons Collections
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Daniel Stewart
>Priority: Trivial
> Fix For: 4.1
>
>
> In CollectionUtils.get(Object, int) on Line 1250, the code in the condition:
> {code:title=CollectionUtils.java|borderStyle=solid}
> else if (object instanceof Iterator) {
> final Iterator it = (Iterator) object;
> while (it.hasNext()) {
> i--;
> if (i == -1) {
> return it.next();
> }
> it.next();
> }
> throw new IndexOutOfBoundsException("Entry does not exist: " + i);
> }
> {code}
> Can be replaced with just a call to CollectionUtils.get(Iterator, int), on
> Line 1176.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-278) put() and putAll() don't update the getKeys() map
[ https://issues.apache.org/jira/browse/COLLECTIONS-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-278. --- > put() and putAll() don't update the getKeys() map > - > > Key: COLLECTIONS-278 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-278 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Henning Schmiedehausen > Attachments: COLLECTIONS-278.patch, COLLECTIONS-278.patch, > putall-test-patch, putall.patch > > > If you use the put() or putAll() methods of the ExtendedProperties class, it > will not update the contents of the internal keysAsListed map which in turn > will return a different list of keys using the getKeys() method than the > keySet() method does. > The attached patchs fix this behaviour and add test cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-572) Create real set operations for SetUtils
[ https://issues.apache.org/jira/browse/COLLECTIONS-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-572. --- > Create real set operations for SetUtils > --- > > Key: COLLECTIONS-572 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-572 > Project: Commons Collections > Issue Type: Sub-task > Components: Collection, List >Affects Versions: 4.0 >Reporter: Thomas Neidhart > Fix For: 4.1 > > > The SetUtils should have cardinality operations that have the same definition > as the typical mathematical set operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-510) ReverseComparator does not compile under Java 8
[ https://issues.apache.org/jira/browse/COLLECTIONS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-510. --- > ReverseComparator does not compile under Java 8 > --- > > Key: COLLECTIONS-510 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-510 > Project: Commons Collections > Issue Type: Improvement > Components: Comparator >Affects Versions: 4.0 >Reporter: Hollis Waite > Labels: patch > Fix For: 4.1 > > Attachments: COLLECTIONS-510.patch > > > My convoluted build process requires recompilation of Commons project with > Java 8. ReverseComparator contains the project's sole incompatibility. > Although Commons Collections doesn't *need* to compile with JDK 8, it could > be made to do so with one rather harmless change. Could attached patch be > merged into 4.1? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-427) performance problem in SetUniqueList.retainAll()
[
https://issues.apache.org/jira/browse/COLLECTIONS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-427.
---
> performance problem in SetUniqueList.retainAll()
>
>
> Key: COLLECTIONS-427
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-427
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.2.1
> Environment: java 1.6.0_24
> Ubuntu 11.10
>Reporter: Mert Guldur
> Fix For: 4.0-alpha1, 4.0, 4.1
>
> Attachments: Test.java, patch.diff
>
>
> I am encountering a performance problem in SetUniqueList.retainAll().
> It appears in version 3.2.1 and also in revision 1365132. I attached
> a test that exposes this problem and a patch that fixes it. On my
> machine, for this test, the patch provides a 621X speedup.
> To run the test, just do:
> $ java Test
> The output for the un-patched version is:
> Time is 6215
> The output for the patched version is:
> Time is 10
> There are two problems here. First, "SetUniqueList.retainAll()"
> should have similar implementation with the current implementation of
> "ListOrderedSet.retainAll()", which is more optimized. Second, even
> "ListOrderedSet.retainAll()" has a performance problem, which was
> reported and explained in detail in COLLECTIONS-426.
> The attached patch has two parts. The first part (the first loop) is
> inspired from COLLECTIONS-426. The second part (everything after the
> first loop) is in fact the current implementation of
> "ListOrderedSet.retainAll()", with some minor changes to adapt it for
> the current code. Overall, the attached patch is very similar to the
> COLLECTIONS-426 patch.
> I will rehash some of the information from COLLECTIONS-426 (which
> describes "ListOrderedSet.retainAll()") for the current
> "SetUniqueList.retainAll()".
> The current code for "SetUniqueList.retainAll()" is:
> {code:java|borderStyle=solid}
> public boolean retainAll(Collection coll) {
> boolean result = super.retainAll(coll);
> set.retainAll(coll);
> return result;
> }
> {code}
> where both "super.retainAll(coll)" and "set.retainAll(coll)" can have
> quadratic complexity, e.g., if "coll" is a List. Both these calls to
> "retainAll" are in fact calls to
> "java.util.AbstractCollection.retainAll()", which has the code:
> {code:java|borderStyle=solid}
> public boolean retainAll(Collection c) {
> boolean modified = false;
> Iterator e = iterator();
> while (e.hasNext()) {
> if (!c.contains(e.next())) {
> e.remove();
> modified = true;
> }
> }
> return modified;
> }
> {code}
> which iterates over "this" and calls "contains()" on "c". Mapping
> this code back to "SetUniqueList.retainAll()" means that the code
> iterates over "this" and "set" and calls "contains()" on "coll". If
> "coll" has slow "contains()" (e.g., if "coll" is a list), then
> "SetUniqueList.retainAll()" has quadratic complexity.
> The patch iterates over "coll" and calls "contains()" on "set", which
> we know is fast, because "set" is a Set. For a more detailed
> discussion of the patch and the problem, see the current
> implementation of "ListOrderedSet.retainAll()", the discussion for
> COLLECTIONS-426, and the patch for COLLECTIONS-426.
> Is this a bug, or am I misunderstanding the intended behavior? If so,
> can you please confirm if the patch is correct?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-503) IfTransformer
[ https://issues.apache.org/jira/browse/COLLECTIONS-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-503. --- > IfTransformer > - > > Key: COLLECTIONS-503 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-503 > Project: Commons Collections > Issue Type: New Feature > Components: Functor >Reporter: Josh Cain >Priority: Trivial > Fix For: 4.1 > > Attachments: ifTransformer.patch, ifTransformer.patch > > > Just thought a basic ifTransformer that performs operations based on a > predicate would be useful. I know this functionality can be accomplished via > a switchTransformer, but sometimes it would just be easier and more clear to > have an ifTransformer. > I attached a draft of what it could look like. Let me know if this is > something that should be included and I can polish it and write some tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-580.
---
> Arbitrary remote code execution with InvokerTransformer
> ---
>
> Key: COLLECTIONS-580
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-580
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.0, 4.0
>Reporter: Philippe Marschall
> Fix For: 3.2.2, 4.1
>
> Attachments: COLLECTIONS-580.patch
>
>
> With {{InvokerTransformer}} serializable collections can be build that
> execute arbitrary Java code.
> {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes
> {{#entrySet}} and {{#get}} on a deserialized collection. If you have an
> endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you
> can combine the two to create arbitrary remote code execution vulnerability.
> I don't know of a good fix short of removing {{InvokerTransformer}} or making
> it not Serializable. Both probably break existing applications.
> This is not my research, but has been discovered by other people.
> https://github.com/frohoff/ysoserial
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-562) Update minimum required java to 1.6
[ https://issues.apache.org/jira/browse/COLLECTIONS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-562. --- > Update minimum required java to 1.6 > --- > > Key: COLLECTIONS-562 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-562 > Project: Commons Collections > Issue Type: Task >Affects Versions: 4.0 >Reporter: Thomas Neidhart > Fix For: 4.1 > > > The minimum required java version shall be updated to 1.6. > 1.5 is already long EOL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-538) ExtendedProperties causes AccessControlException when framework is called from a script
[
https://issues.apache.org/jira/browse/COLLECTIONS-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-538.
---
> ExtendedProperties causes AccessControlException when framework is called
> from a script
> ---
>
> Key: COLLECTIONS-538
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-538
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 3.2.1
> Environment: Java security manager enabled
>Reporter: Trejkaz
> Fix For: 3.2.2
>
>
> We're using Velocity 1.7, which depends upon Commons Collections 3.x series'
> ExtendedProperties class.
> ExtendedProperties has these constructors where it looks up the file
> separator using the least convenient means possible:
> {code}
> public ExtendedProperties() {
> this.fileSeparator = System.getProperty("file.separator");
> // ...
> }
> {code}
> For us, this is all being called from untrusted code, so this fails with
> AccessControlException.
> I think that instead of using the system property here, it is customary to
> use the File.separator constant.
> If you absolutely _must_ use System.getProperty() to fetch this value, it
> should at least be done from a doPrivileged() block.
> Also I had a quick check of Commons Collections 4 to see if this issue had
> been fixed, but couldn't immediately see what happened to this class. If it
> did turn out to have been fixed in v4, maybe Velocity could be encouraged to
> update to v4, but I haven't seen any updates from them in 4 years, so it's
> probably not a good sign.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-268) maven gets 301 error when attempting to download dependencies
[ https://issues.apache.org/jira/browse/COLLECTIONS-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-268. --- > maven gets 301 error when attempting to download dependencies > - > > Key: COLLECTIONS-268 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-268 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 3.2 > Environment: Run maven, which hasn't been run in a while >Reporter: Brian Egge >Priority: Minor > > I was getting this error: > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > Attempting to download junit-4.3.1.jar. > Error retrieving artifact from > [http://www.ibiblio.org/maven/junit/jars/junit-4.3.1.jar]: > java.io.IOException: Unknown error downloading; status code was: 301 > WARNING: Failed to download junit-4.3.1.jar. > Attempting to download easymock-2.0.jar. > Error retrieving artifact from > [http://www.ibiblio.org/maven/easymock/jars/easymock-2.0.jar]: > java.io.IOException: Unknown error downloading; status code was: 301 > WARNING: Failed to download easymock-2.0.jar. > The build cannot continue because of the following unsatisfied dependencies: > junit-4.3.1.jar > easymock-2.0.jar > Total time: 2 seconds > Finished at: Sun Oct 07 07:04:46 EST 2007 > I found this solution, and it worked for me: > http://blogs.atlassian.com/developer/2006/12/maven_1_repository_changes.html > Here's the one line patch (ASF ok) > Index: project.properties > === > --- project.properties (revision 582533) > +++ project.properties (working copy) > @@ -63,3 +63,4 @@ > maven.junit.fork=true > > clover.excludes=**/Test*.java > +maven.repo.remote=http://mirrors.ibiblio.org/pub/mirrors/maven,http://www.ibiblio.org/maven -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-534) Performance bug in CollectionBag::retainAll
[
https://issues.apache.org/jira/browse/COLLECTIONS-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-534.
---
> Performance bug in CollectionBag::retainAll
> ---
>
> Key: COLLECTIONS-534
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-534
> Project: Commons Collections
> Issue Type: Bug
> Components: Bag, Collection
>Affects Versions: 4.0
> Environment: Ubuntu 12.04
>Reporter: Oswaldo Olivo
> Labels: perfomance
> Fix For: 4.1
>
>
> Hi,
> There seems to be a performance bug in the method retainAll in the
> CollectionBag class.
> The problem is that the code is checking containment over the parameter
> collection, which could be expensive for some types of collections like
> ArrayLists.
> One solution could be to convert the Collection into a HashSet and check
> containment in the HashSet.
> If this is done, then running retainAll on a 1,000,000 collection would take
> less than 2 seconds instead of 27 mins, according to my experiments.
>
> Here's a function to expose the bug:
> public static void collectionBagRetainAllTest() {
> ArrayList coll=new ArrayList();
> for(int i=0;i<=100;++i)
> coll.add(new Integer(i));
> TreeBag treeBag=new TreeBag(coll);
> CollectionBag bag = new CollectionBag(treeBag);
> bag.retainAll(coll);
> }
> _
> Here's a proposed patch:
> public boolean retainAll(final Collection coll) {
> if (coll != null) {
> boolean modified = false;
> final Iterator e = iterator();
> HashSet set=new HashSet(coll);
> while (e.hasNext()) {
> if (!set.contains(e.next())) {
> e.remove();
> modified = true;
> }
> }
> return modified;
> } else {
> // let the decorated bag handle the case of null argument
> return decorated().retainAll(null);
> }
> }
> _
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-512) equals/hashCode mismatch
[ https://issues.apache.org/jira/browse/COLLECTIONS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-512. --- > equals/hashCode mismatch > > > Key: COLLECTIONS-512 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-512 > Project: Commons Collections > Issue Type: Bug > Components: Collection, Comparator >Affects Versions: 4.0 > Environment: Mac OS 10.9, Java 6 and Java 7 >Reporter: Cyrille Artho > Fix For: 4.1 > > Attachments: BugReport1.java, BugReport1_1.java > > > We used Randoop on the collection classes, which found several test cases > where two objects are equal but their hash code differs. > I will attach a file containing two test cases that are different; the other > tests seem to be longer versions showing the same issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-523) Removing unnecessary method
[
https://issues.apache.org/jira/browse/COLLECTIONS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-523.
---
> Removing unnecessary method
> ---
>
> Key: COLLECTIONS-523
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-523
> Project: Commons Collections
> Issue Type: Improvement
> Components: Map
>Affects Versions: 4.0
>Reporter: Thiago Andrade
>Priority: Minor
> Fix For: 4.1
>
>
> I suggest remmove unnecessary method {{private V put(final K key, final V
> value, final long now)}} from the class {{PassiveExpiringMap}} once the
> {{final long now}} parameter was never used. I've addapted the code to work
> properly.
> The param was confusing the logic of this method.
> Placeholder ticket for github PR 2:
> https://github.com/apache/commons-collections/pull/2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-571) Deprecate CollectionUtils.{synchronized, unmodifiable}Collection methods
[
https://issues.apache.org/jira/browse/COLLECTIONS-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-571.
---
> Deprecate CollectionUtils.{synchronized, unmodifiable}Collection methods
>
>
> Key: COLLECTIONS-571
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-571
> Project: Commons Collections
> Issue Type: Task
>Affects Versions: 4.0
>Reporter: Thomas Neidhart
> Fix For: 4.1
>
>
> Deprecate the two methods, the existing utility methods in Collections should
> be used instead.
> This has been missed for the 4.0 release.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-529) Add removeAll(Collection collection, Collection remove, Comparator comparator) and contains(Collection collection, E object, Comparator comparator) met
[
https://issues.apache.org/jira/browse/COLLECTIONS-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-529.
---
> Add removeAll(Collection collection, Collection remove, Comparator
> comparator) and contains(Collection collection, E object, Comparator
> comparator) methods
> --
>
> Key: COLLECTIONS-529
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-529
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Reporter: Alexander Muthmann
> Fix For: 4.1
>
> Attachments: COLLECTIONS-529.patch, COLLECTIONS-529_1.patch
>
>
> Hi,
> this request originates from one of our project where we have implemented
> something similar.
> The Java-Interface java.util.Collection specifies the two methods
> contains(Object o) and boolean removeAll(Collection c). Both methods rely
> on the equals() method of the given Objects.
> In some cases, it's not possible to change those methods and therefore
> removeAll and contains cannot be used directly.
> E.g. if you have an class myClass with property A and B and the equals method
> uses both properties, but you are only interested in property B.
> To solve this problem, I'd like to propose the following extensions of
> CollectionsUtils:
> {code}
> /**
> * Removes all elements of remove from the collection using the comparator
> instead of .equals()
> */
> public static Collection removeAll(final Collection collection,
> final Collection remove, Comparator comparator);
> /**
> * Checks if the given collection contains the object using the comparator
> instead of .equals()
> */
> public static boolean contains(final Collection collection, final E
> object, Comparator comparator);
> {code}
> Both methods do basically the same as their native equivalient but use a
> comparator instead of equals().
> This allows the injection of any required compare value:
> {code}
> final Collection result = CollectionUtils.removeAll(base, sub, new
> Comparator() {
> public int compare(myClass o1, myClass o2) {
> return o1.getB() == o2.getB();
> }
> });
> {code}
> If you think those methods are a good idea (as proposed or changed according
> to any rules), please give me a short feedback and I'll offer an
> implementation as diff patch for review.
> Cheers,
> Alex
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-426) performance problem in ListOrderedSet.retainAll()
[
https://issues.apache.org/jira/browse/COLLECTIONS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-426.
---
> performance problem in ListOrderedSet.retainAll()
> -
>
> Key: COLLECTIONS-426
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-426
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.2.1
> Environment: java 1.6.0_24
> Ubuntu 11.10
>Reporter: Adrian Nistor
> Fix For: 4.0-alpha1, 4.0, 4.1
>
> Attachments: Test.java, patch.diff
>
>
> Hi,
> I am encountering a performance problem in ListOrderedSet.retainAll().
> It appears in version 3.2.1 and also in revision 1365132. I attached
> a test that exposes this problem and a patch that fixes it. On my
> machine, for this test, the patch provides a 263X speedup.
> To run the test, just do:
> $ java Test
> The output for the un-patched version is:
> Time is 3682
> The output for the patched version is:
> Time is 14
> The problem is that the code for method
> "ListOrderedSet.retainAll(Collection coll)" is:
> {code:java|borderStyle=solid}
> public boolean retainAll(Collection coll) {
> boolean result = collection.retainAll(coll);
>
> }
> {code}
> because "collection.retainAll(coll)" has quadratic complexity if
> parameter "coll" is a List. Conceptually, the solution is to call
> "coll.retainAll(collection)" which has linear complexity (not
> quadratic), because "collection" is always a HashSet (we know this,
> because "collection" is an inherited field of ListOrderedSet, and thus
> cannot have another type). See the
> "java.util.AbstractCollection.retainAll()" code inlined below for why
> one call has quadratic complexity, and the other has linear
> complexity.
> Directly calling "coll.retainAll(collection)" would change the
> behavior of ListOrderedSet.retainAll(), which is why the patch seems a
> bit involved. In reality, the patch simulates the behavior of
> "coll.retainAll(collection)" (which is just the intersection of two
> collections). You can easily see this by looking at the patch and at
> the "java.util.AbstractCollection.retainAll()" code inlined below.
> "collection.retainAll(coll)" is "java.util.HashSet.retainAll()", which
> is "java.util.AbstractCollection.retainAll()", which has the code:
> {code:java|borderStyle=solid}
> public boolean retainAll(Collection c) {
> boolean modified = false;
> Iterator e = iterator();
> while (e.hasNext()) {
> if (!c.contains(e.next())) {
> e.remove();
> modified = true;
> }
> }
> return modified;
> }
> {code}
> Is this a bug, or am I misunderstanding the intended behavior? If so,
> can you please confirm if the patch is correct?
> Thanks,
> Adrian
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-271) org.apache.commons.collections.ExtendedProperties#combine don't import string properly
[
https://issues.apache.org/jira/browse/COLLECTIONS-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-271.
---
> org.apache.commons.collections.ExtendedProperties#combine don't import string
> properly
> --
>
> Key: COLLECTIONS-271
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-271
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 3.2
>Reporter: Alexander Borovsky
> Attachments: COLLECTIONS-271.patch, COLLECTIONS-271.patch, fix.patch
>
>
> When we set property with escaped characters, after combine propertySets we
> got them unescaped.
> Simple Example
> ExtendedProperties props = new ExtendedProperties();
> props.setProperty("test", "192.168.1.91test");
> props.getProperty("test"); // => \\192.168.1.91\test
> ExtendedProperties props2 = new ExtendedProperties();
> props2.combine(props);
> props.getProperty("test"); // => \192.168.1.91\test -- Wrong!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-576) MultiKey subclassing has deserialization problem since COLLECTIONS-266: either declare protected readResolve() or MultiKey must be final
[
https://issues.apache.org/jira/browse/COLLECTIONS-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-576.
---
> MultiKey subclassing has deserialization problem since COLLECTIONS-266:
> either declare protected readResolve() or MultiKey must be final
>
>
> Key: COLLECTIONS-576
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-576
> Project: Commons Collections
> Issue Type: Bug
> Components: KeyValue
>Affects Versions: 4.0
>Reporter: Stephan Roch
> Fix For: 4.1
>
>
> MultiKey from collections 4 provides a transient hashCode and a *private*
> readResolve to resolve COLLECTIONS-266: Issue with MultiKey when
> serialized/deserialized via RMI.
> Unfortunately the solution does not work in case of *subclassing*:
> readResolve in MultiKey should be declared *protected* readResolve() to be
> called during deserialization of the subclass. Otherwise MultiKey must be
> final to avoid such subclassing.
> *Testcase*:
> {code:java|title=MultiKeySerializationTest.java}
> package de.ivu.test.common.collections4;
> import static org.junit.Assert.assertEquals;
> import java.io.ByteArrayInputStream;
> import java.io.ByteArrayOutputStream;
> import java.io.IOException;
> import java.io.ObjectInputStream;
> import java.io.ObjectOutputStream;
> import org.apache.commons.collections4.keyvalue.MultiKey;
> import org.junit.Test;
> public class MultiKeySerializationTest {
> @Test
> @SuppressWarnings("unchecked")
> public void testReadResolveEqualHashCode()
> throws IOException, ClassNotFoundException {
> class MultiKey2
> extends MultiKey {
> private static final long serialVersionUID = 1928896152249821416L;
> public MultiKey2(A key1, B key2) {
> super(key1, key2);
> }
> public A getFirst() {
> return (A) getKey(0);
> }
> public B getSecond() {
> return (B) getKey(1);
> }
>
> // FIXME: MultiKey should either declare protected readResolve()
> or must be final.
> }
> MultiKey2 one = new MultiKey2<>("bla", "blub");
> System.out.println(one.hashCode());
> ByteArrayOutputStream byteOut = new ByteArrayOutputStream();
> ObjectOutputStream out = new ObjectOutputStream(byteOut);
> out.writeObject(one);
> out.close();
> byte[] serialized = byteOut.toByteArray();
> ByteArrayInputStream byteIn = new ByteArrayInputStream(serialized);
> ObjectInputStream in = new ObjectInputStream(byteIn);
> MultiKey2 two = (MultiKey2)
> in.readObject();
> System.out.println(two.hashCode());
> assertEquals("hashCode must be equal - please check for protected
> readResolve in MultiKey*", one.hashCode(),
> two.hashCode());
> }
> }
> {code}
> *Fix:*
> {code:java|title=MultiKey.java}
> @@ -274,7 +274,7 @@
> * only stable for the same process).
> * @return the instance with recalculated hash code
> */
> -private Object readResolve() {
> +protected Object readResolve() {
> calculateHashCode(keys);
> return this;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-509) Clarify javadoc of CollectionBag
[ https://issues.apache.org/jira/browse/COLLECTIONS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-509. --- > Clarify javadoc of CollectionBag > > > Key: COLLECTIONS-509 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-509 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Thomas Neidhart > Fix For: 4.1 > > > The javadoc of CollectionBag should clarify which methods have changed wrt > the original Bag interface. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-220) Serialization/Deserialization doesn't work well with empty buffers.
[
https://issues.apache.org/jira/browse/COLLECTIONS-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-220.
---
> Serialization/Deserialization doesn't work well with empty buffers.
> ---
>
> Key: COLLECTIONS-220
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-220
> Project: Commons Collections
> Issue Type: Bug
> Components: Buffer
>Affects Versions: 3.2
>Reporter: Jose Luis Huertas
>Priority: Minor
> Attachments: ASF.LICENSE.NOT.GRANTED--SerializationTest.java,
> COLLECTIONS-200.patch, COLLECTIONS-220.patch
>
>
> When I serialize the queue to disk an it has elements, all works ok, but when
> I serialize an empty queue I have some problems when I create a new object
> using the serialized file.
> When I deserialize the queue it has a 'buffer' with size 1 (with null
> content), 'tail' and 'head' fields are 0 (they are declared transient). So,
> when I try to add a new object to the queue, the sentence:
> Object[] tmp = new Object[((buffer.length - 1) * 2) + 1];
> Is executed in the add() method to increase the buffer length, but the buffer
> remains with the same size! (buffer.length = 1 --> (1 - 1) * 2 + 1 = 1). So,
> the object is added and when the tail is going to be incremented, it is reset
> to 0!!
> private int increment(int index) {
> index++;
> if (index >= buffer.length) {
> index = 0;
> }
> return index;
> }
> So it is impossible to add new elements after an empty queue has been
> serialized / deserialized.
> I attach a simple TestCase where this is proved. The example works when you
> use XMLEncoder to serialize the buffer but doesn't work if you use
> ObjectOutputStream or XStream.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-544) Undocumented performance issue in the retainAll method in CollectionUtils
[
https://issues.apache.org/jira/browse/COLLECTIONS-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-544.
---
> Undocumented performance issue in the retainAll method in CollectionUtils
> --
>
> Key: COLLECTIONS-544
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-544
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.1
> Environment: Ubuntu 14.04
>Reporter: Oswaldo Olivo
>Priority: Trivial
> Labels: Collections, documentaion, performance
> Fix For: 4.1
>
>
> The method {{retainAll}} in {{CollectionUtils}} is inefficient when the
> parameter collection has a slow containment method.
> The following is the current implementation with its documentation:
> {noformat}
> /**
> * Returns a collection containing all the elements in
> collection
> * that are also in retain. The cardinality of an element
> e
> * in the returned collection is the same as the cardinality of
> e
> * in collection unless retain does not contain
> e, in which
> * case the cardinality is zero. This method is useful if you do not wish
> to modify
> * the collection c and thus cannot call
> c.retainAll(retain);.
> *
> * @param the type of object the {@link Collection} contains
> * @param collection the collection whose contents are the target of the
> #retailAll operation
> * @param retain the collection containing the elements to be retained
> in the returned collection
> * @return a Collection containing all the elements of
> collection
> * that occur at least once in retain.
> * @throws NullPointerException if either parameter is null
> * @since 3.2
> */
> public static Collection retainAll(final Collection collection,
> final Collection retain) {
> return ListUtils.retainAll(collection, retain);
> }
> {noformat}
> We can notice the inefficiency by looking at the {{retainAll}} method in
> {{ListUtils}}.
> The {{retainAll}} method from {{ListUtils}} is implemented and documented as
> follows:
> {noformat}
> /**
> * Returns a List containing all the elements in collection
> * that are also in retain. The cardinality of an element
> e
> * in the returned list is the same as the cardinality of e
> * in collection unless retain does not contain
> e, in which
> * case the cardinality is zero. This method is useful if you do not wish
> to modify
> * the collection c and thus cannot call
> collection.retainAll(retain);.
> *
> * This implementation iterates over collection, checking
> each element in
> * turn to see if it's contained in retain. If it's
> contained, it's added
> * to the returned list. As a consequence, it is advised to use a
> collection type for
> * retain that provides a fast (e.g. O(1)) implementation of
> * {@link Collection#contains(Object)}.
> *
> * @param the element type
> * @param collection the collection whose contents are the target of the
> #retailAll operation
> * @param retain the collection containing the elements to be retained
> in the returned collection
> * @return a List containing all the elements of
> c
> * that occur at least once in retain.
> * @throws NullPointerException if either parameter is null
> * @since 3.2
> */
> public static List retainAll(final Collection collection, final
> Collection retain) {
> final List list = new ArrayList(Math.min(collection.size(),
> retain.size()));
> for (final E obj : collection) {
> if (retain.contains(obj)) {
> list.add(obj);
> }
> }
> return list;
> }
> {noformat}
> In the case of {{ListUtils#retainAll}}, the inefficiency is properly
> documented.
> Perhaps the disclaimer about potential inefficiencies depending on the type
> of the parameter collection in ListUtils:retainAll should also be included in
> {{CollectionUtils#retainAll}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-471) Add a BoundedIterator which returns at most limit elements
[ https://issues.apache.org/jira/browse/COLLECTIONS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-471. --- > Add a BoundedIterator which returns at most limit elements > -- > > Key: COLLECTIONS-471 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-471 > Project: Commons Collections > Issue Type: New Feature >Reporter: Thomas Neidhart > Fix For: 4.1 > > Attachments: BoundedIterator.java, BoundedIteratorTest.java > > > It would be nice to have a decorator which bounds the number of elements > returned by the decorated iterator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-281) Change maven build to create Collections Test Framework jar
[ https://issues.apache.org/jira/browse/COLLECTIONS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-281. --- > Change maven build to create Collections Test Framework jar > --- > > Key: COLLECTIONS-281 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-281 > Project: Commons Collections > Issue Type: Task >Affects Versions: 3.2 >Reporter: Niall Pemberton >Assignee: Henri Yandell >Priority: Minor > Attachments: COLLECTIONS-281-build-testframework.patch > > > Currently the m2 build does not create the Collections Test Framework jar > (ant and m1 builds do) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-234) Please provide nightly builds of collections_jdk5_branch
[ https://issues.apache.org/jira/browse/COLLECTIONS-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-234. --- > Please provide nightly builds of collections_jdk5_branch > > > Key: COLLECTIONS-234 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-234 > Project: Commons Collections > Issue Type: Wish >Affects Versions: 3.2 >Reporter: Stepan Koltsov > > Please provide nightly builds of collections_jdk5_branch. I'd like to use > generified commons-collections right now, and not wait until it will be > released. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-530) Rejecting items on predicate failure without throwing an Exception
[ https://issues.apache.org/jira/browse/COLLECTIONS-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-530. --- > Rejecting items on predicate failure without throwing an Exception > -- > > Key: COLLECTIONS-530 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-530 > Project: Commons Collections > Issue Type: Improvement > Components: List >Affects Versions: 4.0 >Reporter: Erik > Fix For: 4.1 > > Attachments: COLLECTIONS-530-v0.0.1.alpha.zip, COLLECTIONS-530.patch > > > The PredicatedList class doesn't allow entries that fail the predicate, but > throws an Exception on entry. > The problem I have with this, is that it places the onus of filtering out > invalid entries on the caller. > I typically add items in a loop. The item added is the result of a method > call (which returns null if it can't create one). > This problem is so common for me that I have created my own FilteredList > class that simply ignores invalid entries. > I would like the PredicatedList class to be capable of rejecting items > without throwing an exception. > I don't mind writing the code for this, but there are a great many ways in > which this can be done. > So I was wondering what the interface should look like. > Separate FilteredList class. > Works, but seems a little verbose for the purpose > New factory method: filteredList(List list, Predicate > predicate) > Nice and simple, but doesn't allow extension; other ways of dealing with > predicate failure. > New factory method with enum: predicatedList(List list, Predicate T> predicate, PredicateFailEnum action) > More verbose to use and adds an extra class, but allows more alternative ways > to deal with predicate failure. > One more nice thing is that it might be less confusing, > because choosing between predicatedList and the above filteredList might not > be so obvious. > New factory method with interface: filteredList(List list, Predicate super T> predicate, PredicateFailInterface action) > Complex, but the most flexible way of dealing with predicate failure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-555) Undefined NullPointerException in TreeBag.java
[
https://issues.apache.org/jira/browse/COLLECTIONS-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-555.
---
> Undefined NullPointerException in TreeBag.java
> --
>
> Key: COLLECTIONS-555
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-555
> Project: Commons Collections
> Issue Type: Bug
> Components: Bag
>Affects Versions: 4.1
>Reporter: M Kim
>Priority: Minor
> Fix For: 4.1
>
>
> In add(final E object) method of TreeBag.java, the parameter object is not
> null-checked in throw IlligalArgumentException statement. Thus, it crashes
> with an inappropriate type of exceptions when the parameter, object is null.
> object can be null from the argument, transform(object) in
> TransformedCollection.add(final E object).
> I think object ==null should be added in the predicate of the throw
> IlligalArgumentException statement like below.
> {code}
> public boolean add(final E object) {
> if((object==null) || (comparator() == null && !(object instanceof
> Comparable))) {
> throw new IllegalArgumentException("Objects of type " +
> object.getClass() + " cannot be added to " +
>"a naturally ordered TreeBag
> as it does not implement Comparable");
> }
> return super.add(object);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-458) AbstractUntypedCollectionDecorator is not used
[ https://issues.apache.org/jira/browse/COLLECTIONS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-458. --- > AbstractUntypedCollectionDecorator is not used > - > > Key: COLLECTIONS-458 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-458 > Project: Commons Collections > Issue Type: Bug >Reporter: Sebb > > The public ctor for AbstractUntypedCollectionDecorator takes no > argument and so collection = null; however the protected ctor checks for > collection parameter != null. > The decorated() method says that all access to collection goes through it, > and there is no setter. > At present the only way to recover from calling the public ctor is for the > sub-class to set collection directly. > This is inconsistent. > The class is abstract and there appear to be no concrete subclasses. Looks > like the class might be superfluous, but if it is required, it should ideally > have a private final collection field. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-525) PatriciaTrie
[
https://issues.apache.org/jira/browse/COLLECTIONS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-525.
---
> PatriciaTrie
>
>
> Key: COLLECTIONS-525
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-525
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.0
> Environment: android
>Reporter: zigler zhang
>Priority: Critical
> Fix For: 4.1
>
> Attachments: 525.patch
>
>
> the result of trie tree prefixMap function is inconsistent. it would contain
> a key but the size is 0;
> some unittest codes as below:
> PatriciaTrie aTree =
> new PatriciaTrie ();
> aTree.put("点评", "测试");
> aTree.put("书评", "测试");
> assertTrue(aTree.prefixMap("点").containsKey("点评")); //pass
> assertEquals("测试", aTree.prefixMap("点").get("点评")); //pass
> assertFalse(aTree.prefixMap("点").isEmpty()); //fail
> assertEquals(1, aTree.prefixMap("点").size()); //fail
> actural 0
> assertEquals(1, aTree.prefixMap("点").keySet().size()); //fail actural 0
> assertEquals(1, aTree.prefixMap("点").entrySet().size()); //fail actural 0
> assertEquals(1, aTree.prefixMap("点评").values().size()); //fail actural 0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-537) PredicateUtils (all|any)Predicate type misbehaviour Array vs. Collection
[ https://issues.apache.org/jira/browse/COLLECTIONS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-537. --- > PredicateUtils (all|any)Predicate type misbehaviour Array vs. Collection > > > Key: COLLECTIONS-537 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-537 > Project: Commons Collections > Issue Type: Bug > Components: Functor >Affects Versions: 4.0 >Reporter: Frank Jakop > Fix For: 4.1 > > > Migrating from collections-generic to collections4 we encountered a type > problem with PredicateUtils. When you look at the method anyPredicate(), the > signature with array is typed with "Predicate" whereas the > signature with Collection is typed "? extends Predicate", so the both > methods are not equivalent. > We think both methods should have the same types, so it would not break > compatibility with a lot of legacy code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-395) Request for UnBoundedLRUMap implementation with extra get method
[ https://issues.apache.org/jira/browse/COLLECTIONS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-395. --- > Request for UnBoundedLRUMap implementation with extra get method > > > Key: COLLECTIONS-395 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-395 > Project: Commons Collections > Issue Type: Wish > Components: Map >Affects Versions: Nightly Builds >Reporter: David Hawthorne >Priority: Minor > Fix For: 4.1 > > > I've created an UnBoundedLRUMap implementation (based off of BoundedLRUMap) > using the svn tree at version 3.3, and this has come in so handy that it > makes sense to suggest it to the masters in charge of the collections > framework. > One tweak I made to the copy we're using is an extra get method that takes > two arguments: key and boolean. The boolean determines whether or not the > MRU item is updated, so we can make requests into the map that do *not* > affect order. This is sometimes necessary in real world environments where > you do not want a data structure with LRU-only accesses. > This implementation would solve the main problem we have with using the jdk's > LinkedHashMap LRU implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-558) ListOrderedSet#remove(int) should return E instead of Object
[
https://issues.apache.org/jira/browse/COLLECTIONS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-558.
---
> ListOrderedSet#remove(int) should return E instead of Object
>
>
> Key: COLLECTIONS-558
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-558
> Project: Commons Collections
> Issue Type: Bug
> Components: Set
>Affects Versions: 4.0
>Reporter: Felix Rabe
> Fix For: 4.1
>
>
> Since {{List#remove(int)}} returns {{E}} the implementation in
> {{ListOrderedSet}} should also return {{E}}.
> Minimal example that fails to compile:
> {code:java}
> ListOrderedSet los = new ListOrderedSet();
> los.add("foo");
> String s = los.remove(0);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-567) Add a MultiSet interface / implementations that do not violate the Collection contract
[ https://issues.apache.org/jira/browse/COLLECTIONS-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-567. --- > Add a MultiSet interface / implementations that do not violate the Collection > contract > -- > > Key: COLLECTIONS-567 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-567 > Project: Commons Collections > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Thomas Neidhart > Fix For: 4.1 > > > Prior to the release of 4.0 there was a discussion about to change the Bag > interface to make it compliant with the Collection contract. > The outcome was that the Bag interface should be kept as is to simplify > migration of older code-bases. > Now, it would make sense to add a MultiSet interface that is basically > similar to a Bag, but does comply to the Collection contract. The old Bag > could then be deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-550) Provide a simple way for creating an arbitrary String representation of a given Iterable
[
https://issues.apache.org/jira/browse/COLLECTIONS-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-550.
---
> Provide a simple way for creating an arbitrary String representation of a
> given Iterable
>
>
> Key: COLLECTIONS-550
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-550
> Project: Commons Collections
> Issue Type: New Feature
> Components: Collection
>Affects Versions: 4.0
>Reporter: Gonçalo Marques
>Priority: Minor
> Labels: collection, util
> Fix For: 4.1
>
>
> Create an utility method that returns an arbitrary {{String}} representation
> of a given {{Iterable}}, where for each {{Iterable}} element one may require
> a {{String}} representation that is different from the element's own
> {{toString()}} result.
> Additionally the client may also provide an optional delimiter, where the
> default one could be the common {{", "}}.
> The transformation of each {{Iterable}} element into an arbitrary {{String}}
> could be implemented by the means of a {{Transformer}}.
> Example (illustrative method in {{CollectionUtils}}):
> {code}
> static String toString(Iterable iterable, Transformer
> transformer);
> {code}
> Consider the following illustrative class:
> {code}
> class SomeClass {
> private final String propertyOne;
> private final String propertyTwo;
> public SomeClass(String propertyOne, String propertyTwo) {
> this.propertyOne = propertyOne;
> this.propertyTwo = propertyTwo;
> }
> public String getPropertyOne() {
> return propertyOne;
> }
> public String getPropertyTwo() {
> return propertyTwo;
> }
> @Override
> public String toString() {
> return propertyOne;
> }
> }
> {code}
> One could transform an {{Iterable}} containing elements of type {{SomeClass}}
> into a client provided {{String}} representation by calling:
> {code}
> // list contains elements of type SomeClass
> String result = CollectionUtils.toString(list, new Transformer String>() {
> @Override
> public String transform(SomeClass someClass) {
> return someClass.getPropertyTwo();
> }
> });
> // Will print "propertyTwoA, propertyTwoB"
> System.out.println(result);
> result = CollectionUtils.toString(list, new Transformer() {
> @Override
> public String transform(SomeClass someClass) {
> return someClass.getPropertyOne() + someClass.getPropertyTwo();
> }
> });
> // Will print propertyOneApropertyTwoA, propertyOneBpropertyTwoB
> System.out.println(result);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-539) CircularFifoQueue: make 'isAtFullCapacity' method public
[ https://issues.apache.org/jira/browse/COLLECTIONS-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-539. --- > CircularFifoQueue: make 'isAtFullCapacity' method public > > > Key: COLLECTIONS-539 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-539 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Affects Versions: 4.0 >Reporter: Guram Savinov >Priority: Minor > Labels: queue > Fix For: 4.1 > > > CircularFifoQueue#isAtFullCapacity() method has private modifier, but I think > users want to use it (I want for example). > Please make this method as a public. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[ https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-442. --- > A set of enhanced iterator classes donated by the Apache Jena project > - > > Key: COLLECTIONS-442 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-442 > Project: Commons Collections > Issue Type: Improvement > Components: Iterator >Reporter: Claude Warren > Fix For: 4.1 > > Attachments: COLLECTIONS-442.tar.gz, FluentIterator.java, iter-src.zip > > > A set of templated (Generic) iterators that add filtering, mapping, and > conversion to set or list collections. Tests included. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-566) IteratorUtils.collatedIterator do not use natural ordering if no comparator was provided
[ https://issues.apache.org/jira/browse/COLLECTIONS-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-566. --- > IteratorUtils.collatedIterator do not use natural ordering if no comparator > was provided > > > Key: COLLECTIONS-566 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-566 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Thomas Neidhart > Fix For: 4.1 > > > In case a null comparator was provided natural ordering should be used, as > stated in the javadoc. > In fact an exception is thrown the first time the returned iterator is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-522) Documentation example does not compile
[ https://issues.apache.org/jira/browse/COLLECTIONS-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-522. --- > Documentation example does not compile > -- > > Key: COLLECTIONS-522 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-522 > Project: Commons Collections > Issue Type: Improvement > Components: List >Affects Versions: 4.0 >Reporter: Erik >Priority: Trivial > Fix For: 4.1 > > > There is an example in the javadoc of PredicatedList which doesn't compile: > // PredicatedList.java line 36 in the commons-collections4-4.0 > List list = PredicatedList.decorate(new ArrayList(), > NotNullPredicate.INSTANCE); > // The method decorate does not exist, I presume it has been renamed to: > List list = PredicatedList.predicatedList(new ArrayList(), > NotNullPredicate.INSTANCE); > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-464) Add FluentIterator / FluentIterable implementation
[ https://issues.apache.org/jira/browse/COLLECTIONS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-464. --- > Add FluentIterator / FluentIterable implementation > -- > > Key: COLLECTIONS-464 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-464 > Project: Commons Collections > Issue Type: Sub-task > Components: Iterator >Reporter: Thomas Neidhart > Fix For: 4.1 > > > Add an iterator implementation supporting a fluent API, similar to the Iter > class in jena. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-553) TransformedMultiValuedMap.equals() fails when comparing the value with itself
[
https://issues.apache.org/jira/browse/COLLECTIONS-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-553.
---
> TransformedMultiValuedMap.equals() fails when comparing the value with itself
> -
>
> Key: COLLECTIONS-553
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-553
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Affects Versions: 4.0
>Reporter: M Kim
> Fix For: 4.1
>
>
> TransformedMultiValuedMap.equals() does not return true when comparing a
> value of a Collection key with itself. Is it allowed to put Collection as a
> key in TransformedMultiValuedMap at all? If not, I think it should be
> specified in the document. Or, equals() should be fixed accordingly.
> Reproduce step
> {code:title=Test.java|borderStyle=solid}
> public void test()
> {
> TransformedMultiValuedMap map =
> TransformedMultiValuedMap.transformingMap((MultiValuedMap)new
> MultiValuedHashMap(),TransformerUtils.stringValueTransformer(),
> TransformerUtils.stringValueTransformer());
>
> MultiValuedHashMap helperMap = new MultiValuedHashMap();
> helperMap.put("KEY", "Value");
> Collection key = helperMap.keySet();
> map.put(key, "Hi");
> Collection value = map.get(key);
> assertTrue("Contract failed: value.equals(value)", value.equals(value));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-521) Typo in MultiMapKey's isEqualKey(entry, key1, key2)
[ https://issues.apache.org/jira/browse/COLLECTIONS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-521. --- > Typo in MultiMapKey's isEqualKey(entry, key1, key2) > --- > > Key: COLLECTIONS-521 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-521 > Project: Commons Collections > Issue Type: Bug >Reporter: Maxime Nay > Fix For: 4.1 > > > I believe there is a typo line 252 in MultiKeyMap. > return > multi.size() == 2 && > (key1 == multi.getKey(0) || key1 != null && > key1.equals(multi.getKey(0))) && > (key2 == multi.getKey(1) || key1 != null && > key2.equals(multi.getKey(1))); > should be: > return > multi.size() == 2 && > (key1 == multi.getKey(0) || key1 != null && > key1.equals(multi.getKey(0))) && > (key2 == multi.getKey(1) || key2 != null && > key2.equals(multi.getKey(1))); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-506) Result of CollectionUtils are different between version 3.2.1 and version 4.0
[
https://issues.apache.org/jira/browse/COLLECTIONS-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-506.
---
> Result of CollectionUtils are different between version 3.2.1 and version 4.0
> -
>
> Key: COLLECTIONS-506
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-506
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Anthony Communier
> Fix For: 4.1
>
> Attachments: test-common-collection.zip
>
>
> CollectionUtils V3 uses equals to compute results but not CollectionUtils v4
> (it seems to use ==)
> The following exemple with subtract method :
> List listA = new ArrayList();
> List listB = new ArrayList();
> listA.add(new ObjectTest("Test1"));
> listA.add(new ObjectTest("Test2"));
> listA.add(new ObjectTest("Test3"));
> listB.add(new ObjectTest("Test1"));
> listB.add(new ObjectTest("Test2"));
> Collection res1 =
> org.apache.commons.collections.CollectionUtils.subtract(listA, listB);
> System.out.println("Res1 size = " +res1.size());
> Collection res2 =
> org.apache.commons.collections4.CollectionUtils.subtract(listA, listB);
> System.out.println("Res2 size = " +res2.size());
> Produces this :
> Res1 size = 1
> Res2 size = 3
> The new behaviour is not useful. It would be better to have the V3 behaviour
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-238) ExtendedProperties.load() does not allow empty property values
[
https://issues.apache.org/jira/browse/COLLECTIONS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-238.
---
> ExtendedProperties.load() does not allow empty property values
> --
>
> Key: COLLECTIONS-238
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-238
> Project: Commons Collections
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Alexander Sova
> Attachments: NoEmptyStrings.java
>
>
> empty string is perfectly legal property value
> I think following lines need to be removed
> 595: // Configure produces lines like this ... just
> ignore them
> 596: if ("".equals(value)) {
> 597: continue;
> 598: }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-507) ComparatorUtils.chainedComparator(..) should not force the objects to implement Comparable
[ https://issues.apache.org/jira/browse/COLLECTIONS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-507. --- > ComparatorUtils.chainedComparator(..) should not force the objects to > implement Comparable > -- > > Key: COLLECTIONS-507 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-507 > Project: Commons Collections > Issue Type: Bug > Components: Comparator >Affects Versions: 4.0 >Reporter: Gerson > Fix For: 4.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-516) NullPointerException in MapUtils.toProperties
[ https://issues.apache.org/jira/browse/COLLECTIONS-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-516. --- > NullPointerException in MapUtils.toProperties > - > > Key: COLLECTIONS-516 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-516 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Affects Versions: 4.0 > Environment: Mac OS 10.9, Java 6 >Reporter: Cyrille Artho > Fix For: 4.1 > > Attachments: Report4.java > > > calling MapUtils.toProperties with a map having null entries results in a > NullPointerException. In this case the Map has only entry . > However, javadoc states "A null input will return an empty > properties object." so (1) this should be clarified as it would > only apply to the map reference itself, not its contents, or (2) > an empty property object should be generated for null entries in > the map as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-543) AbstractCollectionDecorator should not delegate equals and hashcode
[ https://issues.apache.org/jira/browse/COLLECTIONS-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-543. --- > AbstractCollectionDecorator should not delegate equals and hashcode > --- > > Key: COLLECTIONS-543 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-543 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Thomas Neidhart > Fix For: 4.1 > > > In order to preserve the symmetry of equals the AbstractCollectionDecorator > shall not forward calls to equals and hashcode to the decorated collection. > The test for equality usually also includes a test for the specific > interface, e.g. List, which the collection decorator does not implement. > The relevant sub-classes like AbstractListDecorator can delegate the calls to > safely fulfill the Collections contract. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-364) DualTreeBidiMap.readObject() uses wrong comparator to create reverseMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-364. --- > DualTreeBidiMap.readObject() uses wrong comparator to create reverseMap > --- > > Key: COLLECTIONS-364 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-364 > Project: Commons Collections > Issue Type: Bug > Components: BidiMap >Reporter: Sebb >Assignee: Sebb > > DualTreeBidiMap.readObject() uses the wrong comparator to create reverseMap. > The code reads: > bq. reverseMap = new TreeMap(comparator); > it should read: > bq. reverseMap = new TreeMap(valueComparator); > Note: this was found when trying to fix generics warnings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-545) Undocumented performance issue in the removeAll method in CollectionUtils
[
https://issues.apache.org/jira/browse/COLLECTIONS-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-545.
---
> Undocumented performance issue in the removeAll method in CollectionUtils
> -
>
> Key: COLLECTIONS-545
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-545
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.0
> Environment: Ubuntu 14.04
>Reporter: Oswaldo Olivo
>Priority: Trivial
> Labels: Collections, documentaion, performance
> Fix For: 4.1
>
>
> This bug is analogous to https://issues.apache.org/jira/browse/COLLECTIONS-544
> The method removeAll in CollectionUtils is inefficient when the second
> parameter collection has a slow containment method.
> The following is the current implementation with its documentation:
>
> /**
> * Removes the elements in remove from
> collection. That is, this
> * method returns a collection containing all the elements in
> c
> * that are not in remove. The cardinality of an element
> e
> * in the returned collection is the same as the cardinality of
> e
> * in collection unless remove contains
> e, in which
> * case the cardinality is zero. This method is useful if you do not wish
> to modify
> * the collection c and thus cannot call
> collection.removeAll(remove);.
> *
> * @param the type of object the {@link Collection} contains
> * @param collection the collection from which items are removed (in the
> returned collection)
> * @param remove the items to be removed from the returned
> collection
> * @return a Collection containing all the elements of
> collection except
> * any elements that also occur in remove.
> * @throws NullPointerException if either parameter is null
> * @since 4.0 (method existed in 3.2 but was completely broken)
> */
> public static Collection removeAll(final Collection collection,
> final Collection remove) {
> return ListUtils.removeAll(collection, remove);
> }
> ===
> We can notice the inefficiency by looking at the removeAll method in
> ListUtils.
> The removeAll method from ListUtils is implemented and documented as follows:
> ===
> /**
> * Removes the elements in remove from
> collection. That is, this
> * method returns a list containing all the elements in
> collection
> * that are not in remove. The cardinality of an element
> e
> * in the returned collection is the same as the cardinality of
> e
> * in collection unless remove contains
> e, in which
> * case the cardinality is zero. This method is useful if you do not wish
> to modify
> * collection and thus cannot call
> collection.removeAll(remove);.
> *
> * This implementation iterates over collection, checking
> each element in
> * turn to see if it's contained in remove. If it's not
> contained, it's added
> * to the returned list. As a consequence, it is advised to use a
> collection type for
> * remove that provides a fast (e.g. O(1)) implementation of
> * {@link Collection#contains(Object)}.
> *
> * @param the element type
> * @param collection the collection from which items are removed (in the
> returned collection)
> * @param remove the items to be removed from the returned
> collection
> * @return a List containing all the elements of
> c except
> * any elements that also occur in remove.
> * @throws NullPointerException if either parameter is null
> * @since 3.2
> */
> public static List removeAll(final Collection collection, final
> Collection remove) {
> final List list = new ArrayList();
> for (final E obj : collection) {
> if (!remove.contains(obj)) {
> list.add(obj);
> }
> }
> return list;
> }
> ===
> In the case of ListUtils:removeAll, the inefficiency is properly documented.
> Perhaps the disclaimer about potential inefficiencies depending on the type
> of the parameter collection in ListUtils:removeAll should also be included in
> CollectionUtils:removeAll.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-557) LRUMap memory usage vs size
[ https://issues.apache.org/jira/browse/COLLECTIONS-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030244#comment-15030244 ] Philippe Mouawad commented on COLLECTIONS-557: -- Hello [~tn], I see you set fix version to 3.2.2 [ 12316247 ] but I don't see it mentioned in release notes of 3.2.2 : http://commons.apache.org/proper/commons-collections/release_3_2_2.html Is it really in 3.2.2 or 3.2.X or only in 4.X ? Thanks > LRUMap memory usage vs size > --- > > Key: COLLECTIONS-557 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-557 > Project: Commons Collections > Issue Type: Improvement > Components: Map >Affects Versions: 3.2.1 >Reporter: Philippe Mouawad > Labels: MEMORY > Fix For: 4.1 > > > Hello, > Currently LRUMap uses maxSize parameter to configure its maxSize. > This is not great for its memory usage. > For example I have a use case where I can't really guess the target maxSize > of LRUMap so I have put a big number . > In reality I end up having 380 elements but LRUMap uses 33 Mb of memory > because it allocates (as capacity) LOAD_FACTORxsupposed max size. > It would be nice to have the possibility to set maxSize apart making it > unrelated to capacity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-557) LRUMap memory usage vs size
[ https://issues.apache.org/jira/browse/COLLECTIONS-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030249#comment-15030249 ] Thomas Neidhart commented on COLLECTIONS-557: - Fix version is set to 4.1 and this improvement is not in the 3.2.2 release as this was bugfix only. > LRUMap memory usage vs size > --- > > Key: COLLECTIONS-557 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-557 > Project: Commons Collections > Issue Type: Improvement > Components: Map >Affects Versions: 3.2.1 >Reporter: Philippe Mouawad > Labels: MEMORY > Fix For: 4.1 > > > Hello, > Currently LRUMap uses maxSize parameter to configure its maxSize. > This is not great for its memory usage. > For example I have a use case where I can't really guess the target maxSize > of LRUMap so I have put a big number . > In reality I end up having 380 elements but LRUMap uses 33 Mb of memory > because it allocates (as capacity) LOAD_FACTORxsupposed max size. > It would be nice to have the possibility to set maxSize apart making it > unrelated to capacity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-557) LRUMap memory usage vs size
[ https://issues.apache.org/jira/browse/COLLECTIONS-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030253#comment-15030253 ] Philippe Mouawad commented on COLLECTIONS-557: -- Thanks > LRUMap memory usage vs size > --- > > Key: COLLECTIONS-557 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-557 > Project: Commons Collections > Issue Type: Improvement > Components: Map >Affects Versions: 3.2.1 >Reporter: Philippe Mouawad > Labels: MEMORY > Fix For: 4.1 > > > Hello, > Currently LRUMap uses maxSize parameter to configure its maxSize. > This is not great for its memory usage. > For example I have a use case where I can't really guess the target maxSize > of LRUMap so I have put a big number . > In reality I end up having 380 elements but LRUMap uses 33 Mb of memory > because it allocates (as capacity) LOAD_FACTORxsupposed max size. > It would be nice to have the possibility to set maxSize apart making it > unrelated to capacity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-373) Bug in class#ListOrderedSet with reproducible JUnit test
[ https://issues.apache.org/jira/browse/COLLECTIONS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-373. --- > Bug in class#ListOrderedSet with reproducible JUnit test > > > Key: COLLECTIONS-373 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-373 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 3.2 > Environment: jdk 1.6.x >Reporter: Sai Zhang > Labels: patch > Attachments: ApacheListOrderSet_Documented_Test.java > > > Hi all: > I am writing an automated bug finding tool, and using > Apache Commons Collections as an experimental subject > for evaluation. > The tool creates executable JUnit tests as well as > explanatory code comments. I attached one bug-revealing > test as follows. Could you please kindly check it, to > see if it is a real bug or not? > Also, it would be tremendous helpful if you could give > some feedback and suggestion on the generated code comments? > From the perspective of developers who are relatively familiar > with the code, > is the automatically-inferred comment useful in understanding > the generated test? is the comment helpful in bug fixing? > Your suggestion will help us improve the tool. > Please see attachment for the failed test. A little explaination > on the generated code comments in the failed test > //explaination: > //Test passes if var53 is: (java.lang.Boolean)false ===> means: > // test passes if var52 is not added to var28 (only in that case, var53 > is false) > boolean var53 = var28.add((java.lang.Object)var52); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-367) Add OSGi headers to bundles built and deployed via Maven
[ https://issues.apache.org/jira/browse/COLLECTIONS-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-367. --- > Add OSGi headers to bundles built and deployed via Maven > > > Key: COLLECTIONS-367 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-367 > Project: Commons Collections > Issue Type: Improvement >Reporter: Kirby Bohling > Attachments: 0001-Add-OSGi-bundle-information.patch > > > I use OSGi and Apache Felix. I've been downloading the source and I've > modified the Maven build of the jar to directly include OSGi headers. It > would be nice if the release builds did the same thing. > I can provide the Ant modifications if that is deemed useful. > I will attach the patch once this issue is created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-577) PatriciaTrie bugs when only a few bits change
[ https://issues.apache.org/jira/browse/COLLECTIONS-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-577. --- > PatriciaTrie bugs when only a few bits change > - > > Key: COLLECTIONS-577 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-577 > Project: Commons Collections > Issue Type: Bug > Components: Map >Affects Versions: 4.0 >Reporter: Chris Duncan >Priority: Critical > Fix For: 4.1 > > > I have a bug report for you, for the class AbstractPatriciaTrie. > It has to do with how you handle bits when they are very close to each other. > > For example, some of your methods seem to think that if the only difference > between a prefix and a longer string, is a single additional bit, then they > are actually the same data. Or if the only difference is some number of zero > bits, then it also thinks they are the same data. > There are also MANY situations where the prefixMap does not return all the > strings that start with the prefix. > Can you also make AbstractPatriciaTrie public, and your other package level > methods into protected level, that way I don't have to copy the entire class > and subclasse's code out into another class just to extend it? > thank you, > Chris Duncan (github user: VEQRYN) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-366) A light-weight list of integers
[ https://issues.apache.org/jira/browse/COLLECTIONS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-366. --- > A light-weight list of integers > --- > > Key: COLLECTIONS-366 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-366 > Project: Commons Collections > Issue Type: New Feature >Affects Versions: 3.2 >Reporter: Dmitry Katsubo > Attachments: COLLECTIONS-366.patch, RangeList_fixed1.zip > > > Sometimes there is a demand too have a list, that represents numbers within > some range (say, [5..10]). If the range is big (millions of records), > creating a dummy list that holds all instances of objects is too expensive. > The provided implementation (attached to this issue) solves this problem. > Nice to have in commons collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-484) maven : add IssueManagement declaration
[ https://issues.apache.org/jira/browse/COLLECTIONS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-484. --- > maven : add IssueManagement declaration > --- > > Key: COLLECTIONS-484 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-484 > Project: Commons Collections > Issue Type: Task >Reporter: lord >Priority: Trivial > > It would be nice to get the IssueManagement declared in pom.xml like this : > >Jira >https://issues.apache.org/jira/browse/COLLECTIONS > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-515) ClassCastException in LazySortedMap when used with equals/transformers
[ https://issues.apache.org/jira/browse/COLLECTIONS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-515. --- > ClassCastException in LazySortedMap when used with equals/transformers > -- > > Key: COLLECTIONS-515 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-515 > Project: Commons Collections > Issue Type: Bug > Components: Collection, Map >Affects Versions: 4.0 > Environment: Mac OS 10.9, Java 6 >Reporter: Cyrille Artho > Attachments: Report3.java > > > When LazySortedMap is used by equals, the result is > java.lang.ClassCastException: > org.apache.commons.collections4.map.LazySortedMap cannot be cast to > java.lang.String > This seems to be odd, as the use of the different transformations should not > result in internal casting to String. See the attached unit test to reproduce. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-443) Proposal for adding IndexedTreeMap to collections
[ https://issues.apache.org/jira/browse/COLLECTIONS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-443. --- > Proposal for adding IndexedTreeMap to collections > - > > Key: COLLECTIONS-443 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-443 > Project: Commons Collections > Issue Type: Improvement >Reporter: Vitaly Sazanovich >Priority: Minor > Fix For: 4.x > > > Dear developers, > I have written a small enhancement to JDK's TreeMap that allows to find and > retrieve entries by index. The project can be found here: > http://code.google.com/p/indexed-tree-map/ > This is a very requested feature, at least on stackoverflow: > http://stackoverflow.com/search?q=treemap+index > I though it would be nice and useful if my implementation becomes part of > Apache collections. Also I could maintain these implementations in the future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-416) ListUtils.removeAll() is very slow
[ https://issues.apache.org/jira/browse/COLLECTIONS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-416. --- > ListUtils.removeAll() is very slow > -- > > Key: COLLECTIONS-416 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-416 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 3.2.1 > Environment: java 1.6.0_24 > Ubuntu 11.10 >Reporter: Adrian Nistor > Attachments: Test.java, patch.diff > > > Hi, > I am encountering a performance problem in ListUtils.removeAll(). It > appears in version 3.2.1 and also in revision 1355448. I attached a > test that exposes this problem and a one-line patch that fixes it. On > my machine, for this test, the patch provides a 217X speedup. > To run the test, just do: > $ java Test > The output for the un-patched version is: > Time is 5430 > The output for the patched version is: > Time is 25 > As the patch shows, the problem is that > "ListUtils.removeAll(Collection collection, Collection remove)" > performs "remove.contains(obj)" for each element in "collection", > which can be very expensive if "remove.contains(obj)" is expensive, > e.g., when "remove" is a list. > The one-line patch I attached puts the elements of "remove" in a > HashSet (which has very fast "contains()"), if "remove" is not already > a set: > "if (!(remove instanceof java.util.Set)) remove = new > HashSet(remove);" > Is this a bug, or am I misunderstanding the intended behavior? If so, > can you please confirm that the patch is correct? > Thanks, > Adrian -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-397) BoundedFifoBuffer could allow null entries
[ https://issues.apache.org/jira/browse/COLLECTIONS-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-397. --- > BoundedFifoBuffer could allow null entries > -- > > Key: COLLECTIONS-397 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-397 > Project: Commons Collections > Issue Type: Improvement >Reporter: Sebb > > BoundedFifoBuffer could easily allow null entries - it uses an array for > storage. > Is there any reason why nulls should not be (optionally) allowed? > This would mean changing the remove() implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-248) TrackingCollection
[ https://issues.apache.org/jira/browse/COLLECTIONS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-248. --- > TrackingCollection > -- > > Key: COLLECTIONS-248 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-248 > Project: Commons Collections > Issue Type: New Feature > Components: Collection >Reporter: Nicolas Marchildon > Attachments: CollectionLoader.java, TrackingCollection.java, > TrackingCollectionTest.java > > > Sometimes you need to keep track of what was added and what was removed > from a collection, and that is what we created TrackingCollection for. > Additionally, since we were implementing lazy-loading of collections of > persistent objects, we introduced a CollectionLoader that is used by the > TrackingCollection when it has to access all of its elements. It is > still possible however to use the TrackingCollection without a loader, > and it will simply start empty and be considered loaded. > Sherpa Solutions is offering the Apache Software Foundation the > attached source code, to be distributed by the projet under the > Apache License terms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-513) NullPointerException in SwitchTransformer.transform
[ https://issues.apache.org/jira/browse/COLLECTIONS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-513. --- > NullPointerException in SwitchTransformer.transform > --- > > Key: COLLECTIONS-513 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-513 > Project: Commons Collections > Issue Type: Bug > Components: Functor >Affects Versions: 4.0 > Environment: Mac OS 10.9, Java 6 and Java 7 >Reporter: Cyrille Artho > Attachments: BugReport2.java > > > A relatively complex test case generated by Randoop results in a > NullPointerException in SwitchTransformer.transform. > I'm not sure if this is an incorrect usage of the method, or if it is a real > bug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-476) Collection wrappers to for unmodifiable / nonnull-safe collections
[
https://issues.apache.org/jira/browse/COLLECTIONS-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-476.
---
> Collection wrappers to for unmodifiable / nonnull-safe collections
> --
>
> Key: COLLECTIONS-476
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-476
> Project: Commons Collections
> Issue Type: New Feature
> Components: List, Set
>Reporter: offbynull
>Priority: Minor
>
> Would it be possible to add something like this to commons lang? Commons
> collection looks like it's pretty much dead, and the only alternative for
> this kind of stuff is Google's horribly designed and massively confusing
> Guava library.
> Below are a couple of quick and dirty (untested) examples of the kind of
> wrappers I'm talking about. Note the isLocked/locked methods and the
> viewBlacklist method. Using these methods, it's easy for a component
> receiving a list/set to identify that it's currently unmodifiable and that
> the collection restricts certain values (e.g. null? maybe others?).
> {code}
> public final class LockableBlacklistableList implements List {
> private boolean locked;
> private List list;
> private Set blacklist;
> public LockableBlacklistableList(List backingList, T... blacklist) {
> if (backingList == null) {
> throw new NullPointerException();
> }
> if (!backingList.isEmpty()) {
> throw new IllegalArgumentException();
> }
> this.blacklist = new HashSet<>(Arrays.asList(blacklist));
> this.list = backingList;
> }
> public void lock() {
> locked = true;
> }
> public boolean isLocked() {
> return locked;
> }
> public Set viewBlacklist() {
> return Collections.unmodifiableSet(blacklist);
> }
> @Override
> public int size() {
> return list.size();
> }
> @Override
> public boolean isEmpty() {
> return list.isEmpty();
> }
> @Override
> public boolean contains(Object o) {
> return list.contains(o);
> }
> @Override
> public Iterator iterator() {
> final Iterator it = list.iterator();
> return new Iterator() {
> @Override
> public boolean hasNext() {
> return it.hasNext();
> }
> @Override
> public T next() {
> return it.next();
> }
> @Override
> public void remove() {
> if (locked) {
> throw new IllegalStateException();
> }
> it.remove();
> }
> };
> }
> @Override
> public Object[] toArray() {
> return list.toArray();
> }
> @Override
> public T[] toArray(T[] a) {
> return list.toArray(a);
> }
> @Override
> public boolean add(T e) {
> if (locked) {
> throw new IllegalStateException();
> }
> return list.add(e);
> }
> @Override
> public boolean remove(Object o) {
> if (locked) {
> throw new IllegalStateException();
> }
> return list.remove(o);
> }
> @Override
> public boolean containsAll(Collection c) {
> return list.containsAll(c);
> }
> @Override
> public boolean addAll(Collection c) {
> if (locked) {
> throw new IllegalStateException();
> }
> for (T item : c) {
> if (blacklist.contains(item)) {
> throw new IllegalArgumentException();
> }
> }
> return list.addAll(c);
> }
> @Override
> public boolean addAll(int index, Collection c) {
> if (locked) {
> throw new IllegalStateException();
> }
> for (T item : c) {
> if (blacklist.contains(item)) {
> throw new IllegalArgumentException();
> }
> }
> return list.addAll(index, c);
> }
> @Override
> public boolean removeAll(Collection c) {
> if (locked) {
> throw new IllegalStateException();
> }
> return list.removeAll(c);
> }
> @Override
> public boolean retainAll(Collection c) {
> if (locked) {
> throw new IllegalStateException();
> }
> return list.retainAll(c);
> }
> @Override
> public void clear() {
> if (locked) {
> throw new IllegalStateException();
> }
> list.clear();
> }
> @Override
> public boolean equals(Object o) {
> return list.equals(o);
> }
> @Override
> public int hashCode() {
> return list.hashCode();
> }
> @Overri
[jira] [Closed] (COLLECTIONS-489) Satisfies utility method
[ https://issues.apache.org/jira/browse/COLLECTIONS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-489. --- > Satisfies utility method > > > Key: COLLECTIONS-489 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-489 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Affects Versions: 3.2.2, 4.0-alpha1, 4.0, 4.x, Nightly Builds >Reporter: Josh Cain >Priority: Trivial > Labels: features, newbie, util > Original Estimate: 2h > Remaining Estimate: 2h > > I recently needed to use something like the CollectionUtils.exists method, > but I wanted to know if a given predicate was true for ALL members of a > collection, rather than just one. I cooked up a quick method called > satisfies (help would be appreciated on the name - it's the best that I could > come up with) that determines whether a given predicate is true for all > members of a collection. > Been using this library a good deal recently - hoping to get involved in its > development! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-430) Create static factory methods for concrete data structure impls in the corresponding Utils classes
[
https://issues.apache.org/jira/browse/COLLECTIONS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-430.
---
> Create static factory methods for concrete data structure impls in the
> corresponding Utils classes
> --
>
> Key: COLLECTIONS-430
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-430
> Project: Commons Collections
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Thomas Neidhart
>
> It is quite tedious to write code like this:
> {noformat}
> BidiMap map = new DualHashBidiMap();
> {noformat}
> a more convenient way would be to take advantage from type inference like
> this:
> {noformat}
> BidiMap map = MapUtils.newHashBidiMap();
> {noformat}
> This would apply basically for all data structures that are available in CC
> atm.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-368) New method in ListUtils to create Lists populated with var-args elements
[ https://issues.apache.org/jira/browse/COLLECTIONS-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-368. --- > New method in ListUtils to create Lists populated with var-args elements > > > Key: COLLECTIONS-368 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-368 > Project: Commons Collections > Issue Type: New Feature > Components: List >Reporter: Henrik Segesten >Priority: Minor > Attachments: addcreatelist.patch > > > Sometimes it is very useful to be able to create new and populate List > objects in the same way that can be done with arrays by using the braces > initialisation. My patch is an implementation of this for ListUtils with > corresponding unit tests. Hoping for inclusion as soon as possible. Any > comments are welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-548) Performance issue in CompositeCollection::retainAll
[
https://issues.apache.org/jira/browse/COLLECTIONS-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-548.
---
> Performance issue in CompositeCollection::retainAll
> ---
>
> Key: COLLECTIONS-548
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-548
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.0
> Environment: Ubuntu 14.04
>Reporter: Oswaldo Olivo
>Priority: Minor
> Labels: performance
>
> There seems to be a performance problem with the function retainAll of
> CompositeCollection. This is analogous to
> https://issues.apache.org/jira/browse/COLLECTIONS-534 .
> The following is the code of the function:
> {code}
>
> /**
> * Retains all the elements in the specified collection in this composite
> collection,
> * removing all others.
> *
> * This implementation calls retainAll() on each collection.
> *
> * @param coll the collection to remove
> * @return true if the collection was modified
> * @throws UnsupportedOperationException if retainAll is unsupported
> */
> public boolean retainAll(final Collection coll) {
> boolean changed = false;
> for (final Collection item : all) {
> changed |= item.retainAll(coll);
> }
> return changed;
> }
> {code}
> The performance problem occurs when the underlying collections in the current
> collection have a slow retainAll method. Whenever we're relying on
> Collection::retainAll, slow cases tend to occur when the parameter collection
> has a slow contains method.
> The following test harness shows the performance degradation between
> using a list and using a set as a parameter, across different collection
> sizes.
> {code}
> public static void compositeCollectionRetainAllTest(boolean original) {
> int N=50;
> ArrayList firstArrayList=new ArrayList();
> ArrayList secondArrayList=new ArrayList();
> for(int i=0;i firstArrayList.add(new Integer(i));
> secondArrayList.add(new Integer(N-1-i));
>
> }
> CompositeCollection col = new CompositeCollection(firstArrayList);
> col.retainAll(original ? secondArrayList : (new
> HashSet(secondArrayList)));
>
> }
> {code}
> In the following table "Original" corresponds to the time taken by
> the existing implementation of CompositeCollection::retainAll, "Repaired" to
> the time taken by the function invoked with the parameter converted into a
> set, and "Speed-up" to the speed-up obtained after the repair.
> N Original(s) Repaired(s) Speed-up(X)
> 10 1.04 1.041.00
> 1001.04 1.050.99
> 1000 1.061.061.00
> 1 1.121.101.01
> 109.341.158.12
> 50> 300 1.29> 232.55
> If it's unacceptable to convert the parameter into a set before calling
> retainsAll, a solution would be to include a warning to the user in the
> documentation that the parameter should have a fast contains method when
> possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-579) PassiveExpiringMap doesn't work when the key is a byte array
[
https://issues.apache.org/jira/browse/COLLECTIONS-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-579.
---
> PassiveExpiringMap doesn't work when the key is a byte array
>
>
> Key: COLLECTIONS-579
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-579
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Affects Versions: 4.0
> Environment: GNU/Linux Ubuntu 15.10 64 bits, OpenJDK 1.8.0_65
>Reporter: Roger R Andrews
>
> When you put a (key,value) pair in a PassiveExpiringMap and the key is byte[]
> you can't retrieve it.
> Code to reproduce the problem:
> byte[] key = {0,0,0,1};
> PassiveExpiringMap map = new PassiveExpiringMap
> ();
> map.put(key,key);
> byte[] queryKey = {0,0,0,1};
> //this should be true
> map.containsKey(queryKey) == false
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-401) Inconsistent Javadoc comment and code in removeAll(Collection, Collection) in org.apache.commons.collections.ListUtils
[
https://issues.apache.org/jira/browse/COLLECTIONS-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-401.
---
> Inconsistent Javadoc comment and code in removeAll(Collection,
> Collection) in org.apache.commons.collections.ListUtils
>
>
> Key: COLLECTIONS-401
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-401
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 3.2.1
>Reporter: SHIN HWEI TAN
> Labels: javadoc
> Original Estimate: 0.05h
> Remaining Estimate: 0.05h
>
> The Javadoc comment below states that the method "throws NullPointerException
> if either parameter is null".
>/*..
>*
>* @throws NullPointerException if either parameter is null
>*/
> public static List removeAll(Collection collection,
> Collection remove) {
> ..
> }
> However, when called with two null collections (i.e.,
> "removeAll((Collection)null, (Collection)null)"), the method executes
> normally without throwing any exception.
> Suggested Fixes:
> 1. Add code "if (collection == null) throw NullPointerException();" at the
> beginning of the method body.
> or
> 2. Remove "@throws NullPointerException if either parameter is null" from the
> Javadoc.
> or
> 3. Change "@throws NullPointerException if either parameter is null" to
> "@throws NullPointerException if the first collection is null or (the first
> collection is non-empty and the second collection is null)".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-514) NullPointerException in MapBackedSet.mapBackedSet
[ https://issues.apache.org/jira/browse/COLLECTIONS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-514. --- > NullPointerException in MapBackedSet.mapBackedSet > - > > Key: COLLECTIONS-514 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-514 > Project: Commons Collections > Issue Type: Bug > Components: Bag, Collection, Set >Affects Versions: 4.0 > Environment: MacOS 10.9, Java 6 >Reporter: Cyrille Artho > Attachments: Report2.java > > > It seems that addAll has issues with adding a set that is backed by a > singleton map with entry null -> null. However, the javadoc of the involved > classes does not state that null entries are disallowed. > Either the code should allow adding a null entry to a bag, or the > documentation should state that null entries are not allowed. > See the attached unit test in JUnit format to reproduce the problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-483) Cyclic dependencies among several packages.
[ https://issues.apache.org/jira/browse/COLLECTIONS-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-483. --- > Cyclic dependencies among several packages. > --- > > Key: COLLECTIONS-483 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-483 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 4.0-alpha1, 4.0 >Reporter: Brahim Djoudi >Priority: Minor > Attachments: c4-refactored.png, c4-refactoring.pdf, c4-src.zip, c4.png > > Original Estimate: 4h > Remaining Estimate: 4h > > Many packages have mutual dependency, directly or undirectly. > These dependencies may be avoided just by moving some classes and interfaces > within different packages. > This refactoring breaks API compatibility but enhances the useability and the > maintainability (hopefully) of the library. In addition, few issues in > dynamic environments (like OSGi) less occur. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-438) ExtendedProperties : String only composed of spaces character
[ https://issues.apache.org/jira/browse/COLLECTIONS-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-438. --- > ExtendedProperties : String only composed of spaces character > - > > Key: COLLECTIONS-438 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-438 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Reporter: Guillaume Chauvet > Attachments: COLLECTIONS-438.patch > > > We have discovered a bug in ExtendedProperties class used in our internal > language manager framework. The cause are strings which contains only spaces > character. We provide a patch to complete the JUnit class > ExtendedPropertiesTest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-482) Transformed* classes require double the number of generic qualifiers
[ https://issues.apache.org/jira/browse/COLLECTIONS-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-482. --- > Transformed* classes require double the number of generic qualifiers > > > Key: COLLECTIONS-482 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-482 > Project: Commons Collections > Issue Type: Bug > Components: Bag, Collection, List, Map, Set >Affects Versions: 4.0-alpha1 >Reporter: Hollis Waite > > Transformed* classes currently have the same number of generic qualifiers as > their parent interfaces (e.g. one for TransformedList and two for > TransformedMap). In order to handle transformations between different types, > transforming collections should specify both input and output classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-554) NullPointerException in CollectionUtils.partition
[
https://issues.apache.org/jira/browse/COLLECTIONS-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-554.
---
> NullPointerException in CollectionUtils.partition
> -
>
> Key: COLLECTIONS-554
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-554
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.1
>Reporter: M Kim
>Priority: Minor
>
> NullPointerException (NPE) is not suitably handled in
> CollectionUtils.partition. With a nullFactory,
> partitions.get(numberOfPredicates) can be null at line
> partitions.get(numberOfPredicates).add(element);.
> Stack trace:
> {code}
> test(Test)java.lang.NullPointerException
> at
> org.apache.commons.collections4.CollectionUtils.partition(CollectionUtils.java:1187)
> at Test.test(Test.java:18)
> {code}
> Test case:
> {code}
> public void test() {
> Collection input = CollectionUtils.permutations((java.util.Collection)new
> CircularFifoQueue(10));
> Factory factory = FactoryUtils.nullFactory();
> NullIsFalsePredicate p = new
> NullIsFalsePredicate(NullPredicate.nullPredicate());
> Predicate[] predicates = p.getPredicates();
>
> CollectionUtils.partition((java.lang.Iterable)input,
> factory, predicates);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-325) Improve thread-safety of ExtendedProperties
[ https://issues.apache.org/jira/browse/COLLECTIONS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-325. --- > Improve thread-safety of ExtendedProperties > --- > > Key: COLLECTIONS-325 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-325 > Project: Commons Collections > Issue Type: Improvement >Reporter: Sebb > > It looks as though ExtendedProperties is intended to be thread-safe, > otherwise why bother synchronizing load() and save()? > If so, then ExtendedProperties field "isInitialized" should be made volatile > to ensure the variable is correctly published. > Likewise, the field "includePropertyName" needs to be volatile or > synchronised. > Also, the following protected variables could be made final to improve > thread-safety: > defaults > file > basePath > fileSeparator - this could perhaps be static too? > keysAsListed > Regardless of thread-safety issues, does it make sense for these variables to > be changed once initialised? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-423) FastArrayList.toString() fails to check for reference to itself
[ https://issues.apache.org/jira/browse/COLLECTIONS-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-423. --- > FastArrayList.toString() fails to check for reference to itself > --- > > Key: COLLECTIONS-423 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-423 > Project: Commons Collections > Issue Type: Bug > Components: List >Affects Versions: 3.2.1 > Environment: All environments >Reporter: Michael Pradel > > FastArrayList.toString() throws a StackOverflowError when the list contains > itself, because toString() is called recursively. In contrast, ArrayList > checks for this case and deals with it appropriately. E.g.: > ArrayList l = new FastArrayList(); > l.add(l); > l.toString(); // StackOverflowError > But: > ArrayList l = new ArrayList(); > l.add(l); > l.toString(); // OK > > To be compatible with its superclass, FastArrayList should also consider this > special case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-365) [collections] ListOrderedSet implementing java.util.List
[
https://issues.apache.org/jira/browse/COLLECTIONS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed COLLECTIONS-365.
---
> [collections] ListOrderedSet implementing java.util.List
>
>
> Key: COLLECTIONS-365
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-365
> Project: Commons Collections
> Issue Type: Improvement
> Components: Set
>Affects Versions: 3.2
>Reporter: Dmitry Katsubo
>
> It looks like nothing prevents {{ListOrderedSet}} to implement
> {{java.util.List}} interface. One need to implement just few methods:
> set(int index, Object element);
> ListIterator listIterator();
> List subList(int fromIndex, int toIndex);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-519) private constructors in utility classes break existing code
[ https://issues.apache.org/jira/browse/COLLECTIONS-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-519. --- > private constructors in utility classes break existing code > --- > > Key: COLLECTIONS-519 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-519 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 4.x >Reporter: Radoslav Paskalev > > Hello, > In collections version 4.x all utility classes (example ListUtils, MapUtils, > PredicateUtils) have private constructors. I consider this to be a > serious bug, as it breaks any possibility the classes to be extended by the > users. The javadoc says that constructors are private in order to prevent > class instantiation but this object instantiation is not really problem and i > think it is more important to allow classes to be extended. The possibility > to extend utility classes was one of the major selling points of commons.lang > and commons.collections projects. In the latest commons.lang project the > utility classes still have public constructors. > Best Regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-440) Consider including heap implementations from java-heaps project
[ https://issues.apache.org/jira/browse/COLLECTIONS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-440. --- > Consider including heap implementations from java-heaps project > --- > > Key: COLLECTIONS-440 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-440 > Project: Commons Collections > Issue Type: New Feature >Reporter: Thomas Neidhart > Fix For: 4.x > > > http://code.google.com/p/java-heaps/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-212) Alternate implementations of ResettableIterator
[ https://issues.apache.org/jira/browse/COLLECTIONS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-212. --- > Alternate implementations of ResettableIterator > --- > > Key: COLLECTIONS-212 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-212 > Project: Commons Collections > Issue Type: Improvement > Components: Iterator > Environment: Operating System: other > Platform: All >Reporter: worodin >Priority: Minor > Fix For: 3.2 > > Attachments: ASF.LICENSE.NOT.GRANTED--first.patch, > ASF.LICENSE.NOT.GRANTED--second.patch, ASF.LICENSE.NOT.GRANTED--third.patch > > > Relates to Discussion on Mailing List: > first.patch turns ListIteratorWrapper into an ResettableIterator, and adds > ResettableListIteratorWrapper, which yields a ResettableListIterator from > every List > second.patch -> some more implementations of Decorators adding Resettability > third.patch -> the reason I'm interested in resettability: CartesianIterator -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COLLECTIONS-439) TreeBag with comparator does not store non-key duplicates.
[ https://issues.apache.org/jira/browse/COLLECTIONS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart closed COLLECTIONS-439. --- > TreeBag with comparator does not store non-key duplicates. > -- > > Key: COLLECTIONS-439 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-439 > Project: Commons Collections > Issue Type: Improvement > Components: Bag >Affects Versions: 3.2.1 >Reporter: Claude Warren > Attachments: BagTest.java, COLLECTIONS-439.tar.gz, SortedBag.java > > > When storing objects that are sorted by a Comparator, if the differences in > the objects are not in the comparator the same version of the object is > returned. I expected that the sorted bag would work like a DB table with a > non-unique key -- ordered but duplicate only determined by Object.equals(). > I have implemented this type of bag using a TreeMap of List. My > implementation uses the Jena ExtendedIterator to make building the iterator() > and array() methods easier. > Will attach the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
