[jira] [Commented] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly

[Thomas Neidhart (Jira)]

[ 
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824873#comment-17824873
 ] 

Thomas Neidhart commented on CLI-221:
-

I agree that the behavior is odd, but oth this bug is > 10 years old, the 
GnuParser class has been deprecated since release 1.3, I would just close this 
issue as Wont'Fix.

> cli's with last option as list type values and have argument are not parsed 
> correctly
> -
>
> Key: CLI-221
> URL: https://issues.apache.org/jira/browse/CLI-221
> Project: Commons CLI
>  Issue Type: Bug
>  Components: Parser
>Affects Versions: 1.2
>Reporter: Gagan Jain
>Priority: Major
>
> I have set the value separator for an option to be comma (',').
> Consider the following cli:
> cli definition : cmd1 -o1  a1
> command name: 'cmd1'
> options: 'o1' accpets list of values separated by ','
> arguments: 'a1' single valued argument
> {code}cmd1 -o1 o1v1,o1v2,o1v3 a1v1{code}
> GnuParser parses this the cli with o1 having values {o1v1, o1v2, o1v3, a1v1} 
> instead of {o1v1,o1v2,o1v3}
> Bug seems to be in org.apache.commons.cli.Parser's class processArgs method.
> {code:java}
> public void processArgs(Option opt, ListIterator iter) throws 
> ParseException
> {
> // loop until an option is found
> while (iter.hasNext())
> {
> String str = (String) iter.next();
> // found an Option, not an argument
> if (getOptions().hasOption(str) && str.startsWith("-"))
> {
> iter.previous();
> break;
> }
> // found a value
> try
> {
> 
> opt.addValueForProcessing(Util.stripLeadingAndTrailingQuotes(str));
> }
> catch (RuntimeException exp)
> {
> iter.previous();
> break;
> }
> }
> if (opt.getValues() == null && !opt.hasOptionalArg())
> {
> throw new MissingArgumentException(opt);
> }
> }
> {code}
> In my opinion, if a value separator is defined for option, and is other than 
> space (' '), loop should break immediately after one iteration.
> Correct me, if I am wrong in my understanding.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (BCEL-311) ClassCastException in Verifier Pass 2

[Thomas Neidhart (Jira)]

[ 
https://issues.apache.org/jira/browse/BCEL-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036181#comment-17036181
 ] 

Thomas Neidhart commented on BCEL-311:
--

Running javap on the provided class produces this output:

 

{code}

