[jira] Updated: (CODEC-92) Many test cases use getBytes() which uses the default platform encoding so tests may fail on some platforms
[ https://issues.apache.org/jira/browse/CODEC-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CODEC-92: -- Fix Version/s: 1.5 Many test cases use getBytes() which uses the default platform encoding so tests may fail on some platforms --- Key: CODEC-92 URL: https://issues.apache.org/jira/browse/CODEC-92 Project: Commons Codec Issue Type: Bug Affects Versions: 1.4 Reporter: Sebb Priority: Minor Fix For: 1.5 Many test cases use getBytes() or new .String(byte[] bytes). These both use the default platform encoding so the tests may fail on some platforms. The tests should either use a known encoding (e.g. UTF-8) or should use bytes directly (e.g. 'h','e','l','l','o' instead of hello.getBytes()) There don't seem to be any examples of such method calls in the main code, so the priority has been set to minor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CODEC-92) Many test cases use getBytes() which uses the default platform encoding so tests may fail on some platforms
[ https://issues.apache.org/jira/browse/CODEC-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved CODEC-92. --- Resolution: Fixed There are no calls to getBytes(). This seems to have been addressed a while back. Many test cases use getBytes() which uses the default platform encoding so tests may fail on some platforms --- Key: CODEC-92 URL: https://issues.apache.org/jira/browse/CODEC-92 Project: Commons Codec Issue Type: Bug Affects Versions: 1.4 Reporter: Sebb Priority: Minor Fix For: 1.5 Many test cases use getBytes() or new .String(byte[] bytes). These both use the default platform encoding so the tests may fail on some platforms. The tests should either use a known encoding (e.g. UTF-8) or should use bytes directly (e.g. 'h','e','l','l','o' instead of hello.getBytes()) There don't seem to be any examples of such method calls in the main code, so the priority has been set to minor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-494) FastMath atan2 does not agree with StrictMath for special cases
[ https://issues.apache.org/jira/browse/MATH-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved MATH-494. --- Resolution: Fixed FastMath atan2 does not agree with StrictMath for special cases --- Key: MATH-494 URL: https://issues.apache.org/jira/browse/MATH-494 Project: Commons Math Issue Type: Bug Reporter: Sebb Fix For: 2.2, 3.0 FastMath atan2 does not agree with StrictMath for special cases. There are two sign problems: atan2(double -0.0, double -Infinity) expected -3.141592653589793 actual 3.141592653589793 entries [1, 4] atan2(double -0.0, double Infinity) expected -0.0 actual 0.0 entries [1, 5] A lot of NaNs where there should be a valid return: atan2(double -1.7976931348623157E308, double -1.7976931348623157E308) expected -2.356194490192345 actual NaN entries [6, 6] atan2(double -1.7976931348623157E308, double 1.7976931348623157E308) expected -0.7853981633974483 actual NaN entries [6, 7] atan2(double -1.7976931348623157E308, double -1.1102230246251565E-16) expected -1.5707963267948968 actual NaN entries [6, 8] atan2(double -1.7976931348623157E308, double 1.1102230246251565E-16) expected -1.5707963267948966 actual NaN entries [6, 9] atan2(double -1.7976931348623157E308, double -2.2250738585072014E-308) expected -1.5707963267948968 actual NaN entries [6, 10] atan2(double -1.7976931348623157E308, double 2.2250738585072014E-308) expected -1.5707963267948966 actual NaN entries [6, 11] atan2(double -1.7976931348623157E308, double -4.9E-324) expected -1.5707963267948968 actual NaN entries [6, 12] atan2(double -1.7976931348623157E308, double 4.9E-324) expected -1.5707963267948966 actual NaN entries [6, 13] atan2(double 1.7976931348623157E308, double -1.7976931348623157E308) expected 2.356194490192345 actual NaN entries [7, 6] atan2(double 1.7976931348623157E308, double 1.7976931348623157E308) expected 0.7853981633974483 actual NaN entries [7, 7] atan2(double 1.7976931348623157E308, double -1.1102230246251565E-16) expected 1.5707963267948968 actual NaN entries [7, 8] atan2(double 1.7976931348623157E308, double 1.1102230246251565E-16) expected 1.5707963267948966 actual NaN entries [7, 9] atan2(double 1.7976931348623157E308, double -2.2250738585072014E-308) expected 1.5707963267948968 actual NaN entries [7, 10] atan2(double 1.7976931348623157E308, double 2.2250738585072014E-308) expected 1.5707963267948966 actual NaN entries [7, 11] atan2(double 1.7976931348623157E308, double -4.9E-324) expected 1.5707963267948968 actual NaN entries [7, 12] atan2(double 1.7976931348623157E308, double 4.9E-324) expected 1.5707963267948966 actual NaN entries [7, 13] atan2(double -1.1102230246251565E-16, double -1.7976931348623157E308) expected -3.141592653589793 actual NaN entries [8, 6] atan2(double -1.1102230246251565E-16, double 1.7976931348623157E308) expected -0.0 actual NaN entries [8, 7] atan2(double -1.1102230246251565E-16, double -4.9E-324) expected -1.5707963267948968 actual NaN entries [8, 12] atan2(double -1.1102230246251565E-16, double 4.9E-324) expected -1.5707963267948966 actual NaN entries [8, 13] atan2(double 1.1102230246251565E-16, double -1.7976931348623157E308) expected 3.141592653589793 actual NaN entries [9, 6] atan2(double 1.1102230246251565E-16, double 1.7976931348623157E308) expected 0.0 actual NaN entries [9, 7] atan2(double 1.1102230246251565E-16, double -4.9E-324) expected 1.5707963267948968 actual NaN entries [9, 12] atan2(double 1.1102230246251565E-16, double 4.9E-324) expected 1.5707963267948966 actual NaN entries [9, 13] atan2(double -2.2250738585072014E-308, double -1.7976931348623157E308) expected -3.141592653589793 actual NaN entries [10, 6] atan2(double -2.2250738585072014E-308, double 1.7976931348623157E308) expected -0.0 actual NaN entries [10, 7] atan2(double 2.2250738585072014E-308, double -1.7976931348623157E308) expected 3.141592653589793 actual NaN entries [11, 6] atan2(double 2.2250738585072014E-308, double 1.7976931348623157E308) expected 0.0 actual NaN entries [11, 7] atan2(double -4.9E-324, double -1.7976931348623157E308) expected -3.141592653589793 actual NaN entries [12, 6] atan2(double -4.9E-324, double 1.7976931348623157E308) expected -0.0 actual NaN entries [12, 7] atan2(double 4.9E-324, double -1.7976931348623157E308) expected 3.141592653589793 actual NaN entries [13, 6] atan2(double 4.9E-324, double 1.7976931348623157E308) expected 0.0 actual NaN entries [13, 7] There are also some spurious errors, which are due to a bug in the test case - expecting the values to be exactly the same as StrictMath atan2(double 2.2250738585072014E-308, double -4.9E-324) expected 1.570796326794897 actual 1.5707963267948968 entries [11, 12] atan2(double
[jira] Created: (MATH-495) Implement StrictMath @since 1.6 methods
Implement StrictMath @since 1.6 methods --- Key: MATH-495 URL: https://issues.apache.org/jira/browse/MATH-495 Project: Commons Math Issue Type: New Feature Reporter: Sebb Fix For: 2.2, 3.0 It would be useful to implement at least some of the additional methods from StrictMath in Java 1.6. These are: public static double java.lang.StrictMath.scalb(double,int) public static float java.lang.StrictMath.scalb(float,int) public static int java.lang.StrictMath.getExponent(float) public static int java.lang.StrictMath.getExponent(double) public static double java.lang.StrictMath.copySign(double,double) public static float java.lang.StrictMath.copySign(float,float) This is a holding issue; will create sub tasks for each pair of methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-496) Create FastMath copySign methods
Create FastMath copySign methods Key: MATH-496 URL: https://issues.apache.org/jira/browse/MATH-496 Project: Commons Math Issue Type: Sub-task Reporter: Sebb Fix For: 2.2, 3.0 The copySIgn methods are simple to implement and will be useful in preserving signs in calculations with FastMath. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-496) Create FastMath copySign methods
[ https://issues.apache.org/jira/browse/MATH-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved MATH-496. --- Resolution: Fixed Create FastMath copySign methods Key: MATH-496 URL: https://issues.apache.org/jira/browse/MATH-496 Project: Commons Math Issue Type: Sub-task Reporter: Sebb Fix For: 2.2, 3.0 The copySIgn methods are simple to implement and will be useful in preserving signs in calculations with FastMath. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-497) Create FastMath .getExponent methods
Create FastMath .getExponent methods Key: MATH-497 URL: https://issues.apache.org/jira/browse/MATH-497 Project: Commons Math Issue Type: Sub-task Reporter: Sebb Fix For: 2.2, 3.0 getExponent - returns the unbiased exponent used in the representation of a floating point number -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-498) Create FastMath .scalb methods
Create FastMath .scalb methods -- Key: MATH-498 URL: https://issues.apache.org/jira/browse/MATH-498 Project: Commons Math Issue Type: Sub-task Reporter: Sebb scalb(n,m) = n * 2**m -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-497) Create FastMath .getExponent methods
[ https://issues.apache.org/jira/browse/MATH-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-497: -- Fix Version/s: (was: 3.0) (was: 2.2) Create FastMath .getExponent methods Key: MATH-497 URL: https://issues.apache.org/jira/browse/MATH-497 Project: Commons Math Issue Type: Sub-task Reporter: Sebb getExponent - returns the unbiased exponent used in the representation of a floating point number -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-672) Doc bug in DateUtils#ceiling
[
https://issues.apache.org/jira/browse/LANG-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-672.
--
Resolution: Fixed
Thanks for noticing that Gergely.
svn ci -m Fixing javadoc for DateUtils.ceiling per LANG-672
src/main/java/org/apache/commons/lang3/time/DateUtils.java
src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java
Sendingsrc/main/java/org/apache/commons/lang3/time/DateUtils.java
Sendingsrc/test/java/org/apache/commons/lang3/time/DateUtilsTest.java
Transmitting file data ..
Committed revision 1062326.
Doc bug in DateUtils#ceiling
Key: LANG-672
URL: https://issues.apache.org/jira/browse/LANG-672
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.5
Reporter: Gergely Kontra
Priority: Trivial
Fix For: 3.0
Original Estimate: 0.17h
Remaining Estimate: 0.17h
{quote}{noformat}For example, if you had the datetime of 28 Mar 2002
* 13:45:01.231, if you passed with HOUR, it would return 28 Mar
* 2002 13:00:00.000. If this was passed with MONTH, it would
* return 1 Mar 2002 0:00:00.000. {noformat}{quote}
Looks like copy-paste from truncate. (the dates are incorrect)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-338) truncateNicely method which avoids truncating in the middle of a word
[ https://issues.apache.org/jira/browse/LANG-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985252#action_12985252 ] Henri Yandell edited comment on LANG-338 at 1/23/11 12:29 AM: -- Noting that LANG-673 noticed that StringUtils already had an abbreviate method. This (WordUtils.abbreviate) has been removed for LANG 3.0. was (Author: bayard): Noting that LANG-673 noticed that StringUtils already had an abbreviate method. This has been removed for LANG 3.0. truncateNicely method which avoids truncating in the middle of a word - Key: LANG-338 URL: https://issues.apache.org/jira/browse/LANG-338 Project: Commons Lang Issue Type: New Feature Reporter: matt humphreys Priority: Trivial Fix For: 2.4 Attachments: LANG-338-cleaned.patch, LANG-338.patch as provided by jakarta string taglib. It would be good if this was part of commons as it doesn't make sense to use a taglib jar for non-web projects. The taglib javadoc says: ...It will search for the first space after the lower limit and truncate the string there. It will also append any string passed as a parameter to the end of the string. The hard limit can be specified to forcibily truncate a string (in the case of an extremely long word or such)... http://jakarta.apache.org/taglibs/doc/string-doc/string-1.1.0/javadoc/org/apache/taglibs/string/util/StringW.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-338) truncateNicely method which avoids truncating in the middle of a word
[ https://issues.apache.org/jira/browse/LANG-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985252#action_12985252 ] Henri Yandell commented on LANG-338: Noting that LANG-673 noticed that StringUtils already had an abbreviate method. This has been removed for LANG 3.0. truncateNicely method which avoids truncating in the middle of a word - Key: LANG-338 URL: https://issues.apache.org/jira/browse/LANG-338 Project: Commons Lang Issue Type: New Feature Reporter: matt humphreys Priority: Trivial Fix For: 2.4 Attachments: LANG-338-cleaned.patch, LANG-338.patch as provided by jakarta string taglib. It would be good if this was part of commons as it doesn't make sense to use a taglib jar for non-web projects. The taglib javadoc says: ...It will search for the first space after the lower limit and truncate the string there. It will also append any string passed as a parameter to the end of the string. The hard limit can be specified to forcibily truncate a string (in the case of an extremely long word or such)... http://jakarta.apache.org/taglibs/doc/string-doc/string-1.1.0/javadoc/org/apache/taglibs/string/util/StringW.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-673) WordUtils.abbreviate() throws undocumented StringIndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LANG-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985254#action_12985254 ] Henri Yandell commented on LANG-673: I don't think so. I've removed the WordUtils.abbreviate version as it's the newer of the pair. svn ci -m Removing WordUtils.abbreviate as it's already found in StringUtils.abbreviate. This was identified in LANG-673 src/main/java/org/apache/commons/lang3/text/WordUtils.java src/test/java/org/apache/commons/lang3/text/WordUtilsTest.java Sendingsrc/main/java/org/apache/commons/lang3/text/WordUtils.java Sendingsrc/test/java/org/apache/commons/lang3/text/WordUtilsTest.java Transmitting file data .. Committed revision 1062328. Leaving this open to discuss whether the StringUtils.abbreviate method is preferred in WordUtils. WordUtils.abbreviate() throws undocumented StringIndexOutOfBoundsException -- Key: LANG-673 URL: https://issues.apache.org/jira/browse/LANG-673 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.5 Reporter: Paul Benedict Fix For: 3.0 The javadoc does not indicate that the string must already be long enough to abbreviate; yet it really does or an Exception is thrown. For example, if you try to abbreviate a string of length 10 at 40 characters, this will fail. I believe this should be allowed... just without any abbreviation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CODEC-99) Base64.encodeBase64String() shouldn't chunk
[
https://issues.apache.org/jira/browse/CODEC-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julius Davies resolved CODEC-99.
Resolution: Fixed
Fix Version/s: 1.5
I applied codec-99.patch and codec-99-tests.patch. Quick summary of
consequences:
1. Another binary incompatibility with codec-1.4.jar is introduced with this.
2. But now the String static encode in 1.4 is more consistent with the
pre-existing byte[] static encode methods from 1.3, 1.2, 1.1.
Base64.encodeBase64String() shouldn't chunk
---
Key: CODEC-99
URL: https://issues.apache.org/jira/browse/CODEC-99
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Julius Davies
Fix For: 1.5
Attachments: codec-99-test-fixes.patch, codec-99-tests.patch,
codec-99.patch
Base64.encodeBase64String() shouldn't chunk.
Change this:
{code}
public static String encodeBase64String(byte[] binaryData) {
return StringUtils.newStringUtf8(encodeBase64(binaryData, true));
}
{code}
To this:
{code}
public static String encodeBase64String(byte[] binaryData) {
return StringUtils.newStringUtf8(encodeBase64(binaryData, false));
}
{code}
This will fix the following tests ggregory added a few minutes ago:
//assertEquals(Zg==,
Base64.encodeBase64String(StringUtils.getBytesUtf8(f)));
//assertEquals(Zm8=,
Base64.encodeBase64String(StringUtils.getBytesUtf8(fo)));
//assertEquals(Zm9v,
Base64.encodeBase64String(StringUtils.getBytesUtf8(foo)));
//assertEquals(Zm9vYg==,
Base64.encodeBase64String(StringUtils.getBytesUtf8(foob)));
//assertEquals(Zm9vYmE=,
Base64.encodeBase64String(StringUtils.getBytesUtf8(fooba)));
//assertEquals(Zm9vYmFy,
Base64.encodeBase64String(StringUtils.getBytesUtf8(foobar)));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-624) SystemUtils.getJavaVersionAsFloat throws StringIndexOutOfBoundsException on Android runtime/Dalvik VM
[
https://issues.apache.org/jira/browse/LANG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985258#action_12985258
]
Henri Yandell commented on LANG-624:
Digging deeper into SystemUtils and specifically what I think should change:
JAVA_VERSION: Keep as is. It's fair to expect it to point to java.version. That
that is the vendor version should be noted in the javadoc.
JAVA_VERSION_TRIMMED: We shouldn't be trying to parse the specification version
out of java.version. Remove this.
getJavaVersionTrimmed(): Private method for the above. Also remove.
JAVA_VERSION_FLOAT: This now becomes impossible. Remove this - I don't think
there's huge need to have code only run on 1.6.1 of a JVM. Sure it might be a
good way to get around some bug in 1.6.0, but the code becomes inherently
unportable.
JAVA_VERSION_INT: Same as above. Remove.
getJavaVersionMatches: Move this over to using JAVA_SPECIFICATION_VERSION.
isJavaVersionAtLeast: Move to spec version. This means having a private Float
version(?). Drop the int variant of this method as it's silly to pass in 13
instead of 1.3. In general this is a silly method; the better solution imo
would be to have a JAVA_1_2 enum :) I wonder if that's something we should
consider for all of the IS_XYZ 'constants'?
SystemUtils.getJavaVersionAsFloat throws StringIndexOutOfBoundsException on
Android runtime/Dalvik VM
-
Key: LANG-624
URL: https://issues.apache.org/jira/browse/LANG-624
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 2.5
Reporter: Travis Truman
Fix For: 3.0
Attachments: AndriodJavaVersion.png
Can be replicated in the Android emulator quite easily.
Stack trace:
{noformat}
at
org.apache.commons.lang.builder.ToStringBuilder.clinit(ToStringBuilder.java:98)
E/AndroidRuntime( 1681): ... 17 more
E/AndroidRuntime( 1681): Caused by: java.lang.ExceptionInInitializerError
E/AndroidRuntime( 1681): at
org.apache.commons.lang.builder.ToStringStyle$MultiLineToStringStyle.init(ToStringStyle.java:2276)
E/AndroidRuntime( 1681): at
org.apache.commons.lang.builder.ToStringStyle.clinit(ToStringStyle.java:94)
E/AndroidRuntime( 1681): ... 18 more
E/AndroidRuntime( 1681): Caused by: java.lang.StringIndexOutOfBoundsException
E/AndroidRuntime( 1681): at java.lang.String.substring(String.java:1571)
E/AndroidRuntime( 1681): at
org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1153)
E/AndroidRuntime( 1681): at
org.apache.commons.lang.SystemUtils.clinit(SystemUtils.java:818)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CODEC-8) REQ: Streaming codecs
[
https://issues.apache.org/jira/browse/CODEC-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julius Davies closed CODEC-8.
-
Resolution: Fixed
Closing this ticket in the hope the the streaming Base64 encoding/decoding
added back in 1.4 is good enough for most people!
Adding streaming to all the other codecs would be neat, but it's probably a lot
of work! Let's close this ticket for now and wait and see if people ever want
other codecs to be Stream-oriented.
REQ: Streaming codecs
-
Key: CODEC-8
URL: https://issues.apache.org/jira/browse/CODEC-8
Project: Commons Codec
Issue Type: Improvement
Affects Versions: 1.2
Environment: Operating System: All
Platform: All
Reporter: Sergei S. Ivanov
Fix For: 1.x
Attachments: Base64.diff
I would really appreciate if, for example, Base64 encoder could operate on
streams. One reason is that it's much easier to attach ByteArrayInputStream to
an array of bytes that to copy a byte array into a stream. The other reason is
greater flexibility, given by the streams.
I'd suggest creating a pair of new interfaces:
public interface StreamingDecoder implements Decoder {
public void decode(InputStream in, OutputStream out) throws
DecoderException;
}
public interface StreamingEncoder implements Encoder {
public void encode(InputStream in, OutputStream out) throws
EncoderException;
}
Base64 and Hex will then be able to implement these interfaces.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CODEC-104) Please add a function for the classical Unix crypt(3) hash
[ https://issues.apache.org/jira/browse/CODEC-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985260#action_12985260 ] Julius Davies commented on CODEC-104: - +1 to o.a.c.c.unix!Gary, do you want to just pull whatever code is currently in directory.apache.org ? Please add a function for the classical Unix crypt(3) hash -- Key: CODEC-104 URL: https://issues.apache.org/jira/browse/CODEC-104 Project: Commons Codec Issue Type: New Feature Reporter: Christian Hammers The Sun Java APIs lack a function for the classical Unix crypt(3) hash that was used in e.g. /etc/passwd or Apache htpasswd and is still widely used dispite the availablitity of better algorithms like MD5 or SHA. Apart from me cursing Sun for producing monster crypto APIs but missing the little things that one really needs, there are already several Apache projects that implemented UnixCrypt for their own: org.apache.directory.studio.ldapbrowser.core.utils.UnixCrypt org.apache.fulcrum.crypto.impl.UnixCrypt and maybe others bye, -christian- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CODEC-95) Base64: optionally allow strict parsing of base64 strings
[
https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985261#action_12985261
]
Julius Davies commented on CODEC-95:
Just call Base64.isArrayByteBase64(byte[] arrayOctet) on your data first!
For very large data sources where streaming is necessary I would be open to an
InputStream decorator (e.g. RejectingInputStream.java). Personally I'm against
adding this kind of thing directly into the Base64 code base because we already
support too many variations:
{code}
// too many variations!
public Base64InputStream(InputStream in, boolean doEncode, int lineLength,
byte[] lineSeparator) {
{code}
One thing we could do to make your life easier is introduce a version of
Base64.isBase64() that takes a String instead of byte[]. I'll open a ticket
for that.
Base64: optionally allow strict parsing of base64 strings
-
Key: CODEC-95
URL: https://issues.apache.org/jira/browse/CODEC-95
Project: Commons Codec
Issue Type: Improvement
Affects Versions: 1.4
Reporter: Adam Rabung
Priority: Minor
Attachments: strictMode.zip
Currently, Codec skips base64 characters that are outside of the encode
table. I realize this is perfectly to spec, but I wonder if other users
might appreciate a strict mode that throws an exception when one of these
illegal characters are encountered. For example, I would love an exception
to be thrown here:
new Base64().decode(!@#$ iHaveIllegalCharsAtBeginningAndEnd %^));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CODEC-110) Add a String version of Base64.isBase64()
Add a String version of Base64.isBase64() - Key: CODEC-110 URL: https://issues.apache.org/jira/browse/CODEC-110 Project: Commons Codec Issue Type: New Feature Reporter: Julius Davies Assignee: Julius Davies Priority: Trivial Fix For: 1.5 Add a String version of Base64.isBase64(). Right now we just have a byte[] version. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-462) FastDateFormat supports parse
[ https://issues.apache.org/jira/browse/LANG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985262#action_12985262 ] Henri Yandell commented on LANG-462: One failed test (line :294) is due to a missing 'Z' in the format text. You have to keep the timezone there if you expect to go from date to string and back again. Easy fix. The other seems to be due to weakness in SimpleDateFormat(line :349)(?). For pattern G/y/M/d/a/E, I get output of ??/03/2/9/??/?. That is, 'G', 'a' and 'E' all seeming to fail when called on the JDK's SimpleDateFormat. Seems odd - might be an OS X thing. For pattern /////, I get ??/2003/2?/0009/??/???. FastDateFormat supports parse - Key: LANG-462 URL: https://issues.apache.org/jira/browse/LANG-462 Project: Commons Lang Issue Type: New Feature Components: lang.time.* Reporter: Franz Wong Fix For: 3.0 Attachments: lang462.patch, UseFormatCache.patch Currently FastDateFormat only supports formatting the ISO8601 time zone, however, it doesn't support parsing such string to Date. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-462) FastDateFormat supports parse
[ https://issues.apache.org/jira/browse/LANG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-462: --- Attachment: LANG-462-Hen.patch Attaching my current state. FastDateFormat supports parse - Key: LANG-462 URL: https://issues.apache.org/jira/browse/LANG-462 Project: Commons Lang Issue Type: New Feature Components: lang.time.* Reporter: Franz Wong Fix For: 3.0 Attachments: LANG-462-Hen.patch, lang462.patch, UseFormatCache.patch Currently FastDateFormat only supports formatting the ISO8601 time zone, however, it doesn't support parsing such string to Date. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-624) SystemUtils.getJavaVersionAsFloat throws StringIndexOutOfBoundsException on Android runtime/Dalvik VM
[
https://issues.apache.org/jira/browse/LANG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985264#action_12985264
]
Stephen Colebourne commented on LANG-624:
-
We shouldn't remove the float/int methods. They are the useful ones!
SystemUtils.getJavaVersionAsFloat throws StringIndexOutOfBoundsException on
Android runtime/Dalvik VM
-
Key: LANG-624
URL: https://issues.apache.org/jira/browse/LANG-624
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 2.5
Reporter: Travis Truman
Fix For: 3.0
Attachments: AndriodJavaVersion.png
Can be replicated in the Android emulator quite easily.
Stack trace:
{noformat}
at
org.apache.commons.lang.builder.ToStringBuilder.clinit(ToStringBuilder.java:98)
E/AndroidRuntime( 1681): ... 17 more
E/AndroidRuntime( 1681): Caused by: java.lang.ExceptionInInitializerError
E/AndroidRuntime( 1681): at
org.apache.commons.lang.builder.ToStringStyle$MultiLineToStringStyle.init(ToStringStyle.java:2276)
E/AndroidRuntime( 1681): at
org.apache.commons.lang.builder.ToStringStyle.clinit(ToStringStyle.java:94)
E/AndroidRuntime( 1681): ... 18 more
E/AndroidRuntime( 1681): Caused by: java.lang.StringIndexOutOfBoundsException
E/AndroidRuntime( 1681): at java.lang.String.substring(String.java:1571)
E/AndroidRuntime( 1681): at
org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1153)
E/AndroidRuntime( 1681): at
org.apache.commons.lang.SystemUtils.clinit(SystemUtils.java:818)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
