[jira] [Created] (COLLECTIONS-402) Inconsistent Javadoc comment and code in intersection(List list1,List list2)in org.apache.commons.collections.ListUtils
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 Fix For: 4.0 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 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] (COLLECTIONS-401) Inconsistent Javadoc comment and code in removeAll(Collection, Collection) in org.apache.commons.collections.ListUtils
Inconsistent Javadoc comment and code in removeAll(Collection,
Collection) in org.apache.commons.collections.ListUtils
Key: COLLECTIONS-401
URL: https://issues.apache.org/jira/browse/COLLECTIONS-401
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 3.2.1
Reporter: SHIN HWEI TAN
The Javadoc comment below states that the method "throws NullPointerException
if either parameter is null".
/*..
*
* @throws NullPointerException if either parameter is null
*/
public static List removeAll(Collection collection,
Collection remove) {
..
}
However, when called with two null collections (i.e.,
"removeAll((Collection)null, (Collection)null)"), the method executes normally
without throwing any exception.
Suggested Fixes:
1. Add code "if (collection == null) throw NullPointerException();" at the
beginning of the method body.
or
2. Remove "@throws NullPointerException if either parameter is null" from the
Javadoc.
or
3. Change "@throws NullPointerException if either parameter is null" to
"@throws NullPointerException if the first collection is null or (the first
collection is non-empty and the second collection is null)".
--
This message 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] (COLLECTIONS-400) Inconsistent Javadoc comment and code in addIgnoreNull(Collection, T) in org.apache.commons.collections.CollectionUtils
Inconsistent Javadoc comment and code in addIgnoreNull(Collection, T) in
org.apache.commons.collections.CollectionUtils
--
Key: COLLECTIONS-400
URL: https://issues.apache.org/jira/browse/COLLECTIONS-400
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 3.2.1
Environment: Platform independent
Reporter: SHIN HWEI TAN
The Javadoc comment below states that the method "throws NullPointerException
if the collection is null".
/**
.
* @param collection the collection to add to, must not be null
* @param object the object to add, if null it will not be added
* @return true if the collection changed
* @throws NullPointerException if the collection is null
*/
public static boolean addIgnoreNull(Collection collection, T
object) {
return (object != null && collection.add(object));
}
However, when called with an null collection and a null object (i.e.,
"addIgnoreNull((Collection)null, null)"), the method executes normally without
throwing any exception.
Suggested Fixes:
1. Add code "if (collection == null) throw NullPointerException();" at the
beginning of the method body.
or
2. Remove "@throws NullPointerException if the collection is null" from the
Javadoc.
or
3. Change "@throws NullPointerException if the collection is null" to "@throws
NullPointerException if the collection is null and the object is non-null)".
--
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] (CSV-91) Distinguish quoted tokens?
Distinguish quoted tokens? -- Key: CSV-91 URL: https://issues.apache.org/jira/browse/CSV-91 Project: Commons CSV Issue Type: New Feature Reporter: Sebb Priority: Minor Might be useful to be able to distinguish which tokens were quoted and which were not. This would need to apply more that one token type, so would be best as a separate flag. Not sure how this might be stored in the CSVRecord class; perhaps a separate boolean array? -- 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] (CSV-70) Improve readability of CSVLexer
[ https://issues.apache.org/jira/browse/CSV-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-70. - Resolution: Fixed I think this is now complete. > Improve readability of CSVLexer > --- > > Key: CSV-70 > URL: https://issues.apache.org/jira/browse/CSV-70 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.0 >Reporter: Benedikt Ritter > Fix For: 1.0 > > > There are several things that can be improved in the token lexer (this has > also been discussed on ML, see http://markmail.org/thread/c6x5ji4v44nx5k4h): > * Remove Token input parameter in nextToken() (x) this makes lexer slower > * Add convenience methods isDelimiter(c) and isEncapsulator(c) (/) > * Remove current caracter input parameter from methods (/) > * If possible: replace while(true) loops -- 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] (CSV-90) CSVFormat isEscaping/isEscaping are not public
[ https://issues.apache.org/jira/browse/CSV-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241969#comment-13241969 ] Sebb commented on CSV-90: - Likewise there could be a public version of getHeader(). It would need to clone the array. > CSVFormat isEscaping/isEscaping are not public > -- > > Key: CSV-90 > URL: https://issues.apache.org/jira/browse/CSV-90 > Project: Commons CSV > Issue Type: Bug >Reporter: Sebb > > The CSVFormat methods isEscaping() and isEncapsulating() are package > protected, whereas the other 3 isXXX() methods are public. > There seems no reason for this difference. > These are external settings - they are defined by the user - so I don't see > why the methods should not be public. > AFAICT making them public would not commit the API to anything new. -- 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] [Closed] (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 ] Gary D. Gregory closed IO-275. -- Version 2.2 has been released and addresses this issue. > 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] [Closed] (IO-290) Add read/readFully methods to IOUtils
[
https://issues.apache.org/jira/browse/IO-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-290.
--
Version 2.2 has been released and addresses this issue.
> Add read/readFully methods to IOUtils
> -
>
> Key: IO-290
> URL: https://issues.apache.org/jira/browse/IO-290
> Project: Commons IO
> Issue Type: New Feature
>Reporter: Sebb
> Fix For: 2.2
>
>
> When reading from network etc, it's possible for a read to return before it
> has read as many bytes as would fit in the buffer.
> Sometimes multiple reads are needed to fulfil the request.
> It would be useful to have read() versions of the skip() methods.
> {code}
> int actual = read(Reader, byte buffer [,offset, length]) // returns normally
> on EOF
> int actual = read(InputStream, char buffer [,offset, length])
> int actual = readFully(Reader, byte buffer [,offset, length]) // throws
> EOFException
> int actual = readFully(InputStream, char buffer [,offset, length])
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-288) Supply a ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/IO-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-288.
--
Version 2.2 has been released and addresses this issue.
> Supply a ReversedLinesFileReader
> -
>
> Key: IO-288
> URL: https://issues.apache.org/jira/browse/IO-288
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Reporter: Georg Henzler
> Fix For: 2.2
>
> Attachments: ReversedLinesFileReader0.3.zip
>
>
> I needed to analyse a log file today and I was looking for a
> ReversedLinesFileReader: A class that behaves exactly like BufferedReader
> except that it goes from bottom to top when readLine() is called. I didn't
> find it in IOUtils and the internet didn't help a lot either, e.g.
> http://www.java2s.com/Tutorial/Java/0180__File/ReversingaFile.htm is a fairly
> inefficient - the log files I'm analysing are huge and it is not a good idea
> to load the whole content in the memory.
> So I ended up writing an implementation myself using little memory and the
> class RandomAccessFile - see attached file. It's used as follows:
> int blockSize = 4096; // only that much memory is needed, no matter how big
> the file is
> ReversedLinesFileReader reversedLinesFileReader = new ReversedLinesFileReader
> (myFile, blockSize, "UTF-8"); // encoding is supported
> String line = null;
> while((line=reversedLinesFileReader.readLine())!=null) {
> ... // use the line
> if(enoughLinesSeen) {
> break;
> }
> }
> reversedLinesFileReader.close();
> I believe this could be useful for other people as well!
--
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] [Closed] (IO-291) Add new function FileUtils.directoryContains
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-291. -- Resolution: Fixed Version 2.2 has been released and addresses this issue. > 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] [Closed] (IO-292) IOUtils.closeQuietly() should take a ServerSocket as a parameter
[ https://issues.apache.org/jira/browse/IO-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-292. -- Version 2.2 has been released and addresses this issue. > IOUtils.closeQuietly() should take a ServerSocket as a parameter > > > Key: IO-292 > URL: https://issues.apache.org/jira/browse/IO-292 > Project: Commons IO > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > Fix For: 2.2 > > > Unfortunately ServerSocket does not implement Closeable, nor does it extend > Socket, so none of the existing closeQuietly() methods can be used. > Might be useful to implement this as well. -- 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] [Closed] (IO-301) Add IOUtils.closeQuietly(Selector)
[ https://issues.apache.org/jira/browse/IO-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-301. -- Version 2.2 has been released and addresses this issue. > Add IOUtils.closeQuietly(Selector) > -- > > Key: IO-301 > URL: https://issues.apache.org/jira/browse/IO-301 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.1 >Reporter: Karthik K > Fix For: 2.2 > > Attachments: IO-301.patch > > > IOUtils.closeQuietly(Selector) would be useful to fix yet another resource > leakage. -- 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] [Closed] (IO-298) Various methods of class 'org.apache.commons.io.FileUtils' incorrectly suppress 'java.io.IOException's.
[ https://issues.apache.org/jira/browse/IO-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-298. -- Version 2.2 has been released and addresses this issue. > Various methods of class 'org.apache.commons.io.FileUtils' incorrectly > suppress 'java.io.IOException's. > --- > > Key: IO-298 > URL: https://issues.apache.org/jira/browse/IO-298 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.1 >Reporter: Christian Schulte >Priority: Critical > Labels: patch > Fix For: 2.2 > > Attachments: IO-298.patch > > -- 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] [Closed] (IO-302) ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without BOM multiple times
[ https://issues.apache.org/jira/browse/IO-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-302. -- Version 2.2 has been released and addresses this issue. > ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without > BOM multiple times > --- > > Key: IO-302 > URL: https://issues.apache.org/jira/browse/IO-302 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.1 > Environment: Win7 64bit, Java 6 32bit >Reporter: Jan Steuerwald >Assignee: Gary D. Gregory > Fix For: 2.2 > > Attachments: IO-302.patch, Test.java, testfileBOM.xml, > testfileNoBOM.xml > > > Resetting the BOMInputStream doesn't reset the _fbLength_ member variable. > This causes _fbLength_ to grow bigger than the _firstBytes_ array (when the > file doesn't contain a BOM), which leads to an ArrayIndexOutOfBoundsException > in the _readFirstBytes_ method. > The attached test case reveals the 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] [Closed] (IO-296) ReaderInputStream optimization: more efficient reading of small chunks of data
[ https://issues.apache.org/jira/browse/IO-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-296. -- Version 2.2 has been released and addresses this issue. > ReaderInputStream optimization: more efficient reading of small chunks of data > -- > > Key: IO-296 > URL: https://issues.apache.org/jira/browse/IO-296 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Oleg Kalnichevski > Fix For: 2.2 > > Attachments: commons-io-readerinputstream-optimization.patch > > > ReaderInputStream in its current form does not efficiently handle reading of > small data chunks. #read(byte[] b, int off, int len) methods compacts > encoderOut on every read operation, which is not very efficient if the chunks > of data being read are smallish. This especially affects the #read() method, > which currently reads one byte of data into a temporary byte array. Not to > mention that allocation of a temporary byte array on each #read() method > invocation leads to generation of unnecessary intermediate garbage on the > heap. -- 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] [Closed] (IO-273) BoundedInputStream.read() treats max differently from BoundedInputStream.read(byte[]...)
[ https://issues.apache.org/jira/browse/IO-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-273. -- Version 2.2 has been released and addresses this issue. > BoundedInputStream.read() treats max differently from > BoundedInputStream.read(byte[]...) > > > Key: IO-273 > URL: https://issues.apache.org/jira/browse/IO-273 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Reporter: Sebb >Priority: Minor > Fix For: 2.2 > > > BoundedInputStream.read() treats max differently from > BoundedInputStream.read(byte[]...) > read() checks for pos == max, whereas read(byte[]...) checks for pos >= max. > The latter check is safer (works even if pos overshoots max). -- 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] [Closed] (IO-173) FileUtils.listFiles() doesn't return directories
[
https://issues.apache.org/jira/browse/IO-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-173.
--
Version 2.2 has been released and addresses this issue.
> FileUtils.listFiles() doesn't return directories
>
>
> Key: IO-173
> URL: https://issues.apache.org/jira/browse/IO-173
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 1.4
>Reporter: François Loison
> Fix For: 2.2
>
> Attachments: IO-173.patch, IO-173.patch
>
>
> FileUtils.listFiles() returns only files and not directories.
> So it can't be used to retrieve sub-directories.
> Some fix could be applied:
> {code}
> private static void innerListFiles(Collection files, File directory,
> IOFileFilter filter) {
> File[] found = directory.listFiles((FileFilter) filter);
> if (found != null) {
> for (int i = 0; i < found.length; i++) {
> if (found[i].isDirectory()) {
> >>> fix
> if ( addDirectories ) {
>files.add(found[i]);
> }
> >>> end fix
> innerListFiles(files, found[i], filter);
> } else {
> files.add(found[i]);
> }
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-276) "FileUtils#deleteDirectoryOnExit(File)" does not work
[
https://issues.apache.org/jira/browse/IO-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-276.
--
Version 2.2 has been released and addresses this issue.
> "FileUtils#deleteDirectoryOnExit(File)" does not work
> -
>
> Key: IO-276
> URL: https://issues.apache.org/jira/browse/IO-276
> Project: Commons IO
> Issue Type: Bug
> Environment: Commons IO 1.4
>Reporter: nkami
>Priority: Minor
> Fix For: 2.2
>
> Attachments: IO-276-r1201108-patch.txt
>
>
> I called this method, but the target directory was not deleted.
> The source of this method is as follows.
> --
> private static void deleteDirectoryOnExit(File directory) throws
> IOException {
> if (!directory.exists()) {
> return;
> }
> cleanDirectoryOnExit(directory);
> directory.deleteOnExit();
> }
> --
> In other words, this method calls "java.io.File#deleteOnExit" in order of
> "grandchildren -> children -> parent" for files of the target directory
> hierarchy.
> There is following mention in javadoc of "java.io.File#deleteOnExit".
> --
> Files (or directories) are deleted in the reverse order that they are
> registered.
> --
> Therefore, I think the calling order of "java.io.File#deleteOnExit" should be
> reverse.
> How will be it?
--
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] [Closed] (IO-297) CharSequenceInputStream to efficiently stream content of a CharSequence
[ https://issues.apache.org/jira/browse/IO-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-297. -- Version 2.2 has been released and addresses this issue. > CharSequenceInputStream to efficiently stream content of a CharSequence > --- > > Key: IO-297 > URL: https://issues.apache.org/jira/browse/IO-297 > Project: Commons IO > Issue Type: Improvement >Reporter: Oleg Kalnichevski > Fix For: 2.2 > > Attachments: commons-io-charseqinputstream.patch > > > CharSequenceInputStream implementation can be used to efficiently stream > content of a CharSequence. This can be useful when streaming out a large body > of text to a network socket without having to create an intermediate byte > array containing the entire content in binary form (using > String#toByteArray() or similar). -- 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] [Closed] (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 ] Gary D. Gregory closed IO-307. -- Version 2.2 has been released and addresses this issue. > 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] [Closed] (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 ] Gary D. Gregory closed IO-306. -- Version 2.2 has been released and addresses this issue. > 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] [Closed] (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
]
Gary D. Gregory closed IO-300.
--
Version 2.2 has been released and addresses this issue.
> 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] [Closed] (IO-312) CharSequenceInputStream(CharSequence s, Charset charset, int bufferSize) ignores bufferSize
[ https://issues.apache.org/jira/browse/IO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-312. -- Version 2.2 has been released and addresses this issue. > CharSequenceInputStream(CharSequence s, Charset charset, int bufferSize) > ignores bufferSize > --- > > Key: IO-312 > URL: https://issues.apache.org/jira/browse/IO-312 > Project: Commons IO > Issue Type: Bug >Reporter: Sebb > Fix For: 2.2 > > -- 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] [Closed] (IO-305) New copy() method in IOUtils that takes additional offset, length and buffersize arguments
[ https://issues.apache.org/jira/browse/IO-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-305. -- Version 2.2 has been released and addresses this issue. > New copy() method in IOUtils that takes additional offset, length and > buffersize arguments > -- > > Key: IO-305 > URL: https://issues.apache.org/jira/browse/IO-305 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Reporter: Manoj Mokashi >Priority: Minor > Fix For: 2.2 > > Attachments: IOUtils.java, IOUtilsTest.java > > > /** > * Copy from input to output stream > * @param is : input stream > * @param os : output stream > * @param offset : number of bytes to skip from input before copying > * -ve values are ignored > * @param len : number of bytes to copy. -1 means all > * @param bufferSize : buffer size to use for copying > * @throws IOException > */ > public static void copy( InputStream is, OutputStream os, int offset, int > len, int bufferSize) throws IOException > -- 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] [Closed] (IO-311) IOUtils.read(InputStream/Reader) ignores the offset parameter
[ https://issues.apache.org/jira/browse/IO-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-311. -- Version 2.2 has been released and addresses this issue. > IOUtils.read(InputStream/Reader) ignores the offset parameter > - > > Key: IO-311 > URL: https://issues.apache.org/jira/browse/IO-311 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Reporter: Robert Muir > Fix For: 2.2 > > Attachments: IO-311.patch > > > IOUtils.read(InputStream input, byte[] buffer, int offset, int length) and > read(Reader input, char[] buffer, int offset, int length) don't take the > offset parameter into account... -- 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] [Closed] (IO-313) Add IOUTils.toBufferedReader(Reader)
[ https://issues.apache.org/jira/browse/IO-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-313. -- Version 2.2 has been released and addresses this issue. > Add IOUTils.toBufferedReader(Reader) > > > Key: IO-313 > URL: https://issues.apache.org/jira/browse/IO-313 > Project: Commons IO > Issue Type: New Feature >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: 2.2 > > > Add IOUTils.toBufferedReader(Reader) to return a new BufferedReader unless > the given Reader is already a BufferedReader. -- 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] [Closed] (IO-308) Allow applications to provide buffer (or size) for copyLarge methods?
[ https://issues.apache.org/jira/browse/IO-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-308. -- Version 2.2 has been released and addresses this issue. > Allow applications to provide buffer (or size) for copyLarge methods? > - > > Key: IO-308 > URL: https://issues.apache.org/jira/browse/IO-308 > Project: Commons IO > Issue Type: New Feature >Reporter: Sebb >Priority: Minor > Fix For: 2.2 > > > Unlike the skip buffer, the copyLarge buffers cannot be shared between > threads. > The methods allocate their own buffers as local variables (current size 4096) > It might be worth allowing applications to provide their own buffers, and/or > specifying the buffer size to be used. -- 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-317) Need a way to extract parsed headers, e.g. for use in formatting output
Need a way to extract parsed headers, e.g. for use in formatting output --- Key: IO-317 URL: https://issues.apache.org/jira/browse/IO-317 Project: Commons IO Issue Type: New Feature Reporter: Sebb Parsed header names are currently not accessible except as field key names, but these have to be known in advance. It would be useful to be able to have access to the header names: * to use in printing a header for a new CSV file. E.g. to read a CSV file and produce a new one with some changes made. * to write generic CSV applications The headers could be made available as a String array (in column number order) from the CSVParser class. The simplest would be to store the parsed (or provided) headers and return a clone of the array. If headers were not provided or requested, the method should probably return null rather than an empty array - to be decided. -- 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] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-43. - Resolution: Unresolved No longer using volatile, so nothing to do here. See CSV-68 for alternative. > CSVFormat fluent API is rather inefficient > -- > > Key: CSV-43 > URL: https://issues.apache.org/jira/browse/CSV-43 > Project: Commons CSV > Issue Type: Improvement >Reporter: Sebb > > The implementation of the CSVFormat fluent API is rather inefficient, as each > method invocation clones the original class instance. > Now that the fields are volatile, it would be possible to do away with the > clone() calls entirely. > This would mean that the format could be updated later. > If such usage is not desirable, then perhaps consider adding some kind of > "freeze" method to prevent further changes. > Or perhaps the parse() and format() methods could perform the freeze (e.g. > set a flag to disable further updates). -- 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] [Issue Comment Edited] (CSV-52) Keep track of record numbers
[ https://issues.apache.org/jira/browse/CSV-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241528#comment-13241528 ] Sebb edited comment on CSV-52 at 3/29/12 7:58 PM: -- Maybe the number should also be stored in the record? The counter should be the same type (long, int) as the line number. was (Author: s...@apache.org): Maybe the number should also be stored in the record? The counter should be long. > Keep track of record numbers > > > Key: CSV-52 > URL: https://issues.apache.org/jira/browse/CSV-52 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Emmanuel Bourg >Priority: Minor > Fix For: 1.x > > > The parser is able to return the current line number of the file, it should > also be able to return the record number. -- 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] (CSV-89) Rename withLineSeparator as withOutputLineSeparator
[ https://issues.apache.org/jira/browse/CSV-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-89. - Resolution: Won't Fix > Rename withLineSeparator as withOutputLineSeparator > --- > > Key: CSV-89 > URL: https://issues.apache.org/jira/browse/CSV-89 > Project: Commons CSV > Issue Type: Improvement >Reporter: Sebb > > The name withLineSeparator is misleading, as it could be taken to mean that > the separator applies to input as well as output. > The Javadoc tries to make this clear, but it would be better if the name > reflected the function/purpose as well. -- 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] (CSV-85) Allow comments to be returned in CSVRecord
[ https://issues.apache.org/jira/browse/CSV-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-85. - Resolution: Fixed > Allow comments to be returned in CSVRecord > -- > > Key: CSV-85 > URL: https://issues.apache.org/jira/browse/CSV-85 > Project: Commons CSV > Issue Type: Improvement >Reporter: Sebb > > It might be useful to provide a comment field in the CSVRecord class. > This would be null if no comment is present for that record. > A line consisting of only a comment would have a size() of 0. -- 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] (CSV-65) Header support
[
https://issues.apache.org/jira/browse/CSV-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CSV-65.
-
Resolution: Fixed
This seems to be complete
> Header support
> --
>
> Key: CSV-65
> URL: https://issues.apache.org/jira/browse/CSV-65
> Project: Commons CSV
> Issue Type: New Feature
> Components: Parser
>Reporter: Emmanuel Bourg
> Fix For: 1.0
>
> Attachments: CSVFormat.java, CSVParser.java, CSVRecord.java
>
>
> Commons CSV is missing some elements to help dealing with CSV file headers.
> With the current API one has to write the following code to read the fields
> by name:
> {code:java}
> CSVParser parser = new CSVParser(in);
> Iterator it = parser.iterator();
> // read the header
> String[] header = it.next();
> // build a name to index mapping
> Map mapping = new HashMap<>();
> for (int i = 0; i < header.length; i++) {
> mapping.put(header[i], i);
> }
> // parse the records
> for (String[] record : parser) {
> Person person = new Person();
> person.setName(record[mapping.get("name")]);
> person.setEmail(record[mapping.get("email")]);
> person.setPhone(record[mapping.get("phone")]);
> persons.add(person);
> }
> {code}
> The header should be defined in the format with something like this:
> {code:java}
> CSVFormat format = CSVFormat.DEFAULT.withHeader();
> {code}
> Then either the parser provides the column name to index mapping
> automatically:
> {code:java}
> CSVFormat format = CSVFormat.DEFAULT.withHeader();
> CSVParser parser = new CSVParser(in, format);
> // parse the records
> for (String[] record : parser) {
> Person person = new Person();
> person.setName(record[parser.indexOf("name")]);
> person.setEmail(record[parser.indexOf("email")]);
> person.setPhone(record[parser.indexOf("phone")]);
> persons.add(person);
> }
> {code}
> or the parser returns a Map like structure similar to a JDBC ResultSet
> (replacing String[]):
> {code:java}
> CSVFormat format = CSVFormat.DEFAULT.withHeader();
> for (CSVRecord record : format.parse(in)) {
> Person person = new Person();
> person.setName(record.get("name"));
> person.setEmail(record.get("email"));
> person.setPhone(record.get("phone"));
> persons.add(person);
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-57) CSVParser.getRecords() contract is confusing
[
https://issues.apache.org/jira/browse/CSV-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CSV-57.
-
Resolution: Fixed
Patch no longer applies, because getRecords() now returns a list.
Added test case to show that the list is empty for an empty file.
> 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] [Commented] (CSV-52) Keep track of record numbers
[ https://issues.apache.org/jira/browse/CSV-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241528#comment-13241528 ] Sebb commented on CSV-52: - Maybe the number should also be stored in the record? The counter should be long. > Keep track of record numbers > > > Key: CSV-52 > URL: https://issues.apache.org/jira/browse/CSV-52 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Emmanuel Bourg >Priority: Minor > Fix For: 1.x > > > The parser is able to return the current line number of the file, it should > also be able to return the record number. -- 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] (CSV-88) Not possible to create a CSVFormat from scratch
[
https://issues.apache.org/jira/browse/CSV-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241526#comment-13241526
]
Sebb commented on CSV-88:
-
bq. PRISTINE is useless as a base format because all properties have to be
defined.
No, it's not useless; that's why it was created as empty.
The PRISTINE format provides a base that is untainted by existing settings,
which is why it works well for creating the pre-defined public formats.
The only setting that is absolutely required is the delimiter, which is why I
suggested providing a ctor which takes the delimiter as its only parameter.
As I see it, there are the following possibilities for creating a new basic
format using : as the delimiter.
{code}
fmt1 = new CSVFormat(':');
fmt2 = new CSVFormat().withDelimiter(':');
fmt3 = CSVFormat.PRISTINE.withDelimiter(':');
fmt4 = CSVFormat.newInstance(':');
fmt5 = CSVFormat.newInstance().withDelimiter(':');
{code}
Obviously the constant name PRISTINE can be changed, or the newInstance()
method could be renamed.
> Not possible to create a CSVFormat from scratch
> ---
>
> Key: CSV-88
> URL: https://issues.apache.org/jira/browse/CSV-88
> Project: Commons CSV
> Issue Type: Bug
>Reporter: Sebb
>
> It's not possible to create a CSVFormat except by modifying an existing
> format.
> Could either make the PRISTINE format public, or provide a constructor with a
> single parameter (the delimiter).
> Could provide a no-args ctor instead, but there seems little point in that.
--
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] [Issue Comment Edited] (CSV-88) Not possible to create a CSVFormat from scratch
[ https://issues.apache.org/jira/browse/CSV-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239359#comment-13239359 ] Sebb edited comment on CSV-88 at 3/29/12 6:53 PM: -- bq. +0 for a no arg constructor equivalent to the default format. If you mean the DEFAULT format here then that achieves nothing, as the user would have to override any unwanted settings - and the use would have to know which ones to override. If the DEFAULT format were ever later updated, that could invalidate the user's format. I meant that the ctor should be equivalent to PRISTINE or perhaps PRISTINE + CRLF. To fit in with the fluent API, there needs to be a static method. was (Author: s...@apache.org): bq. +0 for a no arg constructor equivalent to the default format. If you mean the DEFAULT format here then that achieves nothing, as the user would have to override any unwanted settings - and the use would have to know which ones to override. If the DEFAULT format were ever later updated, that could invalidate the user's format. I meant that the ctor should be equivalent to PRISTINE or perhaps PRISTINE + CRLF. To fit in with the fluent API, there needs to be a static method. For example, withDefault(char) would do. > Not possible to create a CSVFormat from scratch > --- > > Key: CSV-88 > URL: https://issues.apache.org/jira/browse/CSV-88 > Project: Commons CSV > Issue Type: Bug >Reporter: Sebb > > It's not possible to create a CSVFormat except by modifying an existing > format. > Could either make the PRISTINE format public, or provide a constructor with a > single parameter (the delimiter). > Could provide a no-args ctor instead, but there seems little point in that. -- 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] (CONFIGURATION-492) XMLConfiguration.getStringArray does not parse OS Environment Variables
[
https://issues.apache.org/jira/browse/CONFIGURATION-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241401#comment-13241401
]
Oliver Heger commented on CONFIGURATION-492:
In the current implementation list splitting is not done on substituted
variable values. This is true for all methods supporting variables, including
{{getStringArray()}}, {{getList()}} or the get methods for simple data types.
I am not sure whether we should change this. It would probably make the
implementation more complex. In addition, it may cause constellations which are
hard to diagnose. For instance, if {{getString()}} is called on a property with
a variable which contains multiple items, should then only the first item be
returned?
Well, the documentation does not explicitly mention that the list delimiter in
variable values is not taken into account. So at least this could be improved.
> XMLConfiguration.getStringArray does not parse OS Environment Variables
> ---
>
> Key: CONFIGURATION-492
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-492
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 1.8
> Environment: Windows XP, Commons Configuration 1.8
>Reporter: Chris Jackson
>Priority: Minor
>
> When using a OS environment variable in an XMLConfiguration file, the
> getStringArray() method does not correctly parse multiple items in the same
> entry.
> XML:
> ...
> {$env:items}
> ...
> Windows Environment variable %items% is set to "item1,item2".
> Code:
> ...
> String[] items = config.getStringArray("items")
> for (Sting item : items) {
> System.out.println("Item: " + item);
> }
> ...
> Output:
> Item: item1,item2
--
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] (CSV-35) Escaped line separators are not supported
[
https://issues.apache.org/jira/browse/CSV-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241295#comment-13241295
]
Sebb commented on CSV-35:
-
The Lexer does currently (r1036896) handle LF and CR.
The code currently treats CRLF as CR followed by LF. The LF is
handled as EOL.
> Escaped line separators are not supported
> -
>
> Key: CSV-35
> URL: https://issues.apache.org/jira/browse/CSV-35
> Project: Commons CSV
> Issue Type: Bug
>Reporter: Emmanuel Bourg
> Fix For: 1.0
>
>
> Commons CSV doesn't handle escaped line separators, for example:
> {code}
> value1;value2;value3a\
> value3b
> {code}
> In this case the expected result is:
> {code}["value1", "value2", "value3a\nvalue3b"]{code}
> This kind of escaping is produced by MySQL, whether the field enclosing is
> enabled or not. It's possible to see enclosing quotes and escaped line
> separators like this:
> {code}
> "value1";"value2";"value3a\
> value3b"
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-185) BZip2CompressorInputStream truncates files compressed with pbzip2
[
https://issues.apache.org/jira/browse/COMPRESS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241235#comment-13241235
]
Stefan Bodewig commented on COMPRESS-185:
-
Don't worry.
> BZip2CompressorInputStream truncates files compressed with pbzip2
> -
>
> Key: COMPRESS-185
> URL: https://issues.apache.org/jira/browse/COMPRESS-185
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.3
>Reporter: Karsten Loesing
> Fix For: 1.4
>
>
> I'm using BZip2CompressorInputStream in Compress 1.3 to decompress a file
> that was created with pbzip2 1.1.6 (http://compression.ca/pbzip2/). The
> stream ends early after 90 bytes, truncating the rest of the
> pbzip2-compressed file. Decompressing the file with bunzip2 or compressing
> the original file with bzip2 both fix the issue. I think both pbzip2 and
> Compress are to blame here: pbzip2 apparently does something non-standard
> when compressing files, and Compress should handle the non-standard format
> rather than pretending to be done decompressing. Another option is that I'm
> doing something wrong; in that case please let me know! :)
> Here's how the problem can be reproduced:
> 1. Generate a file that's 90+ bytes large: dd if=/dev/zero of=1mbfile
> count=1 bs=1M
> 2. Compress with pbzip2: pbzip2 1mbfile
> 3. Decompress with Bunzip2 class below
> 4. Notice how the resulting 1mbfile is 90 bytes large, not 1M.
> Now compare to using bunzip2/bzip2:
> - Do the steps above, but instead of 2, compress with bzip2: bzip2 1mbfile
> - Do the steps above, but instead of 3, decompress with bunzip2: bunzip2
> 1mbfile.bz2
> import java.io.*;
> import org.apache.commons.compress.compressors.bzip2.*;
> public class Bunzip2 {
> public static void main(String[] args) throws Exception {
> File inFile = new File(args[0]);
> File outFile = new File(args[0].substring(0, args[0].length() - 4));
> FileInputStream fis = new FileInputStream(inFile);
> BZip2CompressorInputStream bz2cis =
> new BZip2CompressorInputStream(fis);
> BufferedInputStream bis = new BufferedInputStream(bz2cis);
> BufferedOutputStream bos = new BufferedOutputStream(
> new FileOutputStream(outFile));
> int len;
> byte[] data = new byte[1024];
> while ((len = bis.read(data, 0, 1024)) >= 0) {
> bos.write(data, 0, len);
> }
> bos.close();
> bis.close();
> }
> }
--
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] (CSV-90) CSVFormat isEscaping/isEscaping are not public
CSVFormat isEscaping/isEscaping are not public -- Key: CSV-90 URL: https://issues.apache.org/jira/browse/CSV-90 Project: Commons CSV Issue Type: Bug Reporter: Sebb The CSVFormat methods isEscaping() and isEncapsulating() are package protected, whereas the other 3 isXXX() methods are public. There seems no reason for this difference. These are external settings - they are defined by the user - so I don't see why the methods should not be public. AFAICT making them public would not commit the API to anything new. -- 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] (CSV-78) Use Character instead of char for char fields except delimiter
[
https://issues.apache.org/jira/browse/CSV-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241211#comment-13241211
]
Sebb commented on CSV-78:
-
I no longer like the idea of using a null Character to disable the setting, as
it entails implicit or explicit boxing for the user code.
Option 2) above was intended to allow the existing char (if any) to be
preserved.
However, using setEscape(true) would need to check if an escape had been set,
so I think it was not a good idea either.
Another possibility would be to provide no-arg versions of the with() methods.
{noformat}
1) withNoEscape() withNoEncapsulator() withNoCommentStart()
3) withEscape() withEncapsulator() withCommentStart()
4) withEscapeNone() withEncapsulatorNone() withCommentStartNone()
{noformat}
Option4 above is just option 1 renamed to look more like the existing methods.
Other renames are possible.
> Use Character instead of char for char fields except delimiter
> --
>
> Key: CSV-78
> URL: https://issues.apache.org/jira/browse/CSV-78
> Project: Commons CSV
> Issue Type: Improvement
>Reporter: Sebb
>
> Apart from the delimiter - which must be specified (obviously) - the other
> char fields are optional.
> At present it's not possible to create a new format from an existing format
> and remove (say) the encapsulation character.
> If the parameters were changed to Character instead of char, then it would be
> possible to pass null.
--
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] (CSV-69) Eliminate CSVPrinterTest.equals(String[][], String[][]) by using Assert.assertArrayEquals
[ https://issues.apache.org/jira/browse/CSV-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-69. - Resolution: Fixed > Eliminate CSVPrinterTest.equals(String[][], String[][]) by using > Assert.assertArrayEquals > - > > Key: CSV-69 > URL: https://issues.apache.org/jira/browse/CSV-69 > Project: Commons CSV > Issue Type: Test >Reporter: Benedikt Ritter > Attachments: CSV-69.patch > > > CSVPrinterTest uses an equals method to compare two dimensional String > arrays. Since the project has been updated to JUnit 4, > Assert.assertArrayEquals() can be used instead. -- 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] (COMPRESS-185) BZip2CompressorInputStream truncates files compressed with pbzip2
[
https://issues.apache.org/jira/browse/COMPRESS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241193#comment-13241193
]
Karsten Loesing commented on COMPRESS-185:
--
Huh, you're right. I can confirm that trunk solves the problem. Thanks and
sorry for the noise.
> BZip2CompressorInputStream truncates files compressed with pbzip2
> -
>
> Key: COMPRESS-185
> URL: https://issues.apache.org/jira/browse/COMPRESS-185
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.3
>Reporter: Karsten Loesing
> Fix For: 1.4
>
>
> I'm using BZip2CompressorInputStream in Compress 1.3 to decompress a file
> that was created with pbzip2 1.1.6 (http://compression.ca/pbzip2/). The
> stream ends early after 90 bytes, truncating the rest of the
> pbzip2-compressed file. Decompressing the file with bunzip2 or compressing
> the original file with bzip2 both fix the issue. I think both pbzip2 and
> Compress are to blame here: pbzip2 apparently does something non-standard
> when compressing files, and Compress should handle the non-standard format
> rather than pretending to be done decompressing. Another option is that I'm
> doing something wrong; in that case please let me know! :)
> Here's how the problem can be reproduced:
> 1. Generate a file that's 90+ bytes large: dd if=/dev/zero of=1mbfile
> count=1 bs=1M
> 2. Compress with pbzip2: pbzip2 1mbfile
> 3. Decompress with Bunzip2 class below
> 4. Notice how the resulting 1mbfile is 90 bytes large, not 1M.
> Now compare to using bunzip2/bzip2:
> - Do the steps above, but instead of 2, compress with bzip2: bzip2 1mbfile
> - Do the steps above, but instead of 3, decompress with bunzip2: bunzip2
> 1mbfile.bz2
> import java.io.*;
> import org.apache.commons.compress.compressors.bzip2.*;
> public class Bunzip2 {
> public static void main(String[] args) throws Exception {
> File inFile = new File(args[0]);
> File outFile = new File(args[0].substring(0, args[0].length() - 4));
> FileInputStream fis = new FileInputStream(inFile);
> BZip2CompressorInputStream bz2cis =
> new BZip2CompressorInputStream(fis);
> BufferedInputStream bis = new BufferedInputStream(bz2cis);
> BufferedOutputStream bos = new BufferedOutputStream(
> new FileOutputStream(outFile));
> int len;
> byte[] data = new byte[1024];
> while ((len = bis.read(data, 0, 1024)) >= 0) {
> bos.write(data, 0, len);
> }
> bos.close();
> bis.close();
> }
> }
--
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] (COMPRESS-185) BZip2CompressorInputStream truncates files compressed with pbzip2
[
https://issues.apache.org/jira/browse/COMPRESS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-185.
-
Resolution: Duplicate
This is COMPRESS-146 which has already been fixed in trunk (and thus will be
fixed in 1.4).
> BZip2CompressorInputStream truncates files compressed with pbzip2
> -
>
> Key: COMPRESS-185
> URL: https://issues.apache.org/jira/browse/COMPRESS-185
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.3
>Reporter: Karsten Loesing
> Fix For: 1.4
>
>
> I'm using BZip2CompressorInputStream in Compress 1.3 to decompress a file
> that was created with pbzip2 1.1.6 (http://compression.ca/pbzip2/). The
> stream ends early after 90 bytes, truncating the rest of the
> pbzip2-compressed file. Decompressing the file with bunzip2 or compressing
> the original file with bzip2 both fix the issue. I think both pbzip2 and
> Compress are to blame here: pbzip2 apparently does something non-standard
> when compressing files, and Compress should handle the non-standard format
> rather than pretending to be done decompressing. Another option is that I'm
> doing something wrong; in that case please let me know! :)
> Here's how the problem can be reproduced:
> 1. Generate a file that's 90+ bytes large: dd if=/dev/zero of=1mbfile
> count=1 bs=1M
> 2. Compress with pbzip2: pbzip2 1mbfile
> 3. Decompress with Bunzip2 class below
> 4. Notice how the resulting 1mbfile is 90 bytes large, not 1M.
> Now compare to using bunzip2/bzip2:
> - Do the steps above, but instead of 2, compress with bzip2: bzip2 1mbfile
> - Do the steps above, but instead of 3, decompress with bunzip2: bunzip2
> 1mbfile.bz2
> import java.io.*;
> import org.apache.commons.compress.compressors.bzip2.*;
> public class Bunzip2 {
> public static void main(String[] args) throws Exception {
> File inFile = new File(args[0]);
> File outFile = new File(args[0].substring(0, args[0].length() - 4));
> FileInputStream fis = new FileInputStream(inFile);
> BZip2CompressorInputStream bz2cis =
> new BZip2CompressorInputStream(fis);
> BufferedInputStream bis = new BufferedInputStream(bz2cis);
> BufferedOutputStream bos = new BufferedOutputStream(
> new FileOutputStream(outFile));
> int len;
> byte[] data = new byte[1024];
> while ((len = bis.read(data, 0, 1024)) >= 0) {
> bos.write(data, 0, len);
> }
> bos.close();
> bis.close();
> }
> }
--
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] (MATH-774) Gamma Distribution override inversion sampling with nextGamma-implementation from oacm.random
Gamma Distribution override inversion sampling with nextGamma-implementation from oacm.random - Key: MATH-774 URL: https://issues.apache.org/jira/browse/MATH-774 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Mikkel Meyer Andersen Assignee: Mikkel Meyer Andersen Priority: Minor Fix For: 3.1 -- 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] (COMPRESS-185) BZip2CompressorInputStream truncates files compressed with pbzip2
BZip2CompressorInputStream truncates files compressed with pbzip2
-
Key: COMPRESS-185
URL: https://issues.apache.org/jira/browse/COMPRESS-185
Project: Commons Compress
Issue Type: Bug
Components: Compressors
Affects Versions: 1.3
Reporter: Karsten Loesing
Fix For: 1.4
I'm using BZip2CompressorInputStream in Compress 1.3 to decompress a file that
was created with pbzip2 1.1.6 (http://compression.ca/pbzip2/). The stream ends
early after 90 bytes, truncating the rest of the pbzip2-compressed file.
Decompressing the file with bunzip2 or compressing the original file with bzip2
both fix the issue. I think both pbzip2 and Compress are to blame here: pbzip2
apparently does something non-standard when compressing files, and Compress
should handle the non-standard format rather than pretending to be done
decompressing. Another option is that I'm doing something wrong; in that case
please let me know! :)
Here's how the problem can be reproduced:
1. Generate a file that's 90+ bytes large: dd if=/dev/zero of=1mbfile
count=1 bs=1M
2. Compress with pbzip2: pbzip2 1mbfile
3. Decompress with Bunzip2 class below
4. Notice how the resulting 1mbfile is 90 bytes large, not 1M.
Now compare to using bunzip2/bzip2:
- Do the steps above, but instead of 2, compress with bzip2: bzip2 1mbfile
- Do the steps above, but instead of 3, decompress with bunzip2: bunzip2
1mbfile.bz2
import java.io.*;
import org.apache.commons.compress.compressors.bzip2.*;
public class Bunzip2 {
public static void main(String[] args) throws Exception {
File inFile = new File(args[0]);
File outFile = new File(args[0].substring(0, args[0].length() - 4));
FileInputStream fis = new FileInputStream(inFile);
BZip2CompressorInputStream bz2cis =
new BZip2CompressorInputStream(fis);
BufferedInputStream bis = new BufferedInputStream(bz2cis);
BufferedOutputStream bos = new BufferedOutputStream(
new FileOutputStream(outFile));
int len;
byte[] data = new byte[1024];
while ((len = bis.read(data, 0, 1024)) >= 0) {
bos.write(data, 0, len);
}
bos.close();
bis.close();
}
}
--
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