{
Error: unexpected entry at #5 -- expected tag 1, found 7
Error: invalid index #64400
Error: invalid index #64400
 public ??? ??;
Error: invalid index #64400
 descriptor: ???
 flags: (0x0001) ACC_PUBLIC
 Code:
Error: invalid index #64400

{code}

 

which is an indication that the provided class is not well-formed.

> ClassCastException in Verifier Pass 2
> -
>
> Key: BCEL-311
> URL: https://issues.apache.org/jira/browse/BCEL-311
> Project: Commons BCEL
>  Issue Type: Bug
>  Components: Verifier
>Affects Versions: 6.2
>Reporter: Rohan Padhye
>Priority: Major
> Attachments: Hello.class
>
>
> Verifier throws ClassCastException on malformed input instead of reporting 
> verification failure.
> h1. Steps to reproduce:
>  
> Save the attached file as "Hello.class" and run:
> java -cp  org.apache.bcel.verifier.Verifier Hello
>  
> The file Hello.class was generated automatically by the fuzzer JQF 
> ([https://github.com/rohanpadhye/jqf]).
> h2. Expected output:
> VERIFIED_REJECTED
> h2. Observed output:
> JustIce by Enver Haase, (C) 2001-2002.
> 
> 
>  
> Now verifying: Hello
>  
> Pass 1:
> VERIFIED_OK
> Passed verification.
>  
> Exception in thread "main" java.lang.ClassCastException: Illegal constant 
> 'CONSTANT_Class[7](name_index = 21)' at index '5'. '<>' expects a 
> 'class org.apache.bcel.classfile.ConstantUtf8'.
>  at 
> org.apache.bcel.verifier.statics.Pass2Verifier$CPESSC_Visitor.checkIndex(Pass2Verifier.java:372)
>  at 
> org.apache.bcel.verifier.statics.Pass2Verifier$CPESSC_Visitor.visitMethod(Pass2Verifier.java:622)
>  at org.apache.bcel.classfile.Method.accept(Method.java:108)
>  at 
> org.apache.bcel.classfile.DescendingVisitor.visitMethod(DescendingVisitor.java:159)
>  at org.apache.bcel.classfile.Method.accept(Method.java:108)
>  at 
> org.apache.bcel.classfile.DescendingVisitor.visitJavaClass(DescendingVisitor.java:99)
>  at org.apache.bcel.classfile.JavaClass.accept(JavaClass.java:213)
>  at 
> org.apache.bcel.classfile.DescendingVisitor.visit(DescendingVisitor.java:85)
>  at 
> org.apache.bcel.verifier.statics.Pass2Verifier$CPESSC_Visitor.(Pass2Verifier.java:361)
>  at 
> org.apache.bcel.verifier.statics.Pass2Verifier$CPESSC_Visitor.(Pass2Verifier.java:317)
>  at 
> org.apache.bcel.verifier.statics.Pass2Verifier.constant_pool_entries_satisfy_static_constraints(Pass2Verifier.java:302)
>  at 
> org.apache.bcel.verifier.statics.Pass2Verifier.do_verify(Pass2Verifier.java:161)
>  at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)
>  at org.apache.bcel.verifier.Verifier.doPass2(Verifier.java:76)
>  at org.apache.bcel.verifier.Verifier.main(Verifier.java:211)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BCEL-310) ArrayIndexOutOfBounds in Verifier Pass 3A

[Thomas Neidhart (Jira)]

[ 
https://issues.apache.org/jira/browse/BCEL-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036180#comment-17036180
 ] 

Thomas Neidhart commented on BCEL-310:
--

Running javap on the class file produces this output:

 

{code}

public Hello();
 descriptor: ()V
 flags: (0x0001) ACC_PUBLIC
 Code:
 stack=1, locals=1, args_size=1
Error: A serious internal error has occurred: java.lang.NullPointerException
Please file a bug report, and include the following information:
java.lang.NullPointerException
 at 
jdk.jdeps/com.sun.tools.javap.CodeWriter$1.visitArrayType(CodeWriter.java:138)
 at 
jdk.jdeps/com.sun.tools.javap.CodeWriter$1.visitArrayType(CodeWriter.java:131)
 at jdk.jdeps/com.sun.tools.classfile.Instruction.accept(Instruction.java:258)
 at jdk.jdeps/com.sun.tools.javap.CodeWriter.writeInstr(CodeWriter.java:126)
 at jdk.jdeps/com.sun.tools.javap.CodeWriter.writeInstrs(CodeWriter.java:108)
 at jdk.jdeps/com.sun.tools.javap.CodeWriter.write(CodeWriter.java:75)
 at 
jdk.jdeps/com.sun.tools.javap.AttributeWriter.visitCode(AttributeWriter.java:235)
 at 
jdk.jdeps/com.sun.tools.javap.AttributeWriter.visitCode(AttributeWriter.java:87)
 at 
jdk.jdeps/com.sun.tools.classfile.Code_attribute.accept(Code_attribute.java:102)
 at 
jdk.jdeps/com.sun.tools.javap.AttributeWriter.write(AttributeWriter.java:112)
 at jdk.jdeps/com.sun.tools.javap.ClassWriter.writeMethod(ClassWriter.java:587)
 at jdk.jdeps/com.sun.tools.javap.ClassWriter.writeMethods(ClassWriter.java:471)
 at jdk.jdeps/com.sun.tools.javap.ClassWriter.write(ClassWriter.java:269)
 at jdk.jdeps/com.sun.tools.javap.JavapTask.write(JavapTask.java:836)
 at jdk.jdeps/com.sun.tools.javap.JavapTask.writeClass(JavapTask.java:655)
 at jdk.jdeps/com.sun.tools.javap.JavapTask.run(JavapTask.java:600)
 at jdk.jdeps/com.sun.tools.javap.JavapTask.run(JavapTask.java:450)
 at jdk.jdeps/com.sun.tools.javap.Main.main(Main.java:47)

{code}

 

which is an indication that the class file is not well-formed.

> ArrayIndexOutOfBounds in Verifier Pass 3A
> -
>
> Key: BCEL-310
> URL: https://issues.apache.org/jira/browse/BCEL-310
> Project: Commons BCEL
>  Issue Type: Bug
>  Components: Verifier
>Affects Versions: 6.2
>Reporter: Rohan Padhye
>Priority: Major
> Attachments: Hello.class
>
>
> Verifier throws OOB on malformed input instead of reporting verification 
> failure.
> h1. Steps to reproduce:
>  
> Save the attached file as "Hello.class" and run:
> java -cp  org.apache.bcel.verifier.Verifier Hello
>  
> The file Hello.class was generated automatically by the fuzzer JQF 
> ([https://github.com/rohanpadhye/jqf]).
> h2. Expected output:
> VERIFIED_REJECTED
> h2. Observed output:
> JustIce by Enver Haase, (C) 2001-2002.
> 
> 
>  
> Now verifying: Hello
>  
> Pass 1:
> VERIFIED_OK
> Passed verification.
>  
> Pass 2:
> VERIFIED_OK
> Passed verification.
>  
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -73
>  at org.apache.bcel.Const.getTypeName(Const.java:1799)
>  at org.apache.bcel.generic.NEWARRAY.toString(NEWARRAY.java:90)
>  at org.apache.bcel.generic.Instruction.toString(Instruction.java:101)
>  at java.lang.String.valueOf(String.java:2994)
>  at java.lang.StringBuilder.append(StringBuilder.java:131)
>  at 
> org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.constraintViolated(Pass3aVerifier.java:499)
>  at 
> org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.visitNEWARRAY(Pass3aVerifier.java:835)
>  at org.apache.bcel.generic.NEWARRAY.accept(NEWARRAY.java:125)
>  at 
> org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:302)
>  at 
> org.apache.bcel.verifier.statics.Pass3aVerifier.pass3StaticInstructionOperandsChecks(Pass3aVerifier.java:443)
>  at 
> org.apache.bcel.verifier.statics.Pass3aVerifier.do_verify(Pass3aVerifier.java:208)
>  at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)
>  at org.apache.bcel.verifier.Verifier.doPass3a(Verifier.java:8



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BCEL-309) NegativeArraySizeException when Code attribute length is negative

[Thomas Neidhart (Jira)]

[ 
https://issues.apache.org/jira/browse/BCEL-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036177#comment-17036177
 ] 

Thomas Neidhart commented on BCEL-309:
--

It is common practice to read the code_length value e.g. using readInt().

 

The JVM specification mandates that the code_length does not exceed 65536, see 
[https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.9.1]

 

Also when running javap on the class it generates an error:

 

{code}

public static void main(java.lang.String[]);
 descriptor: ([Ljava/lang/String;)V
 flags: (0x0009) ACC_PUBLIC, ACC_STATIC
Error: Unexpected or invalid value for Code attribute
Error: java.lang.reflect.InvocationTargetException
 Code: length = 0x25
 00 02 00 F5 3D 85 1B FD B2 00 02 12 03 B6 00 04
 B1 00 00 00 01 00 0A 00 00 00 0A 00 02 00 00 00
 03 00 08 00 04

{code}

 

Also proguard can not process this class file, I would not consider this as a 
bug and rather close the issue as won't fix.

The tool that processed this class file is more likely to contain a bug.

> NegativeArraySizeException when Code attribute length is negative
> -
>
> Key: BCEL-309
> URL: https://issues.apache.org/jira/browse/BCEL-309
> Project: Commons BCEL
>  Issue Type: Bug
>  Components: Parser
>Affects Versions: 6.2
>Reporter: Rohan Padhye
>Priority: Major
> Attachments: Hello.class
>
>
> Class parser throws an undocumented NegativeArraySizeException when parsing a 
> malformed class file.
> h1. Steps to reproduce:
>  
>  
> Attempt to parse the attached file "Hello.class" using the API
> org.apache.bcel.classfile.ClassParser.parse(java.io.InputStream)
>  
> The file Hello.class was generated automatically by the fuzzer JQF 
> ([https://github.com/rohanpadhye/jqf]).
> h2. Expected output:
> ClassFormatException should be thrown as the class file is malformed.
> h2. Observed output:
> Undocumented run-time exception is thrown:
> java.lang.NegativeArraySizeException
>  at org.apache.bcel.classfile.Code.(Code.java:75)
>  at org.apache.bcel.classfile.Attribute.readAttribute(Attribute.java:220)
>  at org.apache.bcel.classfile.FieldOrMethod.(FieldOrMethod.java:109)
>  at org.apache.bcel.classfile.Method.(Method.java:82)
>  at org.apache.bcel.classfile.ClassParser.readMethods(ClassParser.java:294)
>  at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:153)
>  
>  
> This is probably because the length of the Code attribute in a method is read 
> as a 4-byte signed integer, an an array of that size is allocated without 
> checking to see if the integer is negative.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (MATH-959) Add HAC clustering algorithm

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MATH-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved MATH-959.
--
   Resolution: Won't Fix
Fix Version/s: (was: 4.0)

> Add HAC clustering algorithm
> 
>
> Key: MATH-959
> URL: https://issues.apache.org/jira/browse/MATH-959
> Project: Commons Math
>  Issue Type: Sub-task
>Reporter: Thomas Neidhart
>Assignee: Thomas Neidhart
> Attachments: MATH-748.zip
>
>
> Add at least one hierarchical clustering algorithm.
> With the refactoring of the clustering package, this should now be feasible 
> as the Cluster class can be extended.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COLLECTIONS-587) commons-collections-3.2.2 does not compile under docker fedora21

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15258590#comment-15258590
 ] 

Thomas Neidhart commented on COLLECTIONS-587:
-

Commons Collections 3.X can not be compiled with Java 8+ due to incompatible 
additions to the Map interface.

The conflicting methods have been renamed in Collections 4.X.

> commons-collections-3.2.2 does not compile under docker fedora21
> 
>
> Key: COLLECTIONS-587
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-587
> Project: Commons Collections
>  Issue Type: Bug
>Affects Versions: 3.2
> Environment: docker, fedora21
>Reporter: Marc Pawlowsky
>
> In a clean environment using docker, compile errors
> $cat Dockerfile 
> FROM fedora:21 
> RUN yum update -y 
> RUN yum install -y java-1.8.0-openjdk unzip maven wget
> RUN wget 
> http://apache.mirror.rafal.ca//commons/collections/source/commons-collections-3.2.2-src.zip
> RUN unzip commons-collections-3.2.2-src.zip
> RUN cd commons-collections-3.2.2-src && mvn initialize
> RUN cd commons-collections-3.2.2-src && mvn install
> RUN chmod -R 755 /root
> CMD /bin/bash
> $docker build .
> 
> Downloaded: http://repo.maven.apache.org/maven2/commons-[INFO] Changes 
> detected - recompiling the module!
> [INFO] Compiling 273 source files to 
> /commons-collections-3.2.2-src/target/classes
> [INFO] -
> [ERROR] COMPILATION ERROR : 
> [INFO] -
> [ERROR] 
> /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiHashMap.java:[334,19]
>  remove(java.lang.Object,java.lang.Object) in 
> org.apache.commons.collections.MultiHashMap cannot implement 
> remove(java.lang.Object,java.lang.Object) in java.util.Map
>   return type java.lang.Object is not compatible with boolean
> [ERROR] 
> /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiMap.java:[69,19]
>  remove(java.lang.Object,java.lang.Object) in 
> org.apache.commons.collections.MultiMap clashes with 
> remove(java.lang.Object,java.lang.Object) in java.util.Map
>   return type java.lang.Object is not compatible with boolean
> [ERROR] 
> /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiValueMap.java:[156,19]
>  remove(java.lang.Object,java.lang.Object) in 
> org.apache.commons.collections.map.MultiValueMap cannot implement 
> remove(java.lang.Object,java.lang.Object) in java.util.Map
>   return type java.lang.Object is not compatible with boolean
> [ERROR] 
> /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiKeyMap.java:[200,19]
>  remove(java.lang.Object,java.lang.Object) in 
> org.apache.commons.collections.map.MultiKeyMap cannot implement 
> remove(java.lang.Object,java.lang.Object) in java.util.Map
>   return type java.lang.Object is not compatible with boolean
> [INFO] 4 errors 
> [INFO] -
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 19.104 s
> [INFO] Finished at: 2016-04-26T12:35:24-04:00
> [INFO] Final Memory: 19M/203M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile) 
> on project commons-collections: Compilation failure: Compilation failure:
> [ERROR] 
> /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiHashMap.java:[334,19]
>  remove(java.lang.Object,java.lang.Object) in 
> org.apache.commons.collections.MultiHashMap cannot implement 
> remove(java.lang.Object,java.lang.Object) in java.util.Map
> [ERROR] return type java.lang.Object is not compatible with boolean
> [ERROR] 
> /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiMap.java:[69,19]
>  remove(java.lang.Object,java.lang.Object) in 
> org.apache.commons.collections.MultiMap clashes with 
> remove(java.lang.Object,java.lang.Object) in java.util.Map
> [ERROR] return type java.lang.Object is not compatible with boolean
> [ERROR] 
> /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiValueMap.java:[156,19]
>  remove(java.lang.Object,java.lang.Object) in 
> org.apache.commons.collections.map.MultiValueMap cannot implement 
> remove(java.lang.Object,java.lang.Object) in java.util.Map
> [ERROR] return type java.lang.Object is not compatible with boolean
> [ERROR] 
> /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiKeyMap.java:[200,19]
>  

