[jira] [Updated] (MATH-765) Refactoring the vector and matrix classes
[
https://issues.apache.org/jira/browse/MATH-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard updated MATH-765:
---
Description:
{panel:title=Warning|borderStyle=solid}
This is not a bug report, but rather a summary of all discussions which have
taken place on the mailing list regarding the refactoring of the vector and
matrix classes. Indeed, it has been argued many times that the {{RealVector}}
and {{RealMatrix}} interfaces are really cluttered, and could benefit from
other approaches (like functional programming).
The description of this ticket will be updated as the discussion progresses on
the mailing-list, and new JIRA tickets will be created to carry out the real
work. {color:red}In order to keep this ticket tidy, contributors should refrain
from commenting on this website. Instead, messages should be posted on the dev
mailing-list{color}.
{panel}
h1. The current API (version 3.0)
In this section, the current interfaces for vectors and matrices are compared.
Vectors and matrices are two mathematical objects which are very close in
nature. Their implementations should therefore be as similar as possible. The
methods will be sorted as follows
* methods reflecting the mathematical structure of vector space: addition,
multiplication by a scalar, matrix-vector product, ...
* methods reflecting the mathematical structure of euclidean space
* ...
h2. Methods reflecting the mathematical structure of vector space
h3. List of the methods
|| {{RealVector}}|| {{RealMatrix}}
|| Comments ||
| {{RealVector add(RealVector v)}} | {{RealMatrix add(RealMatrix m)}}
| |
| {{int getDimension()}} | {{int getRowDimension()}},\\
{{int getColumnDimension()}} | |
| {{RealVector mapMultiply(double d)}} | {{scalarMultiply(double d)}}
| (1) |
| {{RealVector mapMultiplyToSelf(double d)}} |
| |
| {{RealVector outerProduct(RealVector v)}} |
| |
|| {{double getTrace()}}
| |
|| {{multiply(RealMatrix m)}}
| |
|| {{double[] operate(double[])}}
| (2) |
|| {{RealVector
operate(RealVector)}}| |
|| {{RealMatrix power(int p)}}
| |
|| {{double[]
preMultiply(double[])}}| (2) |
|| {{RealMatrix
preMultiply(RealMatrix)}}| |
|| {{RealVector
preMultiply(RealVector)}}| |
|| {{RealMatrix transpose()}}
| |
h3. Comments on the above methods
h4. Comment (1)
{{RealVector RealVector.mapMultiply(double)}} and {{RealMatrix
RealMatrix.scalarMultiply(double)}} perform essentially the same task.
Readibility of the classes would be improved if they add the same name. This is
very important since these methods reflect the fact that the space of vectors
as well as the space of matrices are two vector spaces.
h4. Comment (2)
Prior to the release of version 3.0, all methods taking as argument, or
returning, {{double[]}} as a representation of vectors were removed. The
rationale for this is that calling {{new ArrayRealVector(double[], false)}} is
very easy, and comes at virtually no cost (see MATH-653 and MATH-660). It might
be worth considering the same simplification for the {{RealMatrix}} interface.
h2. Methods reflecting the mathematical structure of euclidean space
h3. List of the methods
|| {{RealVector}} || {{RealMatrix}} ||
Comments ||
| {{double cosine(RealVector v)}} | |
|
| {{double dotProduct(RealVector v)}} | | (3)
|
| {{double getDistance(RealVector v)}}| |
|
| {{double getNorm()}}| {{double getFrobeniusNorm()}} |
|
| {{RealVector projection(RealVector v)}} | |
|
| {{void unitize()}} | | (4)
|
| {{RealVector unitVector()}} | |
|
h3. Comments on
[jira] [Created] (MATH-769) Slow FFT
Slow FFT Key: MATH-769 URL: https://issues.apache.org/jira/browse/MATH-769 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Marc Madaule Priority: Minor Compared to JNTFFT, ACM's unidimensional FFT is slower. Benchmark and results coming soon. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCS-92) On shutdown .key (empty during runtime) not written and .data (not empty during runtime) deleted
[
https://issues.apache.org/jira/browse/JCS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228383#comment-13228383
]
Thomas Vandahl commented on JCS-92:
---
Did you do a
CompositeCacheManager.getInstance().shutDown();
?
On shutdown .key (empty during runtime) not written and .data (not empty
during runtime) deleted
Key: JCS-92
URL: https://issues.apache.org/jira/browse/JCS-92
Project: Commons JCS
Issue Type: Bug
Components: Composite Cache
Affects Versions: jcs-1.3
Environment: win 7x64; jvm 1.6
Reporter: Karl Klinge
On shutdown .key (which is empty during runtime) is not written from memory
and .data (not empty during runtime) is deleted.
cache ccf:
#
## Default Region Configuration
jcs.default=DC2
jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=50
jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
#
## CACHE REGIONS
jcs.region.sac=DC2
jcs.region.sac.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.region.sac.cacheattributes.MaxObjects=10
jcs.region.sac.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
jcs.region.sac.elementattributes.IsEternal=true
##jcs.region.sac.elementattributes.MaxLifeSeconds=172800 ## 2 Tage
jcs.region.sac.cacheattributes.DiskUsagePatternName=UPDATE
### AUXILIARY CACHES
# Indexed Disk Cache
jcs.auxiliary.DC2=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
jcs.auxiliary.DC2.attributes=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
jcs.auxiliary.DC2.attributes.DiskPath=c:/cache/status
jcs.auxiliary.DC2.attributes.MaxPurgatorySize=1000
jcs.auxiliary.DC2.attributes.MaxKeySize=10
jcs.auxiliary.DC2.attributes.OptimizeAtRemoveCount=3
jcs.auxiliary.DC2.attributes.OptimizeOnShutdown=true
jcs.auxiliary.DC2.attributes.MaxRecycleBinSize=1000
Object to write to cache:
key: string
value (all used classes in import implement Serializable):
package de.spektra.rtd.sdb.condition;
import de.spektra.rtd.model.event.Event;
import de.spektra.rtd.model.event.StatusAlarmCondition;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
import java.util.Map;
/**
*
* @author Klinge
*/
public class DistrictConditions implements Serializable{
//private static final java.util.logging.Logger logger =
Logger.getLogger(DistrictCondition);
private MapString, DistrictObjectTypeConditions objectTypesConditions;
public DistrictConditions() {
this.objectTypesConditions = new HashMapString,
DistrictObjectTypeConditions();
}
public ObjectCondition setEvent(Event event) {
String objectType = event.getIdentification().getObjectType();
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
if (objectTypeConditions == null) {
objectTypeConditions = new DistrictObjectTypeConditions();
this.objectTypesConditions.put(objectType, objectTypeConditions);
}
return objectTypeConditions.setEvent(event);
}
public ObjectCondition getObjectCondtion(String objectType, String
identification) {
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
//logger.log(Level.INFO, objectTypeConditions: {0},
objectTypeConditions);
return objectTypeConditions.getObjectCondition(identification);
}
public CollectionObjectCondition getObjectConditions(CollectionString
objectTypes) {
ArrayListObjectCondition objectConditions = new
ArrayListObjectCondition();
for (String objectType: objectTypes) {
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
if (objectTypeConditions!=null) {
objectConditions.addAll(objectTypeConditions.getObjectConditions());
}
}
return objectConditions;
}
public StatusAlarmCondition getCurrentStatusAlarmCondtition(String
objectType, String identification) {
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
return
objectTypeConditions.getCurrentStatusAlarmCondition(identification);
}
public
[jira] [Updated] (SANDBOX-409) Drop Vertex/Edge marker interfaces
[
https://issues.apache.org/jira/browse/SANDBOX-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claudio Squarcella updated SANDBOX-409:
---
Attachment: SANDBOX-409_ExportersWithVarargsForVertexAndEdgeProperties.patch
Hi Simone,
as anticipated on ML I played a bit with the branch to (re)add export
functionalities. You can find my (very incomplete) attempts to use varargs for
Vertex and Edge properties. However the tests in {{export.ExportTestCase}} give
a warning on the type of the varargs array.
See if you can make sense out of it and maybe even get rid of the warning... :)
Ciao
Claudio
Drop Vertex/Edge marker interfaces
--
Key: SANDBOX-409
URL: https://issues.apache.org/jira/browse/SANDBOX-409
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Attachments:
SANDBOX-409_ExportersWithVarargsForVertexAndEdgeProperties.patch
As widely discussed in the ML, there is a general agreement on dropping the
{{Vertex}} and {{Edge}} interface and allow {{Graph}} using whatever object
as node/arc.
Due to the large number of modifications involved, I intend working on it on
a separate branch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JEXL-127) Allow the creation of functions
[
https://issues.apache.org/jira/browse/JEXL-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228432#comment-13228432
]
Henri Biestro commented on JEXL-127:
Reworked grammar to properly treat parenthesized expressions and calling chains;
Added 'anonymous/closure' style syntax to functions '(x, y)- { ... }';
Made additive operations separate nodes / classes;
Renamed occurences of 'register' to symbol (Scope/Frame);
Code shuffling in Interpreter to have all complex methods located together
(assign, call, de-reference...);
Added syntactic detection of invalid assignment (left member must be left
value);
Moved JexlEvalContext to test package (only use is testing);
Renamed 'UnifiedJEXLTest' to 'JXLTTest' to properly reflect new naming;
Added / completed a few tests;
Various checkstyle / Javadoc
Committed revision 1300178.
Sending jexl3/trunk/pom.xml
Deleting
jexl3/trunk/src/main/java/org/apache/commons/jexl3/JexlEvalContext.java
Sending
jexl3/trunk/src/main/java/org/apache/commons/jexl3/internal/Debugger.java
Sending
jexl3/trunk/src/main/java/org/apache/commons/jexl3/internal/Engine.java
Sending
jexl3/trunk/src/main/java/org/apache/commons/jexl3/internal/Interpreter.java
Sending
jexl3/trunk/src/main/java/org/apache/commons/jexl3/internal/Scope.java
Sending
jexl3/trunk/src/main/java/org/apache/commons/jexl3/internal/introspection/Permissions.java
Sending
jexl3/trunk/src/main/java/org/apache/commons/jexl3/parser/ASTIdentifier.java
Adding
jexl3/trunk/src/main/java/org/apache/commons/jexl3/parser/ASTIdentifierAccess.java
Sending
jexl3/trunk/src/main/java/org/apache/commons/jexl3/parser/ASTJexlScript.java
Sending
jexl3/trunk/src/main/java/org/apache/commons/jexl3/parser/ASTReferenceExpression.java
Sending
jexl3/trunk/src/main/java/org/apache/commons/jexl3/parser/JexlNode.java
Sending
jexl3/trunk/src/main/java/org/apache/commons/jexl3/parser/JexlParser.java
Sending
jexl3/trunk/src/main/java/org/apache/commons/jexl3/parser/Parser.jjt
Sending
jexl3/trunk/src/main/java/org/apache/commons/jexl3/parser/ParserVisitor.java
Sending
jexl3/trunk/src/test/java/org/apache/commons/jexl3/ArrayAccessTest.java
Sending jexl3/trunk/src/test/java/org/apache/commons/jexl3/AssignTest.java
Sending jexl3/trunk/src/test/java/org/apache/commons/jexl3/CacheTest.java
Sending
jexl3/trunk/src/test/java/org/apache/commons/jexl3/ClassCreatorTest.java
Sending jexl3/trunk/src/test/java/org/apache/commons/jexl3/IfTest.java
Sending jexl3/trunk/src/test/java/org/apache/commons/jexl3/IssuesTest.java
Addingjexl3/trunk/src/test/java/org/apache/commons/jexl3/JXLTTest.java
Adding
jexl3/trunk/src/test/java/org/apache/commons/jexl3/JexlEvalContext.java
Sending jexl3/trunk/src/test/java/org/apache/commons/jexl3/JexlTest.java
Sending jexl3/trunk/src/test/java/org/apache/commons/jexl3/LambdaTest.java
Sending jexl3/trunk/src/test/java/org/apache/commons/jexl3/MethodTest.java
Sending
jexl3/trunk/src/test/java/org/apache/commons/jexl3/ScriptCallableTest.java
Deleting
jexl3/trunk/src/test/java/org/apache/commons/jexl3/UnifiedJEXLTest.java
Sending jexl3/trunk/src/test/java/org/apache/commons/jexl3/VarTest.java
Sending
jexl3/trunk/src/test/java/org/apache/commons/jexl3/internal/Util.java
Sending
jexl3/trunk/src/test/java/org/apache/commons/jexl3/junit/Asserter.java
Allow the creation of functions
---
Key: JEXL-127
URL: https://issues.apache.org/jira/browse/JEXL-127
Project: Commons JEXL
Issue Type: Improvement
Reporter: Henri Biestro
Assignee: Henri Biestro
Fix For: 3.0
As script get richer, being able to create functions is a strong need.
This only requires adding a new keyword ('function') and the syntax would be:
var fn = function(x, y, z) {...}.
It would be nice to allow those to behave as closures (thru local variable
hoistering).
This will bring JEXL closer to ECMAScript in functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JCS-94) LateralTCPService should implement getGroupKeys
LateralTCPService should implement getGroupKeys --- Key: JCS-94 URL: https://issues.apache.org/jira/browse/JCS-94 Project: Commons JCS Issue Type: Improvement Components: TCP Lateral Cache Affects Versions: jcs-1.3, jcs-1.4-dev Reporter: Andrew Leamon Calling getGroupKeys on LateralTCPService throws new UnsupportedOperationException( Groups not implemented. ); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-306) ReaderInputStream#read(byte[] b, int off, int len) should always return 0 for length == 0
ReaderInputStream#read(byte[] b, int off, int len) should always return 0 for length == 0 - Key: IO-306 URL: https://issues.apache.org/jira/browse/IO-306 Project: Commons IO Issue Type: Bug Reporter: Sebb The method read(byte[] b, int off, int len) should always return 0 if the requested length == 0, even if the stream is empty or at EOF, as that is how the overridden java.io.InputStream method is documented to behave. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-307) ReaderInputStream#read(byte[] b, int off, int len) should check for valid parameters
ReaderInputStream#read(byte[] b, int off, int len) should check for valid parameters Key: IO-307 URL: https://issues.apache.org/jira/browse/IO-307 Project: Commons IO Issue Type: Bug Reporter: Sebb If the buffer is null, the method should throw NPE immediately (rather than letting it occur later) If the offset or length are 0 or would overflow the buffer, then throw IndexOutOfBoundsException with details of the values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-307) ReaderInputStream#read(byte[] b, int off, int len) should check for valid parameters
[ https://issues.apache.org/jira/browse/IO-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-307: Affects Version/s: 2.1 ReaderInputStream#read(byte[] b, int off, int len) should check for valid parameters Key: IO-307 URL: https://issues.apache.org/jira/browse/IO-307 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Reporter: Sebb If the buffer is null, the method should throw NPE immediately (rather than letting it occur later) If the offset or length are 0 or would overflow the buffer, then throw IndexOutOfBoundsException with details of the values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-306) ReaderInputStream#read(byte[] b, int off, int len) should always return 0 for length == 0
[ https://issues.apache.org/jira/browse/IO-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-306: Affects Version/s: 2.1 Fix Version/s: 2.2 ReaderInputStream#read(byte[] b, int off, int len) should always return 0 for length == 0 - Key: IO-306 URL: https://issues.apache.org/jira/browse/IO-306 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Reporter: Sebb Fix For: 2.2 The method read(byte[] b, int off, int len) should always return 0 if the requested length == 0, even if the stream is empty or at EOF, as that is how the overridden java.io.InputStream method is documented to behave. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-306) ReaderInputStream#read(byte[] b, int off, int len) should always return 0 for length == 0
[ https://issues.apache.org/jira/browse/IO-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved IO-306. - Resolution: Fixed ReaderInputStream#read(byte[] b, int off, int len) should always return 0 for length == 0 - Key: IO-306 URL: https://issues.apache.org/jira/browse/IO-306 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Reporter: Sebb Fix For: 2.2 The method read(byte[] b, int off, int len) should always return 0 if the requested length == 0, even if the stream is empty or at EOF, as that is how the overridden java.io.InputStream method is documented to behave. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CSV-57) CSVParser.getRecords() contract is confusing
[
https://issues.apache.org/jira/browse/CSV-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated CSV-57:
---
Attachment: CSV-57.txt
Hi,
I've created a patch, that does some very minor refactoring:
* use for each loop in favor of while loop (just for readability)
* changed implementation to return empty array instead of null
* JUnit test, that makes sure, that an empty array will be returned, if there
is nothing to parse
* Some JavaDoc adjustments
Regards,
Benedikt
CSVParser.getRecords() contract is confusing
Key: CSV-57
URL: https://issues.apache.org/jira/browse/CSV-57
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Reporter: Benedikt Ritter
Priority: Minor
Attachments: CSV-57.txt
{{CSVParser.getRecords()}} has a confusing contract. It will return all
records from the current position instead of all values in the parsed file.
This implies that users will first iterate over the records using the
iterator and then call getRecords(). This seems like an unlikely use case.
Also, it is not good practice to return {{null}}. So getRecords() should
return an empty array, if no records can be found.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-793) Fix CheckStyle Errors in SerializationUtils
[ https://issues.apache.org/jira/browse/LANG-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-793: - Attachment: LANG-793.txt I have created a patch for this very minor issue. Fix CheckStyle Errors in SerializationUtils --- Key: LANG-793 URL: https://issues.apache.org/jira/browse/LANG-793 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Benedikt Ritter Priority: Trivial Attachments: LANG-793.txt Checkstyle complains about missing braces in SerializationUtils. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-793) Fix CheckStyle Errors in SerializationUtils
Fix CheckStyle Errors in SerializationUtils --- Key: LANG-793 URL: https://issues.apache.org/jira/browse/LANG-793 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Benedikt Ritter Priority: Trivial Attachments: LANG-793.txt Checkstyle complains about missing braces in SerializationUtils. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-213) LineIterator should implement IteratorString as well/instead of Iterator
[ https://issues.apache.org/jira/browse/IO-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-213: Fix Version/s: 2.0 LineIterator should implement IteratorString as well/instead of Iterator --- Key: IO-213 URL: https://issues.apache.org/jira/browse/IO-213 Project: Commons IO Issue Type: Bug Components: Utilities Reporter: Robert Collins Priority: Trivial Fix For: 2.0 Typesafety is nicer than having to cast from object on every pass through the loop. As LineIterator only outputs strings, this should be trivial. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-223) IOUtils.copy Javadoc inconsistency (return -1 vs. throw ArithmeticException)
[ https://issues.apache.org/jira/browse/IO-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-223: Fix Version/s: 2.0 IOUtils.copy Javadoc inconsistency (return -1 vs. throw ArithmeticException) Key: IO-223 URL: https://issues.apache.org/jira/browse/IO-223 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3, 1.3.1, 1.3.2, 1.4 Reporter: Adam Michalik Fix For: 2.0 The javadoc for IOUtils.copy says: Large streams (over 2GB) will return a bytes copied value of -1 after the copy has completed since the correct number of bytes cannot be returned as an int. but then it says: Throws: ArithmeticException - if the byte count is too large This is an inconsistency since -1 is always returned if the byte count is too large. ArithmeticException is never actually thrown. See IO-84 for discussion on solving the too large byte count problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-207) Race condition in forceMkdir
[ https://issues.apache.org/jira/browse/IO-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-207: Fix Version/s: 2.0 Race condition in forceMkdir Key: IO-207 URL: https://issues.apache.org/jira/browse/IO-207 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.4 Environment: Windows Reporter: Luke Quinane Priority: Minor Fix For: 2.0 Attachments: forceMkdir.patch Original Estimate: 1h Remaining Estimate: 1h If two processes or threads call forceMkdir() with the same directory there is a chance that one will throw an IOException even though a directory was correctly created (by the other process or thread). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-187) FileSystemUtils.freeSpaceKb doesn't work with relative paths on Linux
[ https://issues.apache.org/jira/browse/IO-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-187: Fix Version/s: 2.0 FileSystemUtils.freeSpaceKb doesn't work with relative paths on Linux - Key: IO-187 URL: https://issues.apache.org/jira/browse/IO-187 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2, 1.4 Environment: Linux Reporter: Cormac Blackwell Fix For: 2.0 Calling FileSystemUtils.freeSpaceKb with ., ./, ../, ../foo etc. will result in an empty string being passed to df. freeSpaceKb calls FileNameUtils.normalize on the path which destroys relative paths. I don't see any need to normalize the path so the fix is simply to remove that call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-205) FileUtils.forceMkdir Javadoc is unclear
[ https://issues.apache.org/jira/browse/IO-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-205: Component/s: Utilities Fix Version/s: 2.0 FileUtils.forceMkdir Javadoc is unclear --- Key: IO-205 URL: https://issues.apache.org/jira/browse/IO-205 Project: Commons IO Issue Type: Bug Components: Utilities Reporter: Trejkaz Fix For: 2.0 The Javadoc for FileUtils.forceMkdir doesn't say what is supposed to happen if a directory already exists with the same path. It does (misleadingly) say that if a file already exists, it fails. I interpreted this to mean that a directory would also fail, as it said *file* and not *normal file*. However in reality, if the directory already exists, the method passes. For clarity it should say that it succeeds if the directory already exists, and should probably also explicitly say normal file instead of just file, as all directories are files. Also, internally, I notice it is checking for File.isFile() whereas our existing method for implementing the same thing is checking !File.isDirectory(). On some filesystems, a file can be both a directory and a normal file, and in this situation I would expect the method to pass, whereas with Commons' implementation it would fail. Maybe this is a trip-up because Sun themselves documented normal file as meaning something which is not a directory, which is going to break the moment someone runs something on a more exotic filesystem. :-( -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-191) Possible improvements using static analysis.
[ https://issues.apache.org/jira/browse/IO-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-191: Fix Version/s: 2.0 Possible improvements using static analysis. Key: IO-191 URL: https://issues.apache.org/jira/browse/IO-191 Project: Commons IO Issue Type: Improvement Reporter: Peter Lawrey Priority: Trivial Fix For: 2.0 Attachments: commons-io-static-analysis.patch Original Estimate: 3h Remaining Estimate: 3h -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-275) org.apache.commons.io.FileUtils.contentEquals - Add option to ignore line endings
[ https://issues.apache.org/jira/browse/IO-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-275: Fix Version/s: 2.2 org.apache.commons.io.FileUtils.contentEquals - Add option to ignore line endings --- Key: IO-275 URL: https://issues.apache.org/jira/browse/IO-275 Project: Commons IO Issue Type: New Feature Components: Utilities Reporter: CJ Aspromgos Fix For: 2.2 FileUtils has a nice member function to compare two files. It would be nice if the client had the option to ignore line endings. This way files (specifically text files) generated on different platforms (eg windows, unix) would match. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-275) org.apache.commons.io.FileUtils.contentEquals - Add option to ignore line endings
[ https://issues.apache.org/jira/browse/IO-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228735#comment-13228735 ] CJ Aspromgos commented on IO-275: - Excellent. I'll have to try out the new version. :-) org.apache.commons.io.FileUtils.contentEquals - Add option to ignore line endings --- Key: IO-275 URL: https://issues.apache.org/jira/browse/IO-275 Project: Commons IO Issue Type: New Feature Components: Utilities Reporter: CJ Aspromgos Fix For: 2.2 FileUtils has a nice member function to compare two files. It would be nice if the client had the option to ignore line endings. This way files (specifically text files) generated on different platforms (eg windows, unix) would match. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-124) fix website permissions
[ https://issues.apache.org/jira/browse/IO-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-124: Fix Version/s: 1.3.2 fix website permissions --- Key: IO-124 URL: https://issues.apache.org/jira/browse/IO-124 Project: Commons IO Issue Type: Bug Reporter: Godmar Back Fix For: 1.3.2 http://jakarta.apache.org/commons/io/api-release/index.html says: Forbidden You don't have permission to access /commons/io/api-release/index.html on this server. Apache/2.3.0-dev (Unix) Server at jakarta.apache.org Port 80 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-307) ReaderInputStream#read(byte[] b, int off, int len) should check for valid parameters
[ https://issues.apache.org/jira/browse/IO-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved IO-307. - Resolution: Fixed Fix Version/s: 2.2 ReaderInputStream#read(byte[] b, int off, int len) should check for valid parameters Key: IO-307 URL: https://issues.apache.org/jira/browse/IO-307 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Reporter: Sebb Fix For: 2.2 If the buffer is null, the method should throw NPE immediately (rather than letting it occur later) If the offset or length are 0 or would overflow the buffer, then throw IndexOutOfBoundsException with details of the values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-291) Add new function FileUtils.directoryContains
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-291: Fix Version/s: (was: 2.2) Add new function FileUtils.directoryContains Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Attachments: io-291-simple.diff, io-291-v5.patch I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-300) FileUtils.moveDirectoryToDirectory removes source directory if destination is a subdirectory
[ https://issues.apache.org/jira/browse/IO-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-300: Summary: FileUtils.moveDirectoryToDirectory removes source directory if destination is a subdirectory (was: FileUtils.moveDirectoryToDirectory removing source directory) FileUtils.moveDirectoryToDirectory removes source directory if destination is a subdirectory Key: IO-300 URL: https://issues.apache.org/jira/browse/IO-300 Project: Commons IO Issue Type: Bug Reporter: dennis lucero Attachments: IO-300.patch Since moveDirectoryToDirectory performs a copy then delete, if you specify a target directory that is a subdirectory of the source, everything under the source directory is deleted. Steps to recreate: File dest = new File(/tmp/dir1/dir2); File src = new File(/tmp/dir1/); dest.mkdirs(); System.out.println(src.exists()); FileUtils.moveDirectoryToDirectory(src, dest, false); System.out.println(src.exists()); Output: true false If you try the same thing with a move command on Linux, you receive: mv: cannot move `dir1/' to a subdirectory of itself, `dir1/dir2/dir1' Maybe throw an exception if dest.getCanonicalPath().startsWith(src.getCanonicalPath()) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-300) FileUtils.moveDirectoryToDirectory removes source directory if destination is a subdirectory
[ https://issues.apache.org/jira/browse/IO-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved IO-300. - Resolution: Fixed Fix Version/s: 2.2 Thanks for the report. Added check for subdirectory if rename fails. FileUtils.moveDirectoryToDirectory removes source directory if destination is a subdirectory Key: IO-300 URL: https://issues.apache.org/jira/browse/IO-300 Project: Commons IO Issue Type: Bug Reporter: dennis lucero Fix For: 2.2 Attachments: IO-300.patch Since moveDirectoryToDirectory performs a copy then delete, if you specify a target directory that is a subdirectory of the source, everything under the source directory is deleted. Steps to recreate: File dest = new File(/tmp/dir1/dir2); File src = new File(/tmp/dir1/); dest.mkdirs(); System.out.println(src.exists()); FileUtils.moveDirectoryToDirectory(src, dest, false); System.out.println(src.exists()); Output: true false If you try the same thing with a move command on Linux, you receive: mv: cannot move `dir1/' to a subdirectory of itself, `dir1/dir2/dir1' Maybe throw an exception if dest.getCanonicalPath().startsWith(src.getCanonicalPath()) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-295) FileUtils.isSymlinks misses symlink folders
[ https://issues.apache.org/jira/browse/IO-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228909#comment-13228909 ] Sebb commented on IO-295: - At present, the method always returns false for Windows systems. Not sure whether it's possible to detect symbolic links on Windows (except by using Java 7 of course). FileUtils.isSymlinks misses symlink folders --- Key: IO-295 URL: https://issues.apache.org/jira/browse/IO-295 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Environment: Windows 7 64 bit, Oracle Java 7 Reporter: Ron Gross I created a symlink folder via mklink. Then, while debugging, I noticed that FileUtils.isSymlink() returns false on this directory, while Java 7's Files.isSymbolicLink() returns true. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
