[jira] [Commented] (FILEUPLOAD-278) MultipartStream need readBodyDataStream
[
https://issues.apache.org/jira/browse/FILEUPLOAD-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502098#comment-15502098
]
shuaib hasan khwaja commented on FILEUPLOAD-278:
https://commons.apache.org/proper/commons-fileupload/apidocs/org/apache/commons/fileupload/MultipartStream.html
> MultipartStream need readBodyDataStream
> ---
>
> Key: FILEUPLOAD-278
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-278
> Project: Commons FileUpload
> Issue Type: Improvement
>Affects Versions: 1.3.2
>Reporter: shuaib hasan khwaja
>
> Currently MultipartStream has support for "readBodyData", which basically
> read the body data and write in out stream. It work great, if plan to have
> body in memory or write in disk. But not work when you want to upstream some
> where else.
> Its a good idea to get the InputStream for part body and use it for upload to
> upstream. Some thing like...
> public InputStream readBodyDataStream(OutputStream output) IOException
> { return newInputStream(); }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FILEUPLOAD-278) MultipartStream need readBodyDataStream
shuaib hasan khwaja created FILEUPLOAD-278:
--
Summary: MultipartStream need readBodyDataStream
Key: FILEUPLOAD-278
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-278
Project: Commons FileUpload
Issue Type: Improvement
Affects Versions: 1.3.2
Reporter: shuaib hasan khwaja
Currently MultipartStream has support for "readBodyData", which basically read
the body data and write in out stream. It work great, if plan to have body in
memory or write in disk. But not work when you want to upstream some where else.
Its a good idea to get the InputStream for part body and use it for upload to
upstream. Some thing like...
public InputStream readBodyDataStream(OutputStream output) IOException
{ return newInputStream(); }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1267) FastDateFormat does not support timezone X/XX/XXX in SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hyukjin Kwon updated LANG-1267:
---
Description:
It sees {{FastDateFormat}} does not support timezone {{X}}/{{XX}}/{{XXX}} in
{{SimpleDateFormat}}.
For example,
{code}
new FastDateFormat("-MM-dd'T'HH:mm:ss.SSSXXX")
{code}
throws an exception as below:
{code}
Illegal pattern component: XXX
java.lang.IllegalArgumentException: Illegal pattern component: XXX
at
org.apache.commons.lang3.time.FastDatePrinter.parsePattern(FastDatePrinter.java:282)
at
org.apache.commons.lang3.time.FastDatePrinter.init(FastDatePrinter.java:149)
at
org.apache.commons.lang3.time.FastDatePrinter.(FastDatePrinter.java:142)
{code}
{{X}}/{{XX}}/{{XXX}} are different with {{Z}} or {{ZZ}} as described in
https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html#iso8601timezone
-It supports to read all {{+0800}}, {{+08}} and {{+08:00}} whereas it seems
there is no way to include those all.-
I looked though the documentation multiple times but I could not find the
explicit mention about this.
was:
It sees {{FastDateFormat}} does not support timezone {{X}}/{{XX}}/{{XXX}} in
{{SimpleDateFormat}}.
For example,
{code}
new FastDateFormat("-MM-dd'T'HH:mm:ss.SSSXXX")
{code}
throws an exception as below:
{code}
Illegal pattern component: XXX
java.lang.IllegalArgumentException: Illegal pattern component: XXX
at
org.apache.commons.lang3.time.FastDatePrinter.parsePattern(FastDatePrinter.java:282)
at
org.apache.commons.lang3.time.FastDatePrinter.init(FastDatePrinter.java:149)
at
org.apache.commons.lang3.time.FastDatePrinter.(FastDatePrinter.java:142)
{code}
{{X}}/{{XX}}/{{XXX}} are different with {{Z}} or {{ZZ}} as described in
https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html#iso8601timezone
It supports to read all {{+0800}}, {{+08}} and {{+08:00}} whereas it seems
there is no way to include those all.
I looked though the documentation multiple times but I could not find the
explicit mention about this.
> FastDateFormat does not support timezone X/XX/XXX in SimpleDateFormat
> -
>
> Key: LANG-1267
> URL: https://issues.apache.org/jira/browse/LANG-1267
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.3.2
>Reporter: Hyukjin Kwon
> Fix For: Patch Needed, 3.6
>
>
> It sees {{FastDateFormat}} does not support timezone {{X}}/{{XX}}/{{XXX}} in
> {{SimpleDateFormat}}.
> For example,
> {code}
> new FastDateFormat("-MM-dd'T'HH:mm:ss.SSSXXX")
> {code}
> throws an exception as below:
> {code}
> Illegal pattern component: XXX
> java.lang.IllegalArgumentException: Illegal pattern component: XXX
> at
> org.apache.commons.lang3.time.FastDatePrinter.parsePattern(FastDatePrinter.java:282)
> at
> org.apache.commons.lang3.time.FastDatePrinter.init(FastDatePrinter.java:149)
> at
> org.apache.commons.lang3.time.FastDatePrinter.(FastDatePrinter.java:142)
> {code}
> {{X}}/{{XX}}/{{XXX}} are different with {{Z}} or {{ZZ}} as described in
> https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html#iso8601timezone
> -It supports to read all {{+0800}}, {{+08}} and {{+08:00}} whereas it seems
> there is no way to include those all.-
> I looked though the documentation multiple times but I could not find the
> explicit mention about this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1267) FastDateFormat does not support timezone X/XX/XXX in SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501537#comment-15501537
]
Nathan Beyer commented on LANG-1267:
It looks like 'X' has been added to master:
https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=blob;f=src/main/java/org/apache/commons/lang3/time/FastDateParser.java;h=8275ddfd2b5eade34a4a19048c1b0b869d8f1eda;hb=refs/heads/master#l600.
> FastDateFormat does not support timezone X/XX/XXX in SimpleDateFormat
> -
>
> Key: LANG-1267
> URL: https://issues.apache.org/jira/browse/LANG-1267
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.3.2
>Reporter: Hyukjin Kwon
> Fix For: Patch Needed, 3.6
>
>
> It sees {{FastDateFormat}} does not support timezone {{X}}/{{XX}}/{{XXX}} in
> {{SimpleDateFormat}}.
> For example,
> {code}
> new FastDateFormat("-MM-dd'T'HH:mm:ss.SSSXXX")
> {code}
> throws an exception as below:
> {code}
> Illegal pattern component: XXX
> java.lang.IllegalArgumentException: Illegal pattern component: XXX
> at
> org.apache.commons.lang3.time.FastDatePrinter.parsePattern(FastDatePrinter.java:282)
> at
> org.apache.commons.lang3.time.FastDatePrinter.init(FastDatePrinter.java:149)
> at
> org.apache.commons.lang3.time.FastDatePrinter.(FastDatePrinter.java:142)
> {code}
> {{X}}/{{XX}}/{{XXX}} are different with {{Z}} or {{ZZ}} as described in
> https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html#iso8601timezone
> It supports to read all {{+0800}}, {{+08}} and {{+08:00}} whereas it seems
> there is no way to include those all.
> I looked though the documentation multiple times but I could not find the
> explicit mention about this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-910) Patch to extend StringUtils
[ https://issues.apache.org/jira/browse/LANG-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501419#comment-15501419 ] ASF GitHub Bot commented on LANG-910: - Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/184 the non-breaking space replacement was added with https://issues.apache.org/jira/browse/LANG-910 > Patch to extend StringUtils > --- > > Key: LANG-910 > URL: https://issues.apache.org/jira/browse/LANG-910 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.1 > Environment: Developed on Ubuntu 13.04 with openjdk 7u25 >Reporter: Timur Yarosh > Labels: patch > Fix For: Discussion > > Attachments: LANG-910.patch, > substring-matches-and-white-space-normalize.patch > > > This patch extends StringUtils capabilities: added methods to find > substring(s) by Pattern. Also method > org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160 > char to normal whitespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang issue #184: Correct replacing 160 in normalizeSpace
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/184 the non-breaking space replacement was added with https://issues.apache.org/jira/browse/LANG-910 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1184) StringUtils#normalizeSpace no longer normalizes unicode non-breaking spaces (\u00A0)
[
https://issues.apache.org/jira/browse/LANG-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501369#comment-15501369
]
ASF GitHub Bot commented on LANG-1184:
--
Github user PascalSchumacher closed the pull request at:
https://github.com/apache/commons-lang/pull/113
> StringUtils#normalizeSpace no longer normalizes unicode non-breaking spaces
> (\u00A0)
>
>
> Key: LANG-1184
> URL: https://issues.apache.org/jira/browse/LANG-1184
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.4
>Reporter: Pascal Schumacher
>
> This works with 3.3.2, but fails with 3.4
> {code:java}assertEquals("a b", StringUtils.normalizeSpace("a\u00A0 b"));{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang pull request #113: LANG-1184: StringUtils#normalizeSpace no lon...
Github user PascalSchumacher closed the pull request at: https://github.com/apache/commons-lang/pull/113 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #184: Correct replacing 160 in normalizeSpace
Github user PascalSchumacher commented on the issue:
https://github.com/apache/commons-lang/pull/184
Thanks for the information. I did not know that `normalizeSpace` replaces
non-breaking spaces with normal whitespace.
Both these test succeed:
```java
assertEquals("a b", StringUtils.normalizeSpace("a\u00A0b"));
assertEquals("a b", StringUtils.normalizeSpace("a\u00A0 b"));
```
The argument brought forward as to why `normalizeSpace` does not normalize
non-breaking space anymore was that `Character#isWhitespace` returns `false`.
Like I said I do not agree with this argument.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (TEXT-19) Add alphabet converter
[
https://issues.apache.org/jira/browse/TEXT-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501262#comment-15501262
]
ASF GitHub Bot commented on TEXT-19:
Github user eyala closed the pull request at:
https://github.com/apache/commons-lang/pull/188
> Add alphabet converter
> --
>
> Key: TEXT-19
> URL: https://issues.apache.org/jira/browse/TEXT-19
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Eyal Allweil
> Fix For: 1.0
>
>
> (as described in [the mailing
> list|http://mail-archives.apache.org/mod_mbox/commons-dev/201609.mbox/%3c289983494.3057706.1472720010...@mail.yahoo.com%3e])
> This is a utility class I wrote for converting from one alphabet to another -
> for example, from unicode to latin, without using some of the chars in latin.
> The usage looks like this:
> {code}
> Set originals; // a, b, c, d
> Set encoding; // 0, 1, d
> Set doNotEncode; // d
> AlphabetConverter ac = AlphabetConverter.createConverter(originals, encoding,
> doNotEncode);
> ac.encode("a"); // 00
> ac.encode("b"); // 01
> ac.encode("c"); // 0d
> ac.encode("d"); // d
> ac.encode("abcd"); // 00010dd
> {code}
> Of course, x.equals(ac.decode(ac.encode(x))) should always be true.
> The implementation provided makes the encodings of fixed length, other than
> the "do not encode" chars, which remain as they are (length one).
> In addition, in order to make it easier to preserve the encoding scheme, I've
> added a human-readable toString implementation, and a constructor that can
> recreate an AlphabetConverter from the encoding map, such that:
> {code}
> AlphabetConverter ac;
> ac.equals(AlphabetConverter.createConverterFromMap(ac.getOriginalToEncoded()));
> // always should be true
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang pull request #188: LANG-1266 Add alphabet converter
Github user eyala closed the pull request at: https://github.com/apache/commons-lang/pull/188 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TEXT-19) Add alphabet converter
[
https://issues.apache.org/jira/browse/TEXT-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501221#comment-15501221
]
ASF GitHub Bot commented on TEXT-19:
Github user britter commented on the issue:
https://github.com/apache/commons-lang/pull/188
The issue has been moved to https://issues.apache.org/jira/browse/TEXT-19
Please reference TEXT-19 in your PR against the Commons Text repository. Thank
you!
> Add alphabet converter
> --
>
> Key: TEXT-19
> URL: https://issues.apache.org/jira/browse/TEXT-19
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Eyal Allweil
> Fix For: 1.0
>
>
> (as described in [the mailing
> list|http://mail-archives.apache.org/mod_mbox/commons-dev/201609.mbox/%3c289983494.3057706.1472720010...@mail.yahoo.com%3e])
> This is a utility class I wrote for converting from one alphabet to another -
> for example, from unicode to latin, without using some of the chars in latin.
> The usage looks like this:
> {code}
> Set originals; // a, b, c, d
> Set encoding; // 0, 1, d
> Set doNotEncode; // d
> AlphabetConverter ac = AlphabetConverter.createConverter(originals, encoding,
> doNotEncode);
> ac.encode("a"); // 00
> ac.encode("b"); // 01
> ac.encode("c"); // 0d
> ac.encode("d"); // d
> ac.encode("abcd"); // 00010dd
> {code}
> Of course, x.equals(ac.decode(ac.encode(x))) should always be true.
> The implementation provided makes the encodings of fixed length, other than
> the "do not encode" chars, which remain as they are (length one).
> In addition, in order to make it easier to preserve the encoding scheme, I've
> added a human-readable toString implementation, and a constructor that can
> recreate an AlphabetConverter from the encoding map, such that:
> {code}
> AlphabetConverter ac;
> ac.equals(AlphabetConverter.createConverterFromMap(ac.getOriginalToEncoded()));
> // always should be true
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang issue #188: LANG-1266 Add alphabet converter
Github user britter commented on the issue: https://github.com/apache/commons-lang/pull/188 The issue has been moved to https://issues.apache.org/jira/browse/TEXT-19 Please reference TEXT-19 in your PR against the Commons Text repository. Thank you! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Moved] (TEXT-19) Add alphabet converter
[
https://issues.apache.org/jira/browse/TEXT-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter moved LANG-1266 to TEXT-19:
---
Fix Version/s: (was: Discussion)
1.0
Component/s: (was: lang.text.*)
Workflow: jira (was: Default workflow, editable Closed status)
Key: TEXT-19 (was: LANG-1266)
Project: Commons Text (was: Commons Lang)
> Add alphabet converter
> --
>
> Key: TEXT-19
> URL: https://issues.apache.org/jira/browse/TEXT-19
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Eyal Allweil
> Fix For: 1.0
>
>
> (as described in [the mailing
> list|http://mail-archives.apache.org/mod_mbox/commons-dev/201609.mbox/%3c289983494.3057706.1472720010...@mail.yahoo.com%3e])
> This is a utility class I wrote for converting from one alphabet to another -
> for example, from unicode to latin, without using some of the chars in latin.
> The usage looks like this:
> {code}
> Set originals; // a, b, c, d
> Set encoding; // 0, 1, d
> Set doNotEncode; // d
> AlphabetConverter ac = AlphabetConverter.createConverter(originals, encoding,
> doNotEncode);
> ac.encode("a"); // 00
> ac.encode("b"); // 01
> ac.encode("c"); // 0d
> ac.encode("d"); // d
> ac.encode("abcd"); // 00010dd
> {code}
> Of course, x.equals(ac.decode(ac.encode(x))) should always be true.
> The implementation provided makes the encodings of fixed length, other than
> the "do not encode" chars, which remain as they are (length one).
> In addition, in order to make it easier to preserve the encoding scheme, I've
> added a human-readable toString implementation, and a constructor that can
> recreate an AlphabetConverter from the encoding map, such that:
> {code}
> AlphabetConverter ac;
> ac.equals(AlphabetConverter.createConverterFromMap(ac.getOriginalToEncoded()));
> // always should be true
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (LANG-1261) ArrayUtils.contains returns false for instances of subtypes
[
https://issues.apache.org/jira/browse/LANG-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved LANG-1261.
---
Resolution: Fixed
Fix Version/s: 3.5
Fixed in 42f2058c83f256d8654b349d5249d6f59920f88b
> ArrayUtils.contains returns false for instances of subtypes
> ---
>
> Key: LANG-1261
> URL: https://issues.apache.org/jira/browse/LANG-1261
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.4
> Environment: Android
>Reporter: Homer Jay
> Labels: array, equals
> Fix For: 3.5
>
>
> ArrayUtils.contains(Object[] array, Object objectToFind) wrongly returns
> false.
> STEPS TO REPRODUCE
> =
> -Create a superclass "Parent" and override equals and hashcode based on some
> member id variable.
> -Create a class "Child" extending "Parent". Do not override equals nor
> hashcode.
> -Let "childrens" be an array of type Child[] containing several instances.
> Create an instance of Parent "p" with the same id as childrens[0], such that
> childrens[0].equals(p) returns true and p.equals(childrens[0]) returns true
> as well.
> Because they are equals, ArrayUtils.contains(childrens, p) should return
> true. However it returns false.
> WHERE THE BUG IS LOCATED
> =
> -Go to ArrayUtils.class, line 1917. In the "indexOf" method implementation,
> before going into calling equals for each element of the input array, there
> is some sort of optimization check to make sure the instance to be found is
> an instance of the array type:
> } else if (array.getClass().getComponentType().isInstance(objectToFind)) {
> That line is wrong. In our case, the array contains elements of type "Child",
> whereas the object to be found is of type "Parent". They are equals according
> to the equals implementation of "Parent", but obviously
> Children.class.isInstance(p) is false.
> EXPECTED BEHAVIOR
>
> Since the method signature accepts an array of Object[] and an instance of
> Object, it should ignore the classes of the arguments. It should be possible
> to call "ArrayUtils.contains(Child[] children, Parent p)", in fact it should
> be possible to do this with any combination of classes, not only the ones
> assignable from the class hierarchy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang pull request #183: LANG-1261: ArrayUtils#contains ArrayUtils#in...
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/183 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1261) ArrayUtils.contains returns false for instances of subtypes
[
https://issues.apache.org/jira/browse/LANG-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501212#comment-15501212
]
ASF GitHub Bot commented on LANG-1261:
--
Github user asfgit closed the pull request at:
https://github.com/apache/commons-lang/pull/183
> ArrayUtils.contains returns false for instances of subtypes
> ---
>
> Key: LANG-1261
> URL: https://issues.apache.org/jira/browse/LANG-1261
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.4
> Environment: Android
>Reporter: Homer Jay
> Labels: array, equals
>
> ArrayUtils.contains(Object[] array, Object objectToFind) wrongly returns
> false.
> STEPS TO REPRODUCE
> =
> -Create a superclass "Parent" and override equals and hashcode based on some
> member id variable.
> -Create a class "Child" extending "Parent". Do not override equals nor
> hashcode.
> -Let "childrens" be an array of type Child[] containing several instances.
> Create an instance of Parent "p" with the same id as childrens[0], such that
> childrens[0].equals(p) returns true and p.equals(childrens[0]) returns true
> as well.
> Because they are equals, ArrayUtils.contains(childrens, p) should return
> true. However it returns false.
> WHERE THE BUG IS LOCATED
> =
> -Go to ArrayUtils.class, line 1917. In the "indexOf" method implementation,
> before going into calling equals for each element of the input array, there
> is some sort of optimization check to make sure the instance to be found is
> an instance of the array type:
> } else if (array.getClass().getComponentType().isInstance(objectToFind)) {
> That line is wrong. In our case, the array contains elements of type "Child",
> whereas the object to be found is of type "Parent". They are equals according
> to the equals implementation of "Parent", but obviously
> Children.class.isInstance(p) is false.
> EXPECTED BEHAVIOR
>
> Since the method signature accepts an array of Object[] and an instance of
> Object, it should ignore the classes of the arguments. It should be possible
> to call "ArrayUtils.contains(Child[] children, Parent p)", in fact it should
> be possible to do this with any combination of classes, not only the ones
> assignable from the class hierarchy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1261) ArrayUtils.contains returns false for instances of subtypes
[
https://issues.apache.org/jira/browse/LANG-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1261:
--
Summary: ArrayUtils.contains returns false for instances of subtypes (was:
ArrayUtils.contains returns false)
> ArrayUtils.contains returns false for instances of subtypes
> ---
>
> Key: LANG-1261
> URL: https://issues.apache.org/jira/browse/LANG-1261
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.4
> Environment: Android
>Reporter: Homer Jay
> Labels: array, equals
>
> ArrayUtils.contains(Object[] array, Object objectToFind) wrongly returns
> false.
> STEPS TO REPRODUCE
> =
> -Create a superclass "Parent" and override equals and hashcode based on some
> member id variable.
> -Create a class "Child" extending "Parent". Do not override equals nor
> hashcode.
> -Let "childrens" be an array of type Child[] containing several instances.
> Create an instance of Parent "p" with the same id as childrens[0], such that
> childrens[0].equals(p) returns true and p.equals(childrens[0]) returns true
> as well.
> Because they are equals, ArrayUtils.contains(childrens, p) should return
> true. However it returns false.
> WHERE THE BUG IS LOCATED
> =
> -Go to ArrayUtils.class, line 1917. In the "indexOf" method implementation,
> before going into calling equals for each element of the input array, there
> is some sort of optimization check to make sure the instance to be found is
> an instance of the array type:
> } else if (array.getClass().getComponentType().isInstance(objectToFind)) {
> That line is wrong. In our case, the array contains elements of type "Child",
> whereas the object to be found is of type "Parent". They are equals according
> to the equals implementation of "Parent", but obviously
> Children.class.isInstance(p) is false.
> EXPECTED BEHAVIOR
>
> Since the method signature accepts an array of Object[] and an instance of
> Object, it should ignore the classes of the arguments. It should be possible
> to call "ArrayUtils.contains(Child[] children, Parent p)", in fact it should
> be possible to do this with any combination of classes, not only the ones
> assignable from the class hierarchy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LANG-1263) Add possibility to retrieve the current JavaVersion
[ https://issues.apache.org/jira/browse/LANG-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter closed LANG-1263. - > Add possibility to retrieve the current JavaVersion > --- > > Key: LANG-1263 > URL: https://issues.apache.org/jira/browse/LANG-1263 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > > Currently one has to iterate over all JavaVersion enum values and compare > them to the value of java.specification.version in order to get the current > JavaVersion enum value. > Provide a convenient method for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1263) Add possibility to retrieve the current JavaVersion
[ https://issues.apache.org/jira/browse/LANG-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-1263: -- Fix Version/s: (was: 3.5) > Add possibility to retrieve the current JavaVersion > --- > > Key: LANG-1263 > URL: https://issues.apache.org/jira/browse/LANG-1263 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > > Currently one has to iterate over all JavaVersion enum values and compare > them to the value of java.specification.version in order to get the current > JavaVersion enum value. > Provide a convenient method for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LANG-1263) Add possibility to retrieve the current JavaVersion
[ https://issues.apache.org/jira/browse/LANG-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter resolved LANG-1263. --- Resolution: Won't Fix > Add possibility to retrieve the current JavaVersion > --- > > Key: LANG-1263 > URL: https://issues.apache.org/jira/browse/LANG-1263 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > > Currently one has to iterate over all JavaVersion enum values and compare > them to the value of java.specification.version in order to get the current > JavaVersion enum value. > Provide a convenient method for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang issue #187: LANG-1263 Add possibility to retrieve the current J...
Github user britter commented on the issue: https://github.com/apache/commons-lang/pull/187 We already have `SystemUtils.isJavaVersionAtLeast(JavaVersion)` so there is no reason to add this API. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1263) Add possibility to retrieve the current JavaVersion
[ https://issues.apache.org/jira/browse/LANG-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15500832#comment-15500832 ] ASF GitHub Bot commented on LANG-1263: -- Github user britter commented on the issue: https://github.com/apache/commons-lang/pull/187 We already have `SystemUtils.isJavaVersionAtLeast(JavaVersion)` so there is no reason to add this API. > Add possibility to retrieve the current JavaVersion > --- > > Key: LANG-1263 > URL: https://issues.apache.org/jira/browse/LANG-1263 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > Fix For: 3.5 > > > Currently one has to iterate over all JavaVersion enum values and compare > them to the value of java.specification.version in order to get the current > JavaVersion enum value. > Provide a convenient method for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang pull request #187: LANG-1263 Add possibility to retrieve the cu...
Github user britter closed the pull request at: https://github.com/apache/commons-lang/pull/187 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1263) Add possibility to retrieve the current JavaVersion
[ https://issues.apache.org/jira/browse/LANG-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15500831#comment-15500831 ] ASF GitHub Bot commented on LANG-1263: -- Github user britter closed the pull request at: https://github.com/apache/commons-lang/pull/187 > Add possibility to retrieve the current JavaVersion > --- > > Key: LANG-1263 > URL: https://issues.apache.org/jira/browse/LANG-1263 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > Fix For: 3.5 > > > Currently one has to iterate over all JavaVersion enum values and compare > them to the value of java.specification.version in order to get the current > JavaVersion enum value. > Provide a convenient method for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