[jira] [Commented] (MATH-1314) RNG: Warn users about "seeding"

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15146642#comment-15146642
 ] 

Thomas Neidhart commented on MATH-1314:
---

just ftr: the table in the package javadoc measures generation rates, i.e. 
lower rates indicate that the generator is slower.

> RNG: Warn users about "seeding"
> ---
>
> Key: MATH-1314
> URL: https://issues.apache.org/jira/browse/MATH-1314
> Project: Commons Math
>  Issue Type: Wish
>Reporter: Gilles
>  Labels: doc
> Fix For: 4.0
>
>
> The "package-info.java" file of {{o.a.c.m.random}} does not mention the 
> problem of seeding.
> Many users of CM could not be aware that it is not sufficient to "randomly" 
> choose a seed in order to ensure a random sequence.
> I think that this is what is illustrated by random failures of some unit 
> tests (when the seed is "randomly" selected).
> Do the intricate initialization procedures provided in some implementations 
> (WELL family and ISAAC) ensure that all seeds are good enough?
> Should we provide some tool to test a seed?
> By the way, the WELL performances listed on [this 
> table|http://commons.apache.org/proper/commons-math/javadocs/api-3.6/org/apache/commons/math3/random/package-summary.html]
>  do not correspond to the results obtained on my machine with our 
> {{PerfTestUtils}} benchmark: the {{MersenneTwister}} is invariably faster 
> than all WELL implementations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MATH-1322) Negative integer seed for MersenneTwister is not working.

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139829#comment-15139829
 ] 

Thomas Neidhart commented on MATH-1322:
---

+1 for the patch. It does the same as the stdc++11 impl, boost and the original 
c version of Mersenne Twister.

> Negative integer seed for MersenneTwister is not working.
> -
>
> Key: MATH-1322
> URL: https://issues.apache.org/jira/browse/MATH-1322
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.6
>Reporter: Morikawa Joe
>  Labels: patch
> Attachments: MersenneTwister.patch
>
>
> MersenneTwister.setSeed(int seed) has a bug.
> If seed is negative, longMT also becomes negative.
> First 32 bits are filled by 0x.
> But it should be positive. First 32 bits should be filled by 0x.
> Ex) Integer -1 is 0x. 
> Long -1 is 0x.
> Long 0x is 4294967295.
> I created simple patch. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MATH-1315) MultiKMeansPlusPlusClusterer buggy for alternative evaluators

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15091184#comment-15091184
 ] 

Thomas Neidhart commented on MATH-1315:
---

Indeed, you are right this has to be fixed.

> MultiKMeansPlusPlusClusterer buggy for alternative evaluators
> -
>
> Key: MATH-1315
> URL: https://issues.apache.org/jira/browse/MATH-1315
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Thorsten Schäfer
>
> I just looked into the source code for the MultiKMeansPlusPlusClusterer and 
> realized that it would return null in case of an alternative evaluator that 
> favors bigger values instead of smaller ones:
> The basic idea of the clustering method is that we perform n clusterings and 
> choose the best result. The decision what's the best result is performed by 
> the evaluator, which by default assumes smaller values are better. 
> According to the documentation, we can also provide a different evaluator, 
> which for instance would decide that bigger values are better, but given we 
> initialize the best value with Double.POSITIVE_INFINITY in method 
> MultiKMeansPlusPlusClusterer.cluster(Collection), we would never find a 
> "better" result and thus always return null. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MATH-1171) clustering implementations have unnecessary overhead

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073100#comment-15073100
 ] 

Thomas Neidhart commented on MATH-1171:
---

In commit f0943a724, I have added an example for the userguide how to cluster 
images with the current API.

I did some first experiments to improve the API with a Dataset interface that 
provides access to all elements to cluster without the need to create explicit 
Clusterable instances.

In order to make the case of image clustering efficient, it would require some 
more refactoring to avoid unneeded allocations of double arrays (as usually an 
image is a large array or its pixels / samples). The distance API currently 
only works with arrays without offset / length arguments, thus for each pixel a 
separate array must be created, which is more or less the same as creating a 
Clusterable.

Changing the API to support distance calculations in arrays with offsets / 
length parameters would allow to create a Dataset that directly operates on the 
image data without creating intermediate objects. This might be beneficial for 
other use-cases as well.

> clustering implementations have unnecessary overhead
> 
>
> Key: MATH-1171
> URL: https://issues.apache.org/jira/browse/MATH-1171
> Project: Commons Math
>  Issue Type: Bug
>Reporter: Mark
>
> I want to apply clustering algorithms like KMeansPlusPlusClusterer to 
> pictures. And creating a point instance for each pixel is not a good idea.
> Therefore the interface should not be based on Collections, but on some 
> interface that provides sort of "get(index)" accessors to data that is 
> potentially stored in a pixel array etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MATH-1171) clustering implementations have unnecessary overhead

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MATH-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart updated MATH-1171:
--
Attachment: image_clustering_example.png

Attached a screenshot of the image clustering example.

> clustering implementations have unnecessary overhead
> 
>
> Key: MATH-1171
> URL: https://issues.apache.org/jira/browse/MATH-1171
> Project: Commons Math
>  Issue Type: Bug
>Reporter: Mark
> Attachments: image_clustering_example.png
>
>
> I want to apply clustering algorithms like KMeansPlusPlusClusterer to 
> pictures. And creating a point instance for each pixel is not a good idea.
> Therefore the interface should not be based on Collections, but on some 
> interface that provides sort of "get(index)" accessors to data that is 
> potentially stored in a pixel array etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MATH-1305) Improve performance of nextBytes() method of BitsStreamGenerator and AbstractRandomGenerator

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066167#comment-15066167
 ] 

Thomas Neidhart commented on MATH-1305:
---

There is no need to use ">>>" instead of ">>" in this case. It would only 
create confusion why it had been introduced here.

> Improve performance of nextBytes() method of BitsStreamGenerator and 
> AbstractRandomGenerator 
> -
>
> Key: MATH-1305
> URL: https://issues.apache.org/jira/browse/MATH-1305
> Project: Commons Math
>  Issue Type: Improvement
>Affects Versions: 4.0, 3.5, 3.6
>Reporter: Rostislav Krasny
>
> I propose to use this code in {{BitsStreamGenerator}}
> {code:java}
>   @Override
>   public void nextBytes(byte[] bytes) {
>   int index = 0;
>   // multiple 4 part of length, i.e. length with two least 
> significant bits unset
>   int max = bytes.length & 0x7ffc;
>   // start filling the byte array with tetrads of bytes
>   while (index < max) {
>   int random = next(32);
>   bytes[index++] = (byte) random;
>   bytes[index++] = (byte) (random >>> 8);
>   bytes[index++] = (byte) (random >>> 16);
>   bytes[index++] = (byte) (random >>> 24);
>   }
>   // fill the remains bytes
>   if (index < bytes.length) {
>   int random = next(32);
>   while (true) {
>   bytes[index++] = (byte) random;
>   if (index < bytes.length) {
>   random >>>= 8;
>   } else {
>   break;
>   }
>   }
>   }
>   }
> {code}
> I also propose to use the same code but with {{nextInt()}} calls instead of 
> {{next(32)}} in the {{AbstractRandomGenerator}}. This implementation improves 
> performance and fixes inconsistency bugs in those two classes discussed in 
> the MATH-1300. It is also quite simple and well commented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MATH-1300) BitsStreamGenerator#nextBytes(byte[]) is wrong

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065695#comment-15065695
 ] 

