[jira] [Commented] (COMPRESS-277) IOUtils.skip does not work as advertised
[
https://issues.apache.org/jira/browse/COMPRESS-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980742#comment-13980742
]
Fabian Lange commented on COMPRESS-277:
---
Hi Beluga,
You are not correct. Buffering the Cipher Input stream will not work. Because
the BIS will also only invoke skip on the CIS. CIS will always only skip a
maximum of 512 bytes. This would leave the BIS with the same problem: It is not
at the correct position.
A client cannot skip an entry manually. How would we modify
getNextTarEntry() to use IOUtils#skip?
If compress would not use the now corrected implementation of skip, then the
API methods like getNextTar() entry would be broken, which is why i opened the
ticket in the first place.
IOUtils.skip does not work as advertised
Key: COMPRESS-277
URL: https://issues.apache.org/jira/browse/COMPRESS-277
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.8
Reporter: Fabian Lange
Fix For: 1.9
Attachments: TarArchiveInputStream.java.patch
I am trying to feed a TarInputStream from a CipherInputStream.
It does not work, because IOUtils.skip() does not adhere to the contract it
claims in javadoc:
* pThis method will only skip less than the requested number of
* bytes if the end of the input stream has been reached./p
However it does:
long skipped = input.skip(numToSkip);
if (skipped == 0) {
break;
}
And the input stream javadoc says:
* This may result from any of a number of conditions; reaching end of
file
* before coden/code bytes have been skipped is only one possibility.
In the case of CipherInputStream, it stops at the end of each byte buffer.
If you check the IOUtils from colleagues at commons-io, they have considered
this case in IOUtils.skip() where they use a read to skip through the stream.
An optimized version could combine trying to skip, then read then trying to
skip again.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COMPRESS-279) TarArchiveInputStream silently finished when unexpected EOF occured
[
https://issues.apache.org/jira/browse/COMPRESS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980853#comment-13980853
]
Stefan Bodewig commented on COMPRESS-279:
-
I see how my should ever have done so can be misunderstood. What I meant to
say is: of course there should be an exception but I don't see why the code has
ever thrown an exception. I.e. I don't see where the regression has been
introduced.
I'll look into this over the weekend, I've already added a unit test and it
doesn't throw any exception in trunk - so the changed skip alone won't help.
[~belugabehr]: on first glance your patch looks good, thanks.
TarArchiveInputStream silently finished when unexpected EOF occured
---
Key: COMPRESS-279
URL: https://issues.apache.org/jira/browse/COMPRESS-279
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.7, 1.8
Environment: Common Compress 1.7 + openJDK 1.7
Reporter: PeterL in
Labels: regression, tar
Fix For: 1.9
Attachments: TarArchiveInputStream.java.patch, complete.tar,
trim.tar, trim.tar.bz2
I just found the following test case didn't raise an IOException as it used
to be for a *tar trimmed on purpose*
@Test
public void testCorruptedBzip2() throws IOException {
String archivePath = PathUtil.join(testdataDir, test.tar.bz2);
TarArchiveInputStream input = null;
input = new TarArchiveInputStream(new BZip2CompressorInputStream(
GoogleFile.SYSTEM.newInputStream(archivePath), true));
ArchiveEntry nextMatchedEntry = input.getNextEntry();
while (nextMatchedEntry != null) {
logger.infofmt(Extracting %s, nextMatchedEntry.getName());
String outputPath = PathUtil.join(/tmp/, nextMatchedEntry.getName());
OutputStream out = new FileOutputStream(outputPath);
ByteStreams.copy(input, out);
out.close();
nextMatchedEntry = input.getNextEntry();
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COMPRESS-277) IOUtils.skip does not work as advertised
[
https://issues.apache.org/jira/browse/COMPRESS-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980879#comment-13980879
]
Stefan Bodewig commented on COMPRESS-277:
-
The problem is with things like consumeRemainderOfLastBlock or
skipRecordPadding which really need to consume all remaining data, even with a
BufferedReader this is not guaranteed to work as skip may return 0 all the time.
IOUtils.skip does not work as advertised
Key: COMPRESS-277
URL: https://issues.apache.org/jira/browse/COMPRESS-277
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.8
Reporter: Fabian Lange
Fix For: 1.9
Attachments: TarArchiveInputStream.java.patch
I am trying to feed a TarInputStream from a CipherInputStream.
It does not work, because IOUtils.skip() does not adhere to the contract it
claims in javadoc:
* pThis method will only skip less than the requested number of
* bytes if the end of the input stream has been reached./p
However it does:
long skipped = input.skip(numToSkip);
if (skipped == 0) {
break;
}
And the input stream javadoc says:
* This may result from any of a number of conditions; reaching end of
file
* before coden/code bytes have been skipped is only one possibility.
In the case of CipherInputStream, it stops at the end of each byte buffer.
If you check the IOUtils from colleagues at commons-io, they have considered
this case in IOUtils.skip() where they use a read to skip through the stream.
An optimized version could combine trying to skip, then read then trying to
skip again.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COMPRESS-279) TarArchiveInputStream silently finished when unexpected EOF occured
[
https://issues.apache.org/jira/browse/COMPRESS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980933#comment-13980933
]
BELUGA BEHR commented on COMPRESS-279:
--
It was probably in the TarBuffer class that I lopped out.
TarArchiveInputStream silently finished when unexpected EOF occured
---
Key: COMPRESS-279
URL: https://issues.apache.org/jira/browse/COMPRESS-279
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.7, 1.8
Environment: Common Compress 1.7 + openJDK 1.7
Reporter: PeterL in
Labels: regression, tar
Fix For: 1.9
Attachments: TarArchiveInputStream.java.patch, complete.tar,
trim.tar, trim.tar.bz2
I just found the following test case didn't raise an IOException as it used
to be for a *tar trimmed on purpose*
@Test
public void testCorruptedBzip2() throws IOException {
String archivePath = PathUtil.join(testdataDir, test.tar.bz2);
TarArchiveInputStream input = null;
input = new TarArchiveInputStream(new BZip2CompressorInputStream(
GoogleFile.SYSTEM.newInputStream(archivePath), true));
ArchiveEntry nextMatchedEntry = input.getNextEntry();
while (nextMatchedEntry != null) {
logger.infofmt(Extracting %s, nextMatchedEntry.getName());
String outputPath = PathUtil.join(/tmp/, nextMatchedEntry.getName());
OutputStream out = new FileOutputStream(outputPath);
ByteStreams.copy(input, out);
out.close();
nextMatchedEntry = input.getNextEntry();
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COMPRESS-277) IOUtils.skip does not work as advertised
[
https://issues.apache.org/jira/browse/COMPRESS-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980944#comment-13980944
]
BELUGA BEHR commented on COMPRESS-277:
--
Stefan, Fabian,
Please see my patch. I still maintain that it is the correct implementation.
I think we needs to keep the functionality geared for the generic case and keep
as closely to the expected InputStream behavior as possible.
consumeRemainderOfLastBlock - The last block is so small, hardly a factor
in this case. Chances are, the block of the Cipher will contain this
remainder as the remainder is, on average, 256 bytes.
How do you modify getNextTarEntry?
{code:title=Pseudo.java|borderStyle=solid}
CipherInputStream cis = new CipherInputStream ()
TarInputStream tis = new TarInputStream(cis);
while (tis.getNextEntry() != null)
{
// IO-Commons
IOUtils.skip(tis, Long.MAX_VALUE);
}
{code}
IOUtils.skip does not work as advertised
Key: COMPRESS-277
URL: https://issues.apache.org/jira/browse/COMPRESS-277
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.8
Reporter: Fabian Lange
Fix For: 1.9
Attachments: TarArchiveInputStream.java.patch
I am trying to feed a TarInputStream from a CipherInputStream.
It does not work, because IOUtils.skip() does not adhere to the contract it
claims in javadoc:
* pThis method will only skip less than the requested number of
* bytes if the end of the input stream has been reached./p
However it does:
long skipped = input.skip(numToSkip);
if (skipped == 0) {
break;
}
And the input stream javadoc says:
* This may result from any of a number of conditions; reaching end of
file
* before coden/code bytes have been skipped is only one possibility.
In the case of CipherInputStream, it stops at the end of each byte buffer.
If you check the IOUtils from colleagues at commons-io, they have considered
this case in IOUtils.skip() where they use a read to skip through the stream.
An optimized version could combine trying to skip, then read then trying to
skip again.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COMPRESS-277) IOUtils.skip does not work as advertised
[
https://issues.apache.org/jira/browse/COMPRESS-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980950#comment-13980950
]
Fabian Lange commented on COMPRESS-277:
---
That doesn't make sense.
The semantics of getNextEntry are so that it will seek you to the next entry.
compare to JDK ZipInputStream:
/**
* Reads the next ZIP file entry and positions the stream at the
* beginning of the entry data.
* @return the next ZIP file entry, or null if there are no more entries
* @exception ZipException if a ZIP file error has occurred
* @exception IOException if an I/O error has occurred
*/
public ZipEntry getNextEntry() throws IOException {
Also, why should the user now need to care about seeking the next entry? it
just doesnt make sense for me.
The defined api and code are fine! Its just that it was buggy in the case skip
did not skip as much as expected. That has been fixed, and I don't see a reason
to hijack this Ticket to completely change the semantics of the API.
IOUtils.skip does not work as advertised
Key: COMPRESS-277
URL: https://issues.apache.org/jira/browse/COMPRESS-277
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.8
Reporter: Fabian Lange
Fix For: 1.9
Attachments: TarArchiveInputStream.java.patch
I am trying to feed a TarInputStream from a CipherInputStream.
It does not work, because IOUtils.skip() does not adhere to the contract it
claims in javadoc:
* pThis method will only skip less than the requested number of
* bytes if the end of the input stream has been reached./p
However it does:
long skipped = input.skip(numToSkip);
if (skipped == 0) {
break;
}
And the input stream javadoc says:
* This may result from any of a number of conditions; reaching end of
file
* before coden/code bytes have been skipped is only one possibility.
In the case of CipherInputStream, it stops at the end of each byte buffer.
If you check the IOUtils from colleagues at commons-io, they have considered
this case in IOUtils.skip() where they use a read to skip through the stream.
An optimized version could combine trying to skip, then read then trying to
skip again.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (LANG-993) Add zero copy write methods to StrBuilder
[
https://issues.apache.org/jira/browse/LANG-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980969#comment-13980969
]
Benedikt Ritter commented on LANG-993:
--
[~ash2k]: sorry for the late reply. I was a bit busy lately. I understand your
concern, but I like the symmetry of only having {{writeTo(Appendable)}} and
{{read(Readable)}}. How about checking the actual type of the Appendable and if
it a Writer/StringBuilder/-Buffer, downcast and call the method that accepts
the array?
If we go this direction it my make sende to rename the methods to:
* {{appendTo(Appenedable)}} (may be confusing because it is so close to
{{append(...)}}
* {{readFrom(Readable)}}
WDYT?
Add zero copy write methods to StrBuilder
-
Key: LANG-993
URL: https://issues.apache.org/jira/browse/LANG-993
Project: Commons Lang
Issue Type: Improvement
Components: lang.text.*
Affects Versions: 3.3.1
Reporter: Mikhail Mazursky
Fix For: Review Patch, Discussion, 3.4
Attachments: LANG-993.patch
Currently I have the following usecase:
{code}
StrBuilder builder = new StrBuilder();
// add lots of stuff to builder
// in multiple invocations in several classes
// writer cannot be used directly
builder.append(...);
Writer writer = ;
CharStreams.copy(builder.asReader(), writer);
{code}
[CharStreams|https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/io/CharStreams.java#177]
is a class from Guava lib that copies data between reader and writer using
temporary buffer.
There is a problem with such approach - two additional copies are performed:
1) data is copied from the StrBuilder in chunks into temporary buffer
(CharBuffer)
2) Writer.append(CharSequence) is called that is usually implemented as
write(CharSequence.toString()) - i.e. it makes another copy of data and
allocates an additional String object.
I want to avoid those copies by writing the internal buffer of the StrBuilder
directly to the writer. Also it is potentially more efficient because it
performs one I/O call instead of many.
So I propose to add the following methods:
{code}
public void writeTo(Writer writer) throws IOException {
writer.write(buffer, 0, size);
}
public void writeTo(StringBuilder builder) {
builder.append(buffer, 0, size);
}
public void writeTo(StringBuffer buffer) {
buffer.append(this.buffer, 0, size);
}
{code}
If there is interest I will provide patch (with JavaDocs and tests).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (LANG-993) Add zero copy write methods to StrBuilder
[
https://issues.apache.org/jira/browse/LANG-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980969#comment-13980969
]
Benedikt Ritter edited comment on LANG-993 at 4/25/14 1:13 PM:
---
[~ash2k]: sorry for the late reply. I was a bit busy lately. I understand your
concern, but I like the symmetry of only having {{writeTo(Appendable)}} and
{{read(Readable)}}. How about checking the actual type of the Appendable and if
it a Writer/StringBuilder/-Buffer, downcast and call the method that accepts
the array?
If we go this direction it my make sende to rename the methods to:
* {{appendTo(Appenedable)}} (may be confusing because it is so close to
{{append(...)}}
* {{readFrom(Readable)}} EDIT: apparently in your patch in LANG-994 it is
already called readFrom
WDYT?
was (Author: britter):
[~ash2k]: sorry for the late reply. I was a bit busy lately. I understand your
concern, but I like the symmetry of only having {{writeTo(Appendable)}} and
{{read(Readable)}}. How about checking the actual type of the Appendable and if
it a Writer/StringBuilder/-Buffer, downcast and call the method that accepts
the array?
If we go this direction it my make sende to rename the methods to:
* {{appendTo(Appenedable)}} (may be confusing because it is so close to
{{append(...)}}
* {{readFrom(Readable)}}
WDYT?
Add zero copy write methods to StrBuilder
-
Key: LANG-993
URL: https://issues.apache.org/jira/browse/LANG-993
Project: Commons Lang
Issue Type: Improvement
Components: lang.text.*
Affects Versions: 3.3.1
Reporter: Mikhail Mazursky
Fix For: Review Patch, Discussion, 3.4
Attachments: LANG-993.patch
Currently I have the following usecase:
{code}
StrBuilder builder = new StrBuilder();
// add lots of stuff to builder
// in multiple invocations in several classes
// writer cannot be used directly
builder.append(...);
Writer writer = ;
CharStreams.copy(builder.asReader(), writer);
{code}
[CharStreams|https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/io/CharStreams.java#177]
is a class from Guava lib that copies data between reader and writer using
temporary buffer.
There is a problem with such approach - two additional copies are performed:
1) data is copied from the StrBuilder in chunks into temporary buffer
(CharBuffer)
2) Writer.append(CharSequence) is called that is usually implemented as
write(CharSequence.toString()) - i.e. it makes another copy of data and
allocates an additional String object.
I want to avoid those copies by writing the internal buffer of the StrBuilder
directly to the writer. Also it is potentially more efficient because it
performs one I/O call instead of many.
So I propose to add the following methods:
{code}
public void writeTo(Writer writer) throws IOException {
writer.write(buffer, 0, size);
}
public void writeTo(StringBuilder builder) {
builder.append(buffer, 0, size);
}
public void writeTo(StringBuffer buffer) {
buffer.append(this.buffer, 0, size);
}
{code}
If there is interest I will provide patch (with JavaDocs and tests).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (LANG-988) Where's the user guide?
[ https://issues.apache.org/jira/browse/LANG-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980973#comment-13980973 ] Benedikt Ritter commented on LANG-988: -- Maybe we should remove the User Guide page on the website or put some useful content there... I've though about something that gives you a better overview over the functionality provided in [LANG] alongside some code examples. Where's the user guide? --- Key: LANG-988 URL: https://issues.apache.org/jira/browse/LANG-988 Project: Commons Lang Issue Type: Bug Components: Website Affects Versions: 3.3 Reporter: Martin Schröder Priority: Minor The homepage claims A getting started user guide is available together with various project reports. The link for the user guide (https://commons.apache.org/proper/commons-lang/userguide.html) then says Looking for the User Guide? It has been moved to the package JavaDoc - and the JavaDoc link points to the javadoc, where I can't find a user guide (do you mean the package summary of lang3 (https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/package-summary.html#package_description)? Oh, and IMHO the website should be a component in jira. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-997) NumberUtil#isNumber() returns false for 012345678 but not for 12345678
[
https://issues.apache.org/jira/browse/LANG-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-997:
-
Fix Version/s: 3.4
Review Patch
NumberUtil#isNumber() returns false for 012345678 but not for 12345678
--
Key: LANG-997
URL: https://issues.apache.org/jira/browse/LANG-997
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.3.2
Environment: Java 6
Reporter: Juan Pablo Santos Rodríguez
Fix For: Review Patch, 3.4
With commons-lang 3.2.1:
{code}
boolean ret = NumberUtils.isNumber( 012345678901234567 );
{code}
returns {{true}}, but for 3.3.2, returns {{false}}.
The change seems to be introduced in LANG-972 / LANG-992, as it seems to
consider now that, if the parameter string has a leading 0, and it's not hex,
then it must be forcibly octal.
As previous 3.x versions accept 0ddd as valid decimal numbers, the suggested
change on NumberUtils#isNumber, is to replace lines
[1367-1376|http://commons.apache.org/proper/commons-lang/xref/org/apache/commons/lang3/math/NumberUtils.html#L1367]
with:
{code}
} else if (Character.isDigit(chars[start + 1])) {
// leading 0, but not hex, must be octal or decimal
int i = start + 1;
for (; i chars.length; i++) {
if (chars[i] '0' || chars[i] '9') { // was: if
(chars[i] '0' || chars[i] '7') {
return false;
}
}
return true;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (LANG-997) NumberUtil#isNumber() returns false for 012345678 but not for 12345678
[
https://issues.apache.org/jira/browse/LANG-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980974#comment-13980974
]
Benedikt Ritter commented on LANG-997:
--
Should be in the next release. Setting to 3.4.
NumberUtil#isNumber() returns false for 012345678 but not for 12345678
--
Key: LANG-997
URL: https://issues.apache.org/jira/browse/LANG-997
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.3.2
Environment: Java 6
Reporter: Juan Pablo Santos Rodríguez
Fix For: Review Patch, 3.4
With commons-lang 3.2.1:
{code}
boolean ret = NumberUtils.isNumber( 012345678901234567 );
{code}
returns {{true}}, but for 3.3.2, returns {{false}}.
The change seems to be introduced in LANG-972 / LANG-992, as it seems to
consider now that, if the parameter string has a leading 0, and it's not hex,
then it must be forcibly octal.
As previous 3.x versions accept 0ddd as valid decimal numbers, the suggested
change on NumberUtils#isNumber, is to replace lines
[1367-1376|http://commons.apache.org/proper/commons-lang/xref/org/apache/commons/lang3/math/NumberUtils.html#L1367]
with:
{code}
} else if (Character.isDigit(chars[start + 1])) {
// leading 0, but not hex, must be octal or decimal
int i = start + 1;
for (; i chars.length; i++) {
if (chars[i] '0' || chars[i] '9') { // was: if
(chars[i] '0' || chars[i] '7') {
return false;
}
}
return true;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-993) Add zero copy write methods to StrBuilder
[
https://issues.apache.org/jira/browse/LANG-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Mazursky updated LANG-993:
--
Attachment: LANG-993-994.patch
[~britter], I see now what you propose and I fully agree. Here is the new patch
for both this issue and LANG-994.
Add zero copy write methods to StrBuilder
-
Key: LANG-993
URL: https://issues.apache.org/jira/browse/LANG-993
Project: Commons Lang
Issue Type: Improvement
Components: lang.text.*
Affects Versions: 3.3.1
Reporter: Mikhail Mazursky
Assignee: Benedikt Ritter
Fix For: Review Patch, Discussion, 3.4
Attachments: LANG-993-994.patch, LANG-993.patch
Currently I have the following usecase:
{code}
StrBuilder builder = new StrBuilder();
// add lots of stuff to builder
// in multiple invocations in several classes
// writer cannot be used directly
builder.append(...);
Writer writer = ;
CharStreams.copy(builder.asReader(), writer);
{code}
[CharStreams|https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/io/CharStreams.java#177]
is a class from Guava lib that copies data between reader and writer using
temporary buffer.
There is a problem with such approach - two additional copies are performed:
1) data is copied from the StrBuilder in chunks into temporary buffer
(CharBuffer)
2) Writer.append(CharSequence) is called that is usually implemented as
write(CharSequence.toString()) - i.e. it makes another copy of data and
allocates an additional String object.
I want to avoid those copies by writing the internal buffer of the StrBuilder
directly to the writer. Also it is potentially more efficient because it
performs one I/O call instead of many.
So I propose to add the following methods:
{code}
public void writeTo(Writer writer) throws IOException {
writer.write(buffer, 0, size);
}
public void writeTo(StringBuilder builder) {
builder.append(buffer, 0, size);
}
public void writeTo(StringBuffer buffer) {
buffer.append(this.buffer, 0, size);
}
{code}
If there is interest I will provide patch (with JavaDocs and tests).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (LANG-997) NumberUtil#isNumber() returns false for 012345678 but not for 12345678
[
https://issues.apache.org/jira/browse/LANG-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981715#comment-13981715
]
Sebb commented on LANG-997:
---
I'm not sure we want to implement this.
At present, isNumber() agrees with Java constant syntax and the createNumber()
method in treating a leading 0 as meaning octal.
If leading zero is ignored, then isNumber() won't agree with createNumber() or
Java.
I think the current behaviour should be kept (and documented more thoroughly if
need be).
If there is a need to allow leading zeros, this could perhaps be done with a
new method - or by adding a second boolean parameter to select the new
behaviour.
NumberUtil#isNumber() returns false for 012345678 but not for 12345678
--
Key: LANG-997
URL: https://issues.apache.org/jira/browse/LANG-997
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.3.2
Environment: Java 6
Reporter: Juan Pablo Santos Rodríguez
Fix For: Review Patch, 3.4
With commons-lang 3.2.1:
{code}
boolean ret = NumberUtils.isNumber( 012345678901234567 );
{code}
returns {{true}}, but for 3.3.2, returns {{false}}.
The change seems to be introduced in LANG-972 / LANG-992, as it seems to
consider now that, if the parameter string has a leading 0, and it's not hex,
then it must be forcibly octal.
As previous 3.x versions accept 0ddd as valid decimal numbers, the suggested
change on NumberUtils#isNumber, is to replace lines
[1367-1376|http://commons.apache.org/proper/commons-lang/xref/org/apache/commons/lang3/math/NumberUtils.html#L1367]
with:
{code}
} else if (Character.isDigit(chars[start + 1])) {
// leading 0, but not hex, must be octal or decimal
int i = start + 1;
for (; i chars.length; i++) {
if (chars[i] '0' || chars[i] '9') { // was: if
(chars[i] '0' || chars[i] '7') {
return false;
}
}
return true;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (COMPRESS-277) IOUtils.skip does not work as advertised
[
https://issues.apache.org/jira/browse/COMPRESS-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981769#comment-13981769
]
BELUGA BEHR edited comment on COMPRESS-277 at 4/26/14 1:27 AM:
---
Yes! Sorry! I will move to a new ticket! I was confused in that I thought this
had direct changes to the TarInputStream class as I was looking at the wrong
revision. Thanks for bringing these issues to light!
I do admit that the code I suggested was a bit confusing, but I am trying to
help you. IOUtils#skip() from the commons-io package does not call the
stream's skip method, it only calls the stream's read. You may get better
results with the approach I suggested because it allows you to just skip the
'skip' process all together and just pass in a large read buffer allowing for
fewer iterations.
was (Author: belugabehr):
Yes! Sorry! I will move to a new ticket! I was confused in that I thought this
had direct changes to the TarInputStream class. Thanks for bringing these
issues to light!
I do admit that the code I suggested was a bit confusing, but I am trying to
help you. IOUtils#skip() from the commons-io package does not call the
stream's skip method, it only calls the stream's read. You may get better
results with the approach I suggested because it allows you to just skip the
'skip' process all together and just pass in a large read buffer allowing for
fewer iterations.
IOUtils.skip does not work as advertised
Key: COMPRESS-277
URL: https://issues.apache.org/jira/browse/COMPRESS-277
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.8
Reporter: Fabian Lange
Fix For: 1.9
Attachments: TarArchiveInputStream.java.patch
I am trying to feed a TarInputStream from a CipherInputStream.
It does not work, because IOUtils.skip() does not adhere to the contract it
claims in javadoc:
* pThis method will only skip less than the requested number of
* bytes if the end of the input stream has been reached./p
However it does:
long skipped = input.skip(numToSkip);
if (skipped == 0) {
break;
}
And the input stream javadoc says:
* This may result from any of a number of conditions; reaching end of
file
* before coden/code bytes have been skipped is only one possibility.
In the case of CipherInputStream, it stops at the end of each byte buffer.
If you check the IOUtils from colleagues at commons-io, they have considered
this case in IOUtils.skip() where they use a read to skip through the stream.
An optimized version could combine trying to skip, then read then trying to
skip again.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (COMPRESS-280) [COMPRESS] Change TarInputStream Skip Behavior
BELUGA BEHR created COMPRESS-280:
Summary: [COMPRESS] Change TarInputStream Skip Behavior
Key: COMPRESS-280
URL: https://issues.apache.org/jira/browse/COMPRESS-280
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Affects Versions: 1.8
Reporter: BELUGA BEHR
Priority: Minor
Fix For: 1.9
Attachments: TarArchiveInputStream.java.patch
InputStream#skip declares:
{quote}
Skips over and discards n bytes of data from this input stream. The skip method
may, for a variety of reasons, end up skipping over some smaller number of
bytes, possibly 0. This may result from any of a number of conditions;
reaching end of file before n bytes have been skipped is only one possibility.
The actual number of bytes skipped is returned. If n is negative, no bytes are
skipped.
{quote}
I would recommend doing away with the call to the local IOUtils in the Stream's
skip method and just call skip directly on the underlying stream. I'd also
amend the JavaDoc to say end up skipping .. some smaller number of bytes...
reaching the end of the current entry. The stream is not required to make any
best-effort. For your example, there should be a BufferedInputStream between
the TarInputStream and the CipherInputStream. This would put it more in line
with all other InputStreams.
If a client wants to skip an entry manually, they would have to call Commons-IO
IOUtils#skipFully, IOUtils#skip, etc.
You would then have to modify getNextTarEntry() to call the IOUtils#skip method.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (COMPRESS-280) [COMPRESS] Change TarInputStream Skip Behavior
[
https://issues.apache.org/jira/browse/COMPRESS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated COMPRESS-280:
-
Attachment: TarArchiveInputStream.java.patch
[COMPRESS] Change TarInputStream Skip Behavior
--
Key: COMPRESS-280
URL: https://issues.apache.org/jira/browse/COMPRESS-280
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Affects Versions: 1.8
Reporter: BELUGA BEHR
Priority: Minor
Fix For: 1.9
Attachments: TarArchiveInputStream.java.patch
InputStream#skip declares:
{quote}
Skips over and discards n bytes of data from this input stream. The skip
method may, for a variety of reasons, end up skipping over some smaller
number of bytes, possibly 0. This may result from any of a number of
conditions; reaching end of file before n bytes have been skipped is only one
possibility. The actual number of bytes skipped is returned. If n is
negative, no bytes are skipped.
{quote}
I would recommend doing away with the call to the local IOUtils in the
Stream's skip method and just call skip directly on the underlying stream.
I'd also amend the JavaDoc to say end up skipping .. some smaller number of
bytes... reaching the end of the current entry. The stream is not required
to make any best-effort. For your example, there should be a
BufferedInputStream between the TarInputStream and the CipherInputStream.
This would put it more in line with all other InputStreams.
If a client wants to skip an entry manually, they would have to call
Commons-IO IOUtils#skipFully, IOUtils#skip, etc.
You would then have to modify getNextTarEntry() to call the IOUtils#skip
method.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (COMPRESS-277) IOUtils.skip does not work as advertised
[
https://issues.apache.org/jira/browse/COMPRESS-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated COMPRESS-277:
-
Attachment: (was: TarArchiveInputStream.java.patch)
IOUtils.skip does not work as advertised
Key: COMPRESS-277
URL: https://issues.apache.org/jira/browse/COMPRESS-277
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.8
Reporter: Fabian Lange
Fix For: 1.9
I am trying to feed a TarInputStream from a CipherInputStream.
It does not work, because IOUtils.skip() does not adhere to the contract it
claims in javadoc:
* pThis method will only skip less than the requested number of
* bytes if the end of the input stream has been reached./p
However it does:
long skipped = input.skip(numToSkip);
if (skipped == 0) {
break;
}
And the input stream javadoc says:
* This may result from any of a number of conditions; reaching end of
file
* before coden/code bytes have been skipped is only one possibility.
In the case of CipherInputStream, it stops at the end of each byte buffer.
If you check the IOUtils from colleagues at commons-io, they have considered
this case in IOUtils.skip() where they use a read to skip through the stream.
An optimized version could combine trying to skip, then read then trying to
skip again.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (LANG-997) NumberUtil#isNumber() returns false for 012345678 but not for 12345678
[
https://issues.apache.org/jira/browse/LANG-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981869#comment-13981869
]
Henri Yandell commented on LANG-997:
Summarizing - the issue isn't that 0123 is bad, but that 012345678901234567 is
too big for Java.
In the same way, 0xfff should return false. It
currently returns true.
Also 9e is too large, but returns true currently.
I'm +1 to considering this a regression and accepting an isNumber that can
handle numbers larger than Java is prepared to handle. ie) Fixing this bug.
NumberUtil#isNumber() returns false for 012345678 but not for 12345678
--
Key: LANG-997
URL: https://issues.apache.org/jira/browse/LANG-997
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.3.2
Environment: Java 6
Reporter: Juan Pablo Santos Rodríguez
Fix For: Review Patch, 3.4
With commons-lang 3.2.1:
{code}
boolean ret = NumberUtils.isNumber( 012345678901234567 );
{code}
returns {{true}}, but for 3.3.2, returns {{false}}.
The change seems to be introduced in LANG-972 / LANG-992, as it seems to
consider now that, if the parameter string has a leading 0, and it's not hex,
then it must be forcibly octal.
As previous 3.x versions accept 0ddd as valid decimal numbers, the suggested
change on NumberUtils#isNumber, is to replace lines
[1367-1376|http://commons.apache.org/proper/commons-lang/xref/org/apache/commons/lang3/math/NumberUtils.html#L1367]
with:
{code}
} else if (Character.isDigit(chars[start + 1])) {
// leading 0, but not hex, must be octal or decimal
int i = start + 1;
for (; i chars.length; i++) {
if (chars[i] '0' || chars[i] '9') { // was: if
(chars[i] '0' || chars[i] '7') {
return false;
}
}
return true;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-341) Add number to byte array methods
[
https://issues.apache.org/jira/browse/LANG-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-341:
---
Fix Version/s: (was: 3.x)
Discussion
Add number to byte array methods
Key: LANG-341
URL: https://issues.apache.org/jira/browse/LANG-341
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Lilianne E. Blaze
Assignee: Duncan Jones
Fix For: Discussion
Attachments: 341-v1-src.patch, 341-v1-test.patch, LANG-341-2.patch,
LANG-341.patch
Hello,
I need a set of methods to convert Long to or from a byte[] array, as if
writing / reading from Data(Input/Output)Stream(
ByteArray(Input/Output)Stream ).
First, doing it with Streams seems a bit wasteful, second, it seems a
pretty general use. Would it be possible to add something like that to,
for example,
org.apache.commons.lang.math.NumberUtils?
Example code:
{code:java}
static public long toLong(byte[] b)
{
return toLong(b, 0);
}
static public long toLong(byte[] b, int offset)
{
return (((long)b[offset] 56) +
((long)(b[offset + 1] 255) 48) +
((long)(b[offset + 2] 255) 40) +
((long)(b[offset + 3] 255) 32) +
((long)(b[offset + 4] 255) 24) +
((b[offset + 5] 255) 16) +
((b[offset + 6] 255) 8) +
((b[offset + 7] 255) 0));
}
static public byte[] longToByteArray(long l)
{
byte b[] = new byte[8];
longToByteArray(l, b, 0);
return b;
}
static public void longToByteArray(long l, byte b[], int offset)
{
b[offset] = (byte)(l 56);
b[offset + 1] = (byte)(l 48);
b[offset + 2] = (byte)(l 40);
b[offset + 3] = (byte)(l 32);
b[offset + 4] = (byte)(l 24);
b[offset + 5] = (byte)(l 16);
b[offset + 6] = (byte)(l 8);
b[offset + 7] = (byte)(l 0);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