Thomas Neidhart commented on MATH-1300:
---

The Random class does not guarantee that for any chunk size the same sequence 
is generated. In fact it always gets the next 32 bits and uses as much as 
needed.

This means that for chunk sizes that are not multiples of 4, the test from 
Gilles will also fail.

I do see a problem in the nextBytes implementation in BitStreamGenerator, as 
there are unnecessary calls to next(int) in case the chunk size is a multiple 
of 4. I think the proposed patches could be further improved into something 
like that:

{code}
public void nextBytes(byte[] bytes) {
final int len = bytes.length;
for (int i = 0; i < len;) {
int random = nextInt();
int n = Math.min(len - i, 4);
while (n-- > 0) {
bytes[i++] = (byte) random;
random >>= 8;
}
}
}
{code}

> BitsStreamGenerator#nextBytes(byte[]) is wrong
> --
>
> Key: MATH-1300
> URL: https://issues.apache.org/jira/browse/MATH-1300
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Rostislav Krasny
> Attachments: MersenneTwister2.java, TestMersenneTwister.java
>
>
> Sequential calls to the BitsStreamGenerator#nextBytes(byte[]) must generate 
> the same sequence of bytes, no matter by chunks of which size it was divided. 
> This is also how java.util.Random#nextBytes(byte[]) works.
> When nextBytes(byte[]) is called with a bytes array of length multiple of 4 
> it makes one unneeded call to next(int) method. This is wrong and produces an 
> inconsistent behavior of classes like MersenneTwister.
> I made a new implementation of the BitsStreamGenerator#nextBytes(byte[]) see 
> attached code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VFS-228) Ant regression with ClassNotFoundException for DefaultLocalFileProvider

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15056646#comment-15056646
 ] 

Thomas Neidhart commented on VFS-228:
-

It is at least not reproducible anymore, so I would suggest to close it.

> Ant regression with ClassNotFoundException for DefaultLocalFileProvider
> ---
>
> Key: VFS-228
> URL: https://issues.apache.org/jira/browse/VFS-228
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: java version "1.6.0_0"
> IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12)
> OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing)
> Apache Ant version 1.7.1 compiled on October 3 2008
>Reporter: Per Hermansson
>Priority: Critical
> Attachments: patch, test.xml, vfs-task.diff
>
>
> The latest version from trunk fails to work with Apache Ant resulting in this 
> error:
> Could not load VFS configuration from 
> "jar:file:/media/Fort/per/program/backup/lib/commons-vfs-2.0-SNAPSHOT.jar!/org/apache/commons/vfs/impl/providers.xml".
> which was caused by 
> java.lang.ClassNotFoundException: 
> org.apache.commons.vfs.provider.local.DefaultLocalFileProvider 
> The cause seems to be a class loader issued introduced in rev 537717.
> Reverting that change:
> cd core
> svn diff -c r537717 
> src/main/java/org/apache/commons/vfs/impl/StandardFileSystemManager.java | 
> patch -R
> mvn clean install
> [copy commons-vfs-2.0-SNAPSHOT to my test's lib dir]
> ant -f test.xml test
> Makes my example ant file work again (worked with the 1.0 release).
> The 537717 revision was intended to fix 
> VFS-136: Don't force-set the classloader - Thanks to Adam Heath for the patch
> So it might be a bit controversial to reverse that change.
> Attaching patch fixing the issue and my example ant file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COLLECTIONS-584) Deserializing an AbstractHashedMap expands the hash table exponentially

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15056640#comment-15056640
 ] 

Thomas Neidhart commented on COLLECTIONS-584:
-

The AbstractHashedMap class is not serializable. Could you please provide a 
test case illustrating the problem you are facing?

> Deserializing an AbstractHashedMap expands the hash table exponentially
> ---
>
> Key: COLLECTIONS-584
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-584
> Project: Commons Collections
>  Issue Type: Bug
>Affects Versions: 4.1
>Reporter: Diogo Sousa
>
> When deserializing an {{AbstractHashedMap}} the size of the hashtable will be 
> doubled at each element inserted because {{threshold}} = 0, so this
> {code}
> protected void checkCapacity() {
> if(this.size >= this.threshold) {
> int newCapacity = this.data.length * 2;
> if(newCapacity <= 1073741824) {
> this.ensureCapacity(newCapacity);
> }
> }
> }
> {code}
> will always expand the hashtable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COLLECTIONS-584) Deserializing an AbstractHashedMap expands the hash table exponentially

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15056651#comment-15056651
 ] 

Thomas Neidhart commented on COLLECTIONS-584:
-

the load factor is a *parameter* provided to the AbstractHashedMap. If you see 
a value like this, your de-serialization code in the derived class is broken.

> Deserializing an AbstractHashedMap expands the hash table exponentially
> ---
>
> Key: COLLECTIONS-584
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-584
> Project: Commons Collections
>  Issue Type: Bug
>Affects Versions: 4.1
>Reporter: Diogo Sousa
>
> When deserializing an {{AbstractHashedMap}} the size of the hashtable will be 
> doubled at each element inserted because {{threshold}} = 0, so this
> {code}
> protected void checkCapacity() {
> if(this.size >= this.threshold) {
> int newCapacity = this.data.length * 2;
> if(newCapacity <= 1073741824) {
> this.ensureCapacity(newCapacity);
> }
> }
> }
> {code}
> will always expand the hashtable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (COLLECTIONS-584) Deserializing an AbstractHashedMap expands the hash table exponentially

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved COLLECTIONS-584.
-
Resolution: Invalid

The threshold is a transient field that is either provided or calculated from 
the intialCapacity. Concrete implementations of AbstractHashedMap are required 
to create a proper instance during de-serialization.

> Deserializing an AbstractHashedMap expands the hash table exponentially
> ---
>
> Key: COLLECTIONS-584
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-584
> Project: Commons Collections
>  Issue Type: Bug
>Affects Versions: 4.1
>Reporter: Diogo Sousa
>
> When deserializing an {{AbstractHashedMap}} the size of the hashtable will be 
> doubled at each element inserted because {{threshold}} = 0, so this
> {code}
> protected void checkCapacity() {
> if(this.size >= this.threshold) {
> int newCapacity = this.data.length * 2;
> if(newCapacity <= 1073741824) {
> this.ensureCapacity(newCapacity);
> }
> }
> }
> {code}
> will always expand the hashtable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VFS-228) Ant regression with ClassNotFoundException for DefaultLocalFileProvider

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15053656#comment-15053656
 ] 

Thomas Neidhart commented on VFS-228:
-

The provided testcase works for me when changing the task uri to 
org.apache.commons.vfs2.tasks.

> Ant regression with ClassNotFoundException for DefaultLocalFileProvider
> ---
>
> Key: VFS-228
> URL: https://issues.apache.org/jira/browse/VFS-228
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: java version "1.6.0_0"
> IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12)
> OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing)
> Apache Ant version 1.7.1 compiled on October 3 2008
>Reporter: Per Hermansson
>Priority: Critical
> Attachments: patch, test.xml, vfs-task.diff
>
>
> The latest version from trunk fails to work with Apache Ant resulting in this 
> error:
> Could not load VFS configuration from 
> "jar:file:/media/Fort/per/program/backup/lib/commons-vfs-2.0-SNAPSHOT.jar!/org/apache/commons/vfs/impl/providers.xml".
> which was caused by 
> java.lang.ClassNotFoundException: 
> org.apache.commons.vfs.provider.local.DefaultLocalFileProvider 
> The cause seems to be a class loader issued introduced in rev 537717.
> Reverting that change:
> cd core
> svn diff -c r537717 
> src/main/java/org/apache/commons/vfs/impl/StandardFileSystemManager.java | 
> patch -R
> mvn clean install
> [copy commons-vfs-2.0-SNAPSHOT to my test's lib dir]
> ant -f test.xml test
> Makes my example ant file work again (worked with the 1.0 release).
> The 537717 revision was intended to fix 
> VFS-136: Don't force-set the classloader - Thanks to Adam Heath for the patch
> So it might be a bit controversial to reverse that change.
> Attaching patch fixing the issue and my example ant file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VFS-393) The ls command allways returns the cached data

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15053682#comment-15053682
 ] 

Thomas Neidhart commented on VFS-393:
-

This can indeed happen as the list of children are cached for a LocalFile 
implementation. A simple testcase illustrating the issue can be seen below:

{code}
// Locate file by absolute file name
final String fileName = new File("testdir").getAbsolutePath();
final FileSystemManager mgr = VFS.getManager();
final FileObject dir = mgr.resolveFile(fileName);

dir.createFolder();

FileObject child = dir.resolveFile("abc");
child.createFile();

System.out.println("first");
FileObject[] children = dir.getChildren();
for (FileObject c : children) {
System.out.println(c.getName());
}

new File("testdir/abc").delete();
//child.delete();

System.out.println("again");
children = dir.getChildren();
for (FileObject c : children) {
System.out.println(c.getName());
}
{code}

in this case, the created file "testdir/abc" is deleted again via the standard 
java API, thus the VFS object does not get noticed about the change and returns 
the cached list of children.

Now this can happen also when the file is removed from the filesystem by other 
means, so in this case you can do two things:

 * use a file monitor to listen for changes in the directory
 * release the cache resource of the file object before accessing the list of 
children via file.close()

> The ls command allways returns the cached data
> --
>
> Key: VFS-393
> URL: https://issues.apache.org/jira/browse/VFS-393
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Red hat Linux
>Reporter: Prasad Kulkarni
>Priority: Minor
>  Labels: patch
>
> We have follwed the below steps to reproduce the issue
> 1. Created a folder under /home/xyz with name abc
> 2. Tried to get the Childrens of /home/xyz
> 3. I have got the folder listed as 'abc' although there are few other 
> childrens which are not considered and listed
> 4. Deleted the folder 'abc'
> 5. Tried to get the Childrens of /home/xyz
> 6. It is still listing the folder 'abc'
> We have also tried all three possible cache strategy but no luck.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (VFS-143) Fix memory leak in DelegateFileObject in it's handling of listeners

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VFS-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved VFS-143.
-
   Resolution: Implemented
Fix Version/s: 2.0

This has already been implemented in the 2.0 release.

> Fix memory leak in DelegateFileObject in it's handling of listeners
> ---
>
> Key: VFS-143
> URL: https://issues.apache.org/jira/browse/VFS-143
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Adam Heath
> Fix For: 2.0
>
> Attachments: fix_DelegateFile-listener-leak.patch
>
>
> DelegateFileObject adds itself as a listener to the wrapped file.  This adds 
> a *hard* reference to the DelegateFileObject, which prevents it from being 
> garbaged collected.  So, create a WeakRefFileListener proxy, to solve the 
> problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VFS-569) DefaultFileMonitor recursive file

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15053611#comment-15053611
 ] 

Thomas Neidhart commented on VFS-569:
-

Direct children of a directory are always added, regardless of the recursive 
flag, which seems to be intended behavior as it is also described like that in 
the code. So I would suggest to only update the documentation to clarify this.

> DefaultFileMonitor recursive file
> -
>
> Key: VFS-569
> URL: https://issues.apache.org/jira/browse/VFS-569
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Java 7, windows 8, eclipse lune
>Reporter: Sante
> Attachments: VFS-569.patch
>
>
> FileSystemManager fsManager = VFS.getManager();
>   FileObject fileObj = 
> fsManager.resolveFile("file:///MyFolder");
> DefaultFileMonitor fm = new DefaultFileMonitor(listener);
> fm.setDelay(1);
> fm.setRecursive(false);
> fm.addFile(fileObj);
> fm.start();
> when execute fm.addFile(fileObj); library add listener an internal forder 
> although not recursive.
> in this point:
> if (file.getType().hasChildren()){
> // Traverse the children
> final FileObject[] children = file.getChildren();
> for (final FileObject element : children) {
> doAddFile(element);
> }
> }
> variable children: should be a file and not a folder!!!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (VFS-393) The ls command allways returns the cached data

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15053682#comment-15053682
 ] 

Thomas Neidhart edited comment on VFS-393 at 12/11/15 11:15 PM:


This can indeed happen as the list of children are cached for a LocalFile 
implementation. A simple testcase illustrating the issue can be seen below:

{code}
// Locate file by absolute file name
final String fileName = new File("testdir").getAbsolutePath();
final FileSystemManager mgr = VFS.getManager();
final FileObject dir = mgr.resolveFile(fileName);

dir.createFolder();

FileObject child = dir.resolveFile("abc");
child.createFile();

System.out.println("first");
FileObject[] children = dir.getChildren();
for (FileObject c : children) {
System.out.println(c.getName());
}

new File("testdir/abc").delete();
//child.delete();

System.out.println("again");
children = dir.getChildren();
for (FileObject c : children) {
System.out.println(c.getName());
}
{code}

in this case, the created file "testdir/abc" is deleted again via the standard 
java API, thus the VFS object does not get noticed about the change and returns 
the cached list of children.

Now this can happen also when the file is removed from the filesystem by other 
means, so in this case you can do two things:

 * use a file monitor to listen for changes in the directory
 * call refresh() on the file object


was (Author: tn):
This can indeed happen as the list of children are cached for a LocalFile 
implementation. A simple testcase illustrating the issue can be seen below:

{code}
// Locate file by absolute file name
final String fileName = new File("testdir").getAbsolutePath();
final FileSystemManager mgr = VFS.getManager();
final FileObject dir = mgr.resolveFile(fileName);

dir.createFolder();

FileObject child = dir.resolveFile("abc");
child.createFile();

System.out.println("first");
FileObject[] children = dir.getChildren();
for (FileObject c : children) {
System.out.println(c.getName());
}

new File("testdir/abc").delete();
//child.delete();

System.out.println("again");
children = dir.getChildren();
for (FileObject c : children) {
System.out.println(c.getName());
}
{code}

in this case, the created file "testdir/abc" is deleted again via the standard 
java API, thus the VFS object does not get noticed about the change and returns 
the cached list of children.

Now this can happen also when the file is removed from the filesystem by other 
means, so in this case you can do two things:

 * use a file monitor to listen for changes in the directory
 * release the cache resource of the file object before accessing the list of 
children via file.close()

> The ls command allways returns the cached data
> --
>
> Key: VFS-393
> URL: https://issues.apache.org/jira/browse/VFS-393
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Red hat Linux
>Reporter: Prasad Kulkarni
>Priority: Minor
>  Labels: patch
>
> We have follwed the below steps to reproduce the issue
> 1. Created a folder under /home/xyz with name abc
> 2. Tried to get the Childrens of /home/xyz
> 3. I have got the folder listed as 'abc' although there are few other 
> childrens which are not considered and listed
> 4. Deleted the folder 'abc'
> 5. Tried to get the Childrens of /home/xyz
> 6. It is still listing the folder 'abc'
> We have also tried all three possible cache strategy but no luck.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VFS-512) LRUFilesCache grows arbitrarly

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15053563#comment-15053563
 ] 

Thomas Neidhart commented on VFS-512:
-

The LRUFilesCache does not release files that are attached.

Now, basically any operation on a File object makes it attached, which is a 
pain.

Changing your test code to this will prevent the cache from growing:

{code}
public static void visitDirs(FileObject dir) throws FileSystemException {
// System.out.println(MemoryMeasurer.measureBytes(lruCache));
FileObject[] files = dir.getChildren();
dir.close();
count += files.length;
for (FileObject f : files) {
if (f.getType() == FileType.FOLDER) {
try {
visitDirs(f);
} catch (FileSystemException e) {
e.printStackTrace();
}
}
f.close();
}
}
{code}

But I think the LRUFileCache should be change to allow also attached files to 
be removed from the cache. Maybe by first checking if there are any other files 
to be removed that are not attached.

> LRUFilesCache grows arbitrarly
> --
>
> Key: VFS-512
> URL: https://issues.apache.org/jira/browse/VFS-512
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Bela Hullar
>  Labels: leak
>
> We are experiencing memory issues in our system where we have to scan very 
> big directories. After doing some investigation it turned out that the cause 
> of the issue is the caching of vfs. 
> (http://mail-archives.apache.org/mod_mbox/commons-user/201312.mbox/browser)
> From this reason we tried out LRUFilesCache, but it seems this cache can 
> still grow way beyond the limit. 
> This can be reproduced with a simple test code:
> https://sourceforge.net/p/screeningbee/code/HEAD/tree/trunk/vfs-cache-test/src/main/java/ch/systemsx/bee/vfscachetest/CacheSizeChecker.java
> In this example we set the max size of lru to 100, but running a while this 
> example and then checking the heap of the program showed that the real size 
> of the map can be 10 000 or more too. And it seems its growing constantly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1077) [PATCH] StringUtils.ordinalIndexOf("aaaaaa", "aa", 2) != 3 in StringUtils

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15053437#comment-15053437
 ] 

Thomas Neidhart commented on LANG-1077:
---

This code exists since a long time and looking at the implementation it is 
clear what it does and what its intention is: repeatedly execute indexOf with a 
start index of +1 compared to the last match. There are even suggestions on 
stackoverflow to use this method for exactly that use-case.

What you are facing is a corner-case that was not described in the javadoc and 
thus it might create confusion for a user. So the right thing to do is what 
sebb did: revert the fix to the previous, working version and update the 
javadoc to document the corner case. Contrary to your opinion that this might 
introduce bugs, it is quite the opposite, your fix will introduce bugs as 
people relied on the previous version for a long time already.

If there is a need for a method that does not handle overlaps, then this should 
be a new feature request. The method could have an additional flag to indicate 
how it handles overlaps.

> [PATCH] StringUtils.ordinalIndexOf("aa", "aa", 2)  != 3 in StringUtils
> --
>
> Key: LANG-1077
> URL: https://issues.apache.org/jira/browse/LANG-1077
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>  Labels: patch
> Attachments: LANG-1077.patch
>
>
> {code:title= org.apache.commons.lang3.StringUtils.java|borderStyle=solid}
> int found = 0;
> int index = lastIndex ? str.length() : INDEX_NOT_FOUND;
> do {
> if (lastIndex) {
> index = CharSequenceUtils.lastIndexOf(str, searchStr, index - 
> 1);
> } else {
> index = CharSequenceUtils.indexOf(str, searchStr, index + 1);
> }
> if (index < 0) {
> return index;
> }
> found++;
> } while (found < ordinal);
> {code}
> Should it be:
> {code:title= org.apache.commons.lang3.StringUtils.java|borderStyle=solid}
> private static int ordinalIndexOf(final CharSequence str, final 
> CharSequence searchStr, final int ordinal, final boolean lastIndex) {
> //if (str == null || searchStr == null || ordinal <= 0) {
> //return INDEX_NOT_FOUND;
> //}
> //if (searchStr.length() == 0) {
> //return lastIndex ? str.length() : 0;
> //}
> //int found = 0;
> //int index = lastIndex ? str.length() : INDEX_NOT_FOUND;
> //do {
> //if (lastIndex) {
> //index = CharSequenceUtils.lastIndexOf(str, 
> searchStr, index - 1);
> //} else {
> //index = CharSequenceUtils.indexOf(str, searchStr, 
> index + 1);
> //}
> //if (index < 0) {
> //return index;
> //}
> //found++;
> //} while (found < ordinal);
> //return index;
> if (str == null || searchStr == null || ordinal <= 0) {
> return INDEX_NOT_FOUND;
> }
> if (searchStr.length() == 0) {
> return lastIndex ? str.length() : 0;
> }
> final int searchStrLen = searchStr.length();
> int index = lastIndex ? str.length() : 0;
> for (int found = 0; index >= 0;) {
> if (lastIndex) {
> index = CharSequenceUtils.lastIndexOf(str, searchStr, index);
> } else {
> index = CharSequenceUtils.indexOf(str, searchStr, index);
> }
> if (index < 0) {
> return INDEX_NOT_FOUND;
> }
> if (++found >= ordinal) {
> break;
> }
> index = lastIndex ? index - searchStrLen : index + searchStrLen;
> }
> return index;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15046545#comment-15046545
 ] 

Thomas Neidhart commented on COLLECTIONS-580:
-

The collections 2.x branch is not affected.

@all the issue tracker is no discussion forum, please use the user/dev 
mailinglist for questions. Furthermore this issue is closed, I will not answer 
anything here anymore.

> 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] [Resolved] (EMAIL-157) Sending an email from a Java TimerTask object doesn't work

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/EMAIL-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved EMAIL-157.
---
Resolution: Cannot Reproduce

> Sending an email from a Java TimerTask object doesn't work
> --
>
> Key: EMAIL-157
> URL: https://issues.apache.org/jira/browse/EMAIL-157
> Project: Commons Email
>  Issue Type: Bug
>Affects Versions: 1.4
> Environment: OS: Windows 8.1 Pro / IDE: Eclipse Juno / Servlets 
> container: Tomcat 8
>Reporter: LEA MASSIOT
>
> Hello,
> I'm using "Apache Commons Email 1.4".
> Consider the following simple code:
> {code}
> import org.apache.commons.mail.Email;
> import org.apache.commons.mail.EmailException;
> import org.apache.commons.mail.SimpleEmail;
> [...]
> Email email = new SimpleEmail();
> email.setHostName("smtp.foo.bar");
> try
> {
> email.setFrom("f...@bar2.fr");
> email.setSubject("TestMail");
> email.setMsg("This is a test mail ... :-)");
> email.addTo("f...@bar3.fr");
> email.send();
> }
> catch(EmailException e)
> {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> {code}
> The code above is put:
> - CASE 1: in the *doPost()* method of a *HttpServlet* object: it works (I 
> receive the email).
> - CASE 2: at runtime (there are no build errors), in the *run()* method of a 
> *TimerTask* object:  
>   If I put a breakpoint on the line *Email email = new SimpleEmail();*
>   hit F6 in Eclipse to execute the instruction,
>   I get the message: Source not found.
> What am I doing wrong? What is going wrong? How can I make it work?
> Best regards.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MATH-1169) Faster Percentile

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15038673#comment-15038673
 ] 

Thomas Neidhart commented on MATH-1169:
---

The advantage of the current implementation is that the pivots are cached, thus 
sub-sequent calls will be faster. In your benchmark you select new values for 
each iteration, which renders the pivot cache useless.

We could try adding the FloydRivest selection as an extension of the current 
KthSelector implementation, and a user can select which selector to use via the 
withKthSelector method in Percentile.

> Faster Percentile
> -
>
> Key: MATH-1169
> URL: https://issues.apache.org/jira/browse/MATH-1169
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Adam Stelmaszczyk
>Priority: Minor
> Attachments: FloydRivest.java, Main.java, PercentileFloydRivest.java
>
>
> Percentile class is now using Hoare selection algorithm (aka 
> [Quickselect|http://en.wikipedia.org/wiki/Quickselect]) with median of 3 for 
> choosing a pivot and caching pivots. Quickselect expected runtime is about 
> 3.4N + O(N).
> The constant can be improved to 1.5N by different pivot strategy involving 
> sampling, yielding the [Floyd–Rivest 
> algorithm|http://en.wikipedia.org/wiki/Floyd%E2%80%93Rivest_algorithm], which 
> has average complexity of 1.5N + O(N) for median, with other position 
> statistics even faster.
> For proof of concept I implemented Floyd–Rivest algorithm without caching 
> pivots following Wikipedia and benchmarked it with 
> [Caliper|https://code.google.com/p/caliper/].
> Array size - runtime for Floyd-Rivest - runtime for current Percentile - % 
> faster
> 10 - 6.907 - 7.083 - 2.5% 
> [link|https://microbenchmarks.appspot.com/runs/a0d947ee-57fc-4636-b687-b4bc5170f1d7#r:scenario.benchmarkSpec.methodName]
> 100 - 70.3 - 75.4 - 6.8% 
> [link|https://microbenchmarks.appspot.com/runs/77291c2e-6dbb-4666-bf37-c174e4b53f2e#r:scenario.benchmarkSpec.methodName]
> 1000 - 708 - 868 - 18.4% 
> [link|https://microbenchmarks.appspot.com/runs/c0f65e35-44c0-458e-b6e0-634b4e6fa68b#r:scenario.benchmarkSpec.methodName]
> In attachments:
> {{Main.java}} should be run to repeat experiments, it needs Caliper JAR: 
> https://code.google.com/p/caliper/downloads/detail?name=caliper-1.0-beta-1-all.jar
> Every call to evaluate() I'm filling the input double[] array with different 
> random numbers.
> {{FloydRivest.java}} contatins implementation of algorithm basing on 
> pseudocode from its Wikipedia page.
> {{PercentileFloydRivest.java}} is Percentile.java with modified evaluate(), 
> so it calls FloydRivest.select() instead of typical select(). pivotsHeap was 
> removed for simplicity (maybe it can improve efficiency even more).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MATH-729) Add an implementation for Holt-Winters triple exponential smoothing

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MATH-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved MATH-729.
--
Resolution: Won't Fix

Closing as this does not really fit into CM as pointed out by Gilles.

> Add an implementation for Holt-Winters triple exponential smoothing
> ---
>
> Key: MATH-729
> URL: https://issues.apache.org/jira/browse/MATH-729
> Project: Commons Math
>  Issue Type: New Feature
>Reporter: Nishant Chandra
>Priority: Minor
>  Labels: exponential, smoothing, triple
>
> Add an implementation for Holt-Winters triple exponential smoothing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MATH-287) Add support for weighted descriptive statistics

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MATH-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved MATH-287.
--
Resolution: Implemented

Weighted statistics have been implemented a long time ago.

Further changes should be reported/handled in a separate ticket.

> Add support for weighted descriptive statistics
> ---
>
> Key: MATH-287
> URL: https://issues.apache.org/jira/browse/MATH-287
> Project: Commons Math
>  Issue Type: New Feature
>Affects Versions: 2.0
>Reporter: Matthew Rowles
>Priority: Minor
> Attachments: weightTests.patch, weighted.patch
>
>
> Add support for weighted descriptive statistics, such as weighted variance.
> An example method call would be Variance.evaluate(double[] values, double[] 
> weights, int begin, int length)
> - Suggested by  mickey...@taosnet.com on the mailing list.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MATH-643) Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and mapAddToSelf(...) to ebeAddToSelf(...) for instance

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MATH-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved MATH-643.
--
Resolution: Duplicate

Should be discussed/fixed as part of MATH-765

> Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and 
> mapAddToSelf(...) to ebeAddToSelf(...) for instance
> -
>
> Key: MATH-643
> URL: https://issues.apache.org/jira/browse/MATH-643
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Arne Plöse
>Priority: Minor
> Fix For: 4.0
>
>
> I think the map* methods have historical names. Today I would prefer ebe as 
> prefix like ebeMultiply(...).
> This would describe the methods better from a users view.
> If this is a valid issue, I could provide a patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MATH-608) Remove methods from RealMatrix Interface

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MATH-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved MATH-608.
--
   Resolution: Duplicate
Fix Version/s: (was: 4.0)

Should be discussed as part of MATH-765.

> Remove methods from RealMatrix Interface
> 
>
> Key: MATH-608
> URL: https://issues.apache.org/jira/browse/MATH-608
> Project: Commons Math
>  Issue Type: Improvement
>Affects Versions: 1.0, 1.1, 1.2, 2.0, 2.1, 2.2
> Environment: Java
>Reporter: greg sterijevski
>Priority: Minor
>  Labels: Matrices
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The RealMatrix interface describes several methods which take a RealMatrix 
> and yield a RealMatrix return. They are:
> RealMatrix multiply(RealMatrix m);
> RealMatrix preMultiply(RealMatrix m);
> RealMatrix power(final int p);
> RealMatrix add(RealMatrix m)
> RealMatrix subtract(RealMatrix m)
> There is nothing inherently wrong in making all subclasses of RealMatrix 
> implement these methods. However, as the number of subclasses of RealMatrix 
> increases, the complexity of these methods will also increase. I think these 
> methods should be part of a separate class of 'operators' which handle matrix 
> multiplication, addition, subtraction and exponentiation.
> Say for example, I implement SymmetricRealMatrix. I would like to store the 
> data of a real symmetric in compressed form, so that I only consume (nrow + 
> 1)*nrow /2 space in memory. When it comes time to implement multiply (for 
> example), I must test to see if the RealMatrix given in the argument is also 
> of Type SymmetricRealMatrix, since that will affect the algorithm I use to do 
> the multiplication. I could access each element of the argument matrix via 
> its getter, but efficiency will suffer. One can think of cases where we might 
> have a DiagonalRealMatrix times a DiagonRealMatrix. One would not want to 
> store the resultant diagonal in a general matrix storage. Keeping track of 
> all of the permutations of Symmetrics, Diagonals,..., and their resultants 
> inside of the body of a function makes for very brittle code. Furthermore, 
> anytime a new type of matrix is defined all matrix multiplication routines 
> would have to be updated.  
> There are special types of operations which result in particular matrix 
> patterns. A matrix times its transpose is itself a symmetric. A general 
> matrix sandwiched between another general matrix and its transpose is a 
> symmetric. Cholesky decompositions form upper and lower triangular matrices. 
> These are common enough occurrences in statistical techniques that it makes 
> sense to put them in their own class (perhaps as static methods). It would 
> keep the contract of the RealMatrix classes very simple. The ReaMatrix would 
> be nothing more than:
> 1. Marker (is the matrix General, Symmetric, Banded, Diagonal, 
> UpperTriangular..)
> 2. Opaque data store (except for the operator classes, no one would need to 
> know how the data is actually stored).
> 3. Indexing scheme. 
> The reason I bring this up, is that I am attempting to write a 
> SymmetricRealMatrix class to support variance-covariance matrices. I noticed 
> that there are relatively few subclasses of RealMatrix. While it would be 
> easy to hack it up for the handful of implementations that exist, that would 
> probably create more problems as the number of types of matrices increases.
> Thank you,
> -Greg 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COLLECTIONS-561) Add CollectionUtils#containsQuietly method

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15038579#comment-15038579
 ] 

Thomas Neidhart commented on COLLECTIONS-561:
-

I think the method is quite reasonable but I was unsure about the name.

> Add CollectionUtils#containsQuietly method
> --
>
> Key: COLLECTIONS-561
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-561
> Project: Commons Collections
>  Issue Type: New Feature
>Reporter: Thomas Neidhart
>
> Placeholder ticket for pull request: 
> https://github.com/apache/commons-collections/pull/10



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15035999#comment-15035999
 ] 

Thomas Neidhart commented on COLLECTIONS-580:
-

All 3.X releases and the 4.0 release are affected.

For the 3.X branch we have released 3.2.2 to which all users of the 3.X branch 
are encouraged to upgrade.
For the 4.X branch we have released 4.1 (same as above applies).

> 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-508) MultiMap's methods are not strongly typed even though the interface supports generics

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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-299) ExtendedProperties.convertProperties loses non-String values

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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-571) Deprecate CollectionUtils.{synchronized, unmodifiable}Collection methods

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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()

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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-562) Update minimum required java to 1.6

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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-539) CircularFifoQueue: make 'isAtFullCapacity' method public

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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-555) Undefined NullPointerException in TreeBag.java

[Thomas Neidhart (JIRA)]

 [ 
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<E, D> is not used

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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-395) Request for UnBoundedLRUMap implementation with extra get method

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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-540) Duplication of code in CollectionUtils

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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()

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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-557) LRUMap memory usage vs size

[Thomas Neidhart (JIRA)]

 [ 
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()

[Thomas Neidhart (JIRA)]

 [ 
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-521) Typo in MultiMapKey's isEqualKey(entry, key1, key2)

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Closed] (COLLECTIONS-582) Maven repository metadata of Commons Collections in bad condition

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart closed COLLECTIONS-582.
---

> Maven repository metadata of Commons Collections in bad condition
> -
>
> Key: COLLECTIONS-582
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-582
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.2.2
>Reporter: Alexander Veit
>
> The metadata located at
> https://repo1.maven.org/maven2/commons-collections/commons-collections/maven-metadata.xml
> are in a bad condition.
> It states that latest version and release version is 20040616. Moreover, the 
> list of versions does not reflect the actual release order.
> This makes it difficult to automatically check for new versions in our QA 
> processes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COLLECTIONS-581) Deserialization and Apache Commons Collection

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart closed COLLECTIONS-581.
---

> Deserialization and Apache Commons Collection
> -
>
> Key: COLLECTIONS-581
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-581
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Functor
>Affects Versions: 3.0, 3.1, 3.2.1
>Reporter: Deepesh
>Assignee: Mark Thomas
>  Labels: patch
>
> Hi Team,
> This is regarding “commons-collections Java library”. In our applications we 
> are widely using this library and hence looking to urgently patch the fix for 
> vulnerability issue if it is available.
> Searching on internet we found one patch released on Sunday 08th Nov 
> http://svn.apache.org/viewvc?view=revision=1713307
> Just wanted to check with you if there is any updated / complied version of 
> commons-collections jar available or going to be released soon which we can 
> directly replace with our existing jar file that provides the fix for the 
> vulnerability issue.
> Thanks in advance!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COLLECTIONS-165) Filtered Maps, Lists, and Sets

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart closed COLLECTIONS-165.
---

> Filtered Maps, Lists, and Sets
> --
>
> Key: COLLECTIONS-165
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-165
> Project: Commons Collections
>  Issue Type: New Feature
>  Components: List, Map, Set
>Affects Versions: 3.1
> Environment: Operating System: other
> Platform: Other
>Reporter: Venkatesh Prasad Ranganath
>Priority: Minor
> Attachments: ASF.LICENSE.NOT.GRANTED--FilteredCollection.java, 
> ASF.LICENSE.NOT.GRANTED--FilteredList.java, 
> ASF.LICENSE.NOT.GRANTED--FilteredListIterator.java, 
> ASF.LICENSE.NOT.GRANTED--FilteredMap.java, 
> ASF.LICENSE.NOT.GRANTED--FilteredSet.java
>
>
> In the project I work I have found that it would be efficient (at a small cost
> of memory) to use filtered maps, lists, and sets instead of creating a new 
> copy
> of the decorated entities that contains only the filtered elements.
> To begin with I have implemented a FilteredMap and plan to implement
> FilteredList and FilteredSet.  I will post the code for these in a couple of
> days and it would be great if Collections library could accept these 
> contributions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COLLECTIONS-402) Inconsistent Javadoc comment and code in intersection(List list1,List list2)in org.apache.commons.collections.ListUtils

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart closed COLLECTIONS-402.
---

> Inconsistent Javadoc comment and code in intersection(List list1,List 
> list2)in org.apache.commons.collections.ListUtils
> ---
>
> Key: COLLECTIONS-402
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-402
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection
>Affects Versions: 3.2.1
> Environment: Platform Independent 
>Reporter: SHIN HWEI TAN
>   Original Estimate: 0.05h
>  Remaining Estimate: 0.05h
>
> The Javadoc comment below states that the method "throws NullPointerException 
> if either list is null". 
>/*..
>* 
>* @throws NullPointerException if either list is null
>*/
>   public static List intersection(final List list1, final List list2)
>   ..
>   }
> However, when called with a null list1 and an empty list2(i.e., 
> "intersection((List)null, new ArrayList())"), the method executes normally 
> without throwing any exception.
> Suggested Fixes:
> 1. Add code "if (list1 == null) throw NullPointerException();" at the 
> beginning of the method body.
> or
> 2. Remove "@throws NullPointerException if either list is null" from the 
> Javadoc.
> or
> 3. Change "@throws NullPointerException if either list is null" to "@throws 
> NullPointerException if list2 is null or (the list2 is non-empty and the 
> list1 is null)".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COLLECTIONS-279) LRUMap: moveToMRU is not invoked for new entry

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart closed COLLECTIONS-279.
---

> LRUMap: moveToMRU is not invoked for new entry
> --
>
> Key: COLLECTIONS-279
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-279
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Map
>Affects Versions: 3.2
>Reporter: Andrey Andreev
>Priority: Blocker
> Attachments: AbstractLinkedMap.java.diff
>
>
>   @Test
>   public void testFirst() {
>   LRUMap map = new LRUMap();
>   String key = "key1";
>   String value = "value1";
>   map.put(key, value);
>   Assert.assertEquals(map.get(key), value);
>   Assert.assertEquals(map.get(map.firstKey()), value);
>   
>   key = "key2";
>   value = "value2";
>   map.put(key, value);
>   // here it fails
>   Assert.assertEquals(map.get(map.firstKey()), value);
>   }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COLLECTIONS-354) Add Collection utils from MINA: e.g. CopyOnWriteMap

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart closed COLLECTIONS-354.
---

> Add Collection utils from MINA: e.g. CopyOnWriteMap
> ---
>
> Key: COLLECTIONS-354
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-354
> Project: Commons Collections
>  Issue Type: New Feature
>  Components: Map
>Reporter: Sebb
>
> MINA has some useful Collection utilities, for example CopyOnWriteMap.
> http://svn.apache.org/repos/asf/mina/trunk/core/src/main/java/org/apache/mina/util/CopyOnWriteMap.java
> Several of the other utilities look useful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COLLECTIONS-403) Make AndPredicate, AnyPredicate etc. not final

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart closed COLLECTIONS-403.
---

> Make AndPredicate, AnyPredicate etc. not final
> --
>
> Key: COLLECTIONS-403
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-403
> Project: Commons Collections
>  Issue Type: Improvement
>  Components: Collection
>Affects Versions: 3.2.1
>Reporter: david cogen
>Priority: Minor
>
> If there is no good reason for these (and similar classes) to not be final, 
> they would be much more useful to me if they were not final.
> I have a class that I wanted to have an "is a" relation to AnyPredicate, but, 
> AnyPredicate being declared final, I cannot and instead have to design it 
> with a "has a" relation to AnyPredicate, which for my purpose is much less 
> clear.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart closed COLLECTIONS-527.
---

> Please create a version commons-collections 3.x for jdk 8 compatibility
> ---
>
> Key: COLLECTIONS-527
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
> Project: Commons Collections
>  Issue Type: Bug
>Reporter: Ignat Alexeyenko
>Priority: Blocker
>  Labels: java8, jdk8
> Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch
>
>
> Could you make a 3.x or 3.2.x release compatible with JDK8 ?
> {code}
> org.apache.commons.collections.MultiMap {
>public Object remove(Object key, Object item);
> }
> {code}
> is not compatible with JDK's 8 Map
> {code}
> java.util.Map {
>boolean remove(Object key, Object value);
> }
> {code}
> This causes bugs in projects, who run jdk8 and even compilation failures - 
> for these, who implement common's MultiMap.
> *Compilation Error*
> If anyone implement MultiMap in their code, compilation fails with the error:
> {code}
> MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap 
> cannot implement remove(Object,Object) in Map
> [ERROR] return type Object is not compatible with boolean
> {code}
> *Reasoning*
> JDK 8 is here and being adopted. collection-commons are not yet compatible 
> with Java 8. For many big project switch to commons-collections 4.x is not an 
> option - some transitional release version needs to be required.
> Alternative would be for companies to fork commons-collections and create 
> their internal artifact. Why do it if the official compatibility version can 
> be created?
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COLLECTIONS-374) Bug in class#BeanMap and TransformedBuffer with reproducible JUnit test

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart closed COLLECTIONS-374.
---

> Bug in class#BeanMap and TransformedBuffer with reproducible JUnit test
> ---
>
> Key: COLLECTIONS-374
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-374
> Project: Commons Collections
>  Issue Type: Bug
>Affects Versions: 3.2
> Environment: jdk 1.6.0
>Reporter: Sai Zhang
> Attachments: ApacheCommons_Documented_Test.java
>
>
> Hi all:
> (as in the previous post)
> 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. 
> The comment appears in the form of:
> //Tests pass if  (it gives some small change to the test which can make 
> the failed test pass)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COLLECTIONS-465) Add more static helper functions to IteratorUtils & CollectionUtils

[Thomas Neidhart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart closed COLLECTIONS-465.
---

> Add more static helper functions to IteratorUtils & CollectionUtils
> ---
>
> Key: COLLECTIONS-465
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-465
> Project: Commons Collections
>  Issue Type: Sub-task
>  Components: Iterator
>Reporter: Thomas Neidhart
> Fix For: 4.x
>
>
> The Iter class from the jena projects contains a lot of convenience methods 
> for iterators. We should implement the same in our IteratorUtils class.
> Also consider several methods in class Iterators from guava project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COLLECTIONS-443) Proposal for adding IndexedTreeMap to collections

[Thomas Neidhart (JIRA)]

 [ 
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

[Thomas Neidhart (JIRA)]

 [ 
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)