[jira] [Commented] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040125#comment-16040125
 ] 

ASF GitHub Bot commented on COMPRESS-399:
-

Github user bodewig commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
Sorry, I'm currently swamped and won't find time to look into this for the 
coming days. @sesuncedu there is a discussion going on on the dev mailing list 
that you may want to join -> 
https://lists.apache.org/thread.html/4a205ffad0ae0886113e76f358a6fbe59dfdf113f194c5fa687cdd69@%3Cdev.commons.apache.org%3E


> OSGI package versions are overly pessimistic, except when they're overly 
> optimisic 
> ---
>
> Key: COMPRESS-399
> URL: https://issues.apache.org/jira/browse/COMPRESS-399
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The OSGI versions in the current distributions are not being correctly 
> generated.  OSGI relies on package version numbers following semantic version 
> properly for correct resolution.  
> Current version numbers have been generated from the maven version. This has 
> lead to new minor version increases for packages that have no API changed; it 
> has also concealed   major (breaking) changes to several packages since 1.0.
> I have created two branches that address the issue.
> Both add the bundle:baseline goal to the verify phase of the build. 
> The also both have packageinfo files added to every package, containing the 
> package version. These are picked up by the bundle manifest generator, and 
> are used if no explicit version is given in the "Export-Package" command. 
> Both branches bump the major version number for packages with any minor 
> changes to 2.0.0.  This makes the bundle correct, but does not fix improper 
> import declarations made by users of earlier bundles.   
> One branch uses the version number  from the oldest version that has no 
> changes when compared to HEAD, and which has not had any breaking changes 
> since 1.0.0.  This will fail the build because version numbers should be 
> increasing, and may cause issues if an importing bundle uses a range that 
> requires an identical, but higher numbered version of the package
> The other branch uses version 1.14.0 for all packages with no major changes. 
> A third alternative, which I didn't add, is to just set all packages be 
> version 1.14.0, and just bump major versions when required going forward. The 
> bulk of the major changes happened a good few versions back,  so it's not as 
> bad as it could be. 
> If you have a preferred option, I can create a pull request on Github 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (JEXL-226) add ?? operator support

[Min Wei (JIRA)]

Min Wei created JEXL-226:


 Summary: add ?? operator support 
 Key: JEXL-226
 URL: https://issues.apache.org/jira/browse/JEXL-226
 Project: Commons JEXL
  Issue Type: New Feature
Affects Versions: Later
Reporter: Min Wei
 Fix For: Later


Jexl already supports null-coalescing semantics with the operator "?:". So it 
should be a simple matter to extend it with a different syntax.
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator

https://github.com/apache/commons-jexl/pull/4



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IO-538) Non Synchronized CharArrayWriter

[BELUGA BEHR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IO-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

BELUGA BEHR updated IO-538:
---
Attachment: IO-538.1.patch

> Non Synchronized CharArrayWriter 
> -
>
> Key: IO-538
> URL: https://issues.apache.org/jira/browse/IO-538
> Project: Commons IO
>  Issue Type: New Feature
>  Components: Streams/Writers
>Affects Versions: 2.5
>Reporter: BELUGA BEHR
>Priority: Minor
> Attachments: IO-538.1.patch
>
>
> There currently exists {{StringBuilderWriter}}. This implementation, as an 
> alternative to java.io.StringWriter, provides an un-synchronized (i.e. for 
> use in a single thread) implementation for better performance.
> It would be nice if there way one for CharArrayWriter as well.
> https://www.igorkromin.net/index.php/2015/08/20/java-stringwriter-vs-chararraywriter-which-one-to-choose-for-performance/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (LANG-1336) Add NUL Byte To CharUtils

[BELUGA BEHR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

BELUGA BEHR updated LANG-1336:
--
Attachment: LANG-1336.2.patch

Sorry about that!

> Add NUL Byte To CharUtils
> -
>
> Key: LANG-1336
> URL: https://issues.apache.org/jira/browse/LANG-1336
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 2.6
>Reporter: BELUGA BEHR
>Priority: Minor
> Attachments: LANG-1336.1.patch, LANG-1336.2.patch
>
>
> {{CharUtils}} already defines LF and RF, please add NUL
> {code}
> public static final char NUL = '\0';
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (COLLECTIONS-605) Add new CollectionUtils Feature - addNCopies

[BELUGA BEHR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

BELUGA BEHR updated COLLECTIONS-605:

Attachment: (was: COLLECTIONS-605.1.patch)

> Add new CollectionUtils Feature - addNCopies
> 
>
> Key: COLLECTIONS-605
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-605
> Project: Commons Collections
>  Issue Type: New Feature
>Affects Versions: 4.1
>Reporter: BELUGA BEHR
>Priority: Trivial
> Attachments: COLLECTIONS-605.1.patch
>
>
> Java's {{java.util.Collections}} has:
> {code}
> nCopies(int n, T o)
> Returns an immutable list consisting of n copies of the specified object.
> addAll(Collection c, T... elements)
> Adds all of the specified elements to the specified collection.
> fill(List list, T obj)
> Replaces all of the elements of the specified list with the specified element.
> {code}
> However, it does not have the ability to add nCopies directly to a Collection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (COLLECTIONS-605) Add new CollectionUtils Feature - addNCopies

[BELUGA BEHR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

BELUGA BEHR updated COLLECTIONS-605:

Attachment: COLLECTIONS-605.1.patch

> Add new CollectionUtils Feature - addNCopies
> 
>
> Key: COLLECTIONS-605
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-605
> Project: Commons Collections
>  Issue Type: New Feature
>Affects Versions: 4.1
>Reporter: BELUGA BEHR
>Priority: Trivial
> Attachments: COLLECTIONS-605.1.patch
>
>
> Java's {{java.util.Collections}} has:
> {code}
> nCopies(int n, T o)
> Returns an immutable list consisting of n copies of the specified object.
> addAll(Collection c, T... elements)
> Adds all of the specified elements to the specified collection.
> fill(List list, T obj)
> Replaces all of the elements of the specified list with the specified element.
> {code}
> However, it does not have the ability to add nCopies directly to a Collection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (COLLECTIONS-605) Add new CollectionUtils Feature - addNCopies

[BELUGA BEHR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

BELUGA BEHR updated COLLECTIONS-605:

Attachment: COLLECTIONS-605.1.patch

> Add new CollectionUtils Feature - addNCopies
> 
>
> Key: COLLECTIONS-605
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-605
> Project: Commons Collections
>  Issue Type: New Feature
>Affects Versions: 4.1
>Reporter: BELUGA BEHR
>Priority: Trivial
> Attachments: COLLECTIONS-605.1.patch
>
>
> Java's {{java.util.Collections}} has:
> {code}
> nCopies(int n, T o)
> Returns an immutable list consisting of n copies of the specified object.
> addAll(Collection c, T... elements)
> Adds all of the specified elements to the specified collection.
> fill(List list, T obj)
> Replaces all of the elements of the specified list with the specified element.
> {code}
> However, it does not have the ability to add nCopies directly to a Collection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (COLLECTIONS-605) Add new CollectionUtils Feature - addNCopies

[BELUGA BEHR (JIRA)]

BELUGA BEHR created COLLECTIONS-605:
---

 Summary: Add new CollectionUtils Feature - addNCopies
 Key: COLLECTIONS-605
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-605
 Project: Commons Collections
  Issue Type: New Feature
Affects Versions: 4.1
Reporter: BELUGA BEHR
Priority: Trivial


Java's {{java.util.Collections}} has:

{code}
nCopies(int n, T o)
Returns an immutable list consisting of n copies of the specified object.

addAll(Collection c, T... elements)
Adds all of the specified elements to the specified collection.

fill(List list, T obj)
Replaces all of the elements of the specified list with the specified element.
{code}

However, it does not have the ability to add nCopies directly to a Collection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (VALIDATOR-427) Race Condition in DomainValidator

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/VALIDATOR-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039720#comment-16039720
 ] 

Sebb commented on VALIDATOR-427:


I suppose it might be possible to turn the override arrays into instance fields 
set at construction.
This would allow an app to create mutiple validators.
That would be an enhancement request. It needs a fair amount of work to ensure 
compatibility etc.

> Race Condition in DomainValidator
> -
>
> Key: VALIDATOR-427
> URL: https://issues.apache.org/jira/browse/VALIDATOR-427
> Project: Commons Validator
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Steven Sheehy
>
> There's a race condition in DomainValidator which causes our application to 
> fail sometimes. The issue occurs when the DomainValidator.getInstance() is 
> called before we can call DomainValidator.updateTLDOverride() and we receive 
> a IllegalStateException("Can only invoke this method before calling 
> getInstance"). In a multi-threaded environment, DomainValidator.getInstance() 
> can be called at any time and it is difficult to find a location in 
> application startup which ensures DomainValidator.updateTLDOverride() is 
> called before to initialize it. I was able to workaround during application 
> runtime it by placing the initialization in a Spring @Configuration class, 
> but there is no proper location in JUnit tests which can be called before any 
> tests run.
> Therefore, I think the proper approach to address this is to allow 
> DomainValidator.updateTLDOverride() to be updated at any time including after 
> calls to getInstance(). Examining the source, I see that the both methods are 
> synchronized and that the custom TLD arrays are all volatile. Therefore, 
> assuming Java 1.5 or greater and its guarantees about volatile assignments, 
> the code already guarantees proper synchronization for the TLD plus arrays 
> and the inUse flag is not needed and can be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (VALIDATOR-427) Race Condition in DomainValidator

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/VALIDATOR-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039686#comment-16039686
 ] 

Sebb commented on VALIDATOR-427:


The current rule is that the overrides must be set up before getting the 
instance.

That was done in order to guarantee safe publication of the data without 
requiring all the isValidxxx methods to be synchronised.

Volatile on its own does not do that, see:

https://www.securecoding.cert.org/confluence/display/java/CON50-J.+Do+not+assume+that+declaring+a+reference+volatile+guarantees+safe+publication+of+the+members+of+the+referenced+object

The inUse flag avoids the need to synch. the isValidxxx methods.

> Race Condition in DomainValidator
> -
>
> Key: VALIDATOR-427
> URL: https://issues.apache.org/jira/browse/VALIDATOR-427
> Project: Commons Validator
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Steven Sheehy
>
> There's a race condition in DomainValidator which causes our application to 
> fail sometimes. The issue occurs when the DomainValidator.getInstance() is 
> called before we can call DomainValidator.updateTLDOverride() and we receive 
> a IllegalStateException("Can only invoke this method before calling 
> getInstance"). In a multi-threaded environment, DomainValidator.getInstance() 
> can be called at any time and it is difficult to find a location in 
> application startup which ensures DomainValidator.updateTLDOverride() is 
> called before to initialize it. I was able to workaround during application 
> runtime it by placing the initialization in a Spring @Configuration class, 
> but there is no proper location in JUnit tests which can be called before any 
> tests run.
> Therefore, I think the proper approach to address this is to allow 
> DomainValidator.updateTLDOverride() to be updated at any time including after 
> calls to getInstance(). Examining the source, I see that the both methods are 
> synchronized and that the custom TLD arrays are all volatile. Therefore, 
> assuming Java 1.5 or greater and its guarantees about volatile assignments, 
> the code already guarantees proper synchronization for the TLD plus arrays 
> and the inUse flag is not needed and can be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (VALIDATOR-425) UrlValidator fails to validate punycode encode URLs

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VALIDATOR-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved VALIDATOR-425.

Resolution: Not A Bug

> UrlValidator fails to validate punycode encode URLs
> ---
>
> Key: VALIDATOR-425
> URL: https://issues.apache.org/jira/browse/VALIDATOR-425
> Project: Commons Validator
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Michael Ignatysh
>
> When working with non-ASCII characters in URL, domain section of such URLs 
> may be encoded with Punycode. 
> In such cases, a top level domain may contain "-" character, which fails 
> validation. 
> Example:
> http://кто.ру/ - is a valid URL which will be encoded as:
> http://xn--j1ail.xn--p1ag/
> The expected behavior is that second URL passes validation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (VALIDATOR-425) UrlValidator fails to validate punycode encode URLs

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/VALIDATOR-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039646#comment-16039646
 ] 

Sebb commented on VALIDATOR-425:


UrlValidator does support punycode.
See for example UrlValidatorTest.testValidator290()

The problem here is that the TLD is not valid.

> UrlValidator fails to validate punycode encode URLs
> ---
>
> Key: VALIDATOR-425
> URL: https://issues.apache.org/jira/browse/VALIDATOR-425
> Project: Commons Validator
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Michael Ignatysh
>
> When working with non-ASCII characters in URL, domain section of such URLs 
> may be encoded with Punycode. 
> In such cases, a top level domain may contain "-" character, which fails 
> validation. 
> Example:
> http://кто.ру/ - is a valid URL which will be encoded as:
> http://xn--j1ail.xn--p1ag/
> The expected behavior is that second URL passes validation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IO-539) Add NonSyncByteArrayInputStream Implementation

[BELUGA BEHR (JIRA)]

BELUGA BEHR created IO-539:
--

 Summary: Add NonSyncByteArrayInputStream Implementation
 Key: IO-539
 URL: https://issues.apache.org/jira/browse/IO-539
 Project: Commons IO
  Issue Type: New Feature
  Components: Streams/Writers
Affects Versions: 2.5
Reporter: BELUGA BEHR


Consume code from Apache Hadoop 
{{org.apache.hadoop.hive.common.io.NonSyncByteArrayInputStream}} and make it 
more available to a broader audience.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class

[Amey Jadiye (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039506#comment-16039506
 ] 

Amey Jadiye commented on NUMBERS-38:


Hello [~erans],

I have submitted code for your review, now latest test case only going to test 
values generated by {{LanczosApproximation.java}}  against code given 
[Here|https://rosettacode.org/wiki/Gamma_function#Java] which was scope of this 
jira and we can merge and close it.

My intent is modifying code with no breaks anywhere, I've reviewed the code in 
{{GammaDistribution}}  we might need to change it if we go with my approach, 
and anyway we are segregating Math and Numbers so we are in that flow to change 
it little more. 

Lets see what others are thinking, for now we can close this ticket as it have 
completed its purpose.

> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
>  Issue Type: Test
>Reporter: Gilles
>  Labels: unit-test
> Fix For: 1.0
>
> Attachments: NUMBERS-38.patch
>
>
> The computation of the {{LanczosApproximation}} (package 
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not 
> checked by unit tests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039474#comment-16039474
 ] 

Simon Spero edited comment on COMPRESS-400 at 6/6/17 7:27 PM:
--

1. Should the appropriate method names be changed to from extra to either ext 
or extended? I was thinking of them as extra (to the ones already processed), 
and so mentally expanded exthdr to extra, contra PAX regem. 

2. Should I add methods to TarArchiveOutputStream to allow setting global 
extended headers to be emitted in a global header record when the next header 
set is pushed?

3. Should I change TarArchiveInputStream to propagate  input global extended 
header values to each entry?

4. Should I look to see if some of this API work could be generalized to the 
generic Archive API interfaces? 


was (Author: sesuncedu):
1. Should the appropriate method names be changed to from extra to either ext 
or extended? I was thinking of them as extra (to the ones already processed), 
and so mentally expanded exthdr to extra, contra PAX regem. 

2. Should I add methods to TarArchiveOutputStream to allow setting global 
extended headers to be emitted in a global header record when the next header 
set is pushed?

3. Should I change TarArchiveInputStream to propagate  input global extended 
header values to each entry?

> It should be possible for users to create and access extra PAX headers to tar 
> archives 
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries.  For 
> example, a tar file containing maven artifacts could have extra headers 
> carrying the groupid, artifactid, version, classifier, etc.  
> If the appropriate prefixes are used, these headers can be extracted to posix 
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra 
> headers, plus modifications to the TarArchive*Stream to save unrecognized 
> headers when reading, and to add any extra headers when writing. 
> I have created a prototype implementation, but have not merged it into my 
> fork of the project.  I don't have full tests written, because I was using 
> gnutar as an oracle.
>  I have also ignored the issue of writing values to standard headers like 
> size, though since the PAX specification states that doing things like 
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm 
> technically in compliance.  The temptation is  to do what was asked, then on 
> close pop up a "Were you sure?" dialog, but that's mean.  I guess I could use 
> this to set the appropriate entry fields if doing so makes sense, but the 
> easiest approach  is to block setting any headers that would be consumed by 
> the tar implementation when reading. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CODEC-234) Base32.decode should support lowercase letters

[Christopher Schultz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CODEC-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz updated CODEC-234:
--
Attachment: CODEC-234-2.diff

An updated patch:

1. 0->O and 1->I is not optional, via a setter
2. Base32 Hex encoding supports lowercase decoding, too
3. Additional test cases


> Base32.decode should support lowercase letters
> --
>
> Key: CODEC-234
> URL: https://issues.apache.org/jira/browse/CODEC-234
> Project: Commons Codec
>  Issue Type: Improvement
>Affects Versions: 1.10
>Reporter: Christopher Schultz
>Priority: Minor
> Attachments: CODEC-234-2.diff, CODEC-234.diff
>
>
> Base32.decode accepts a String input, but any lowercase characters are 
> ignored -- e.g. Base32.decode("abcd2345") will give a different result than 
> Base32.decode("ABCD1234") with no errors and a surprise to a developer.
> Accepting any case is desirable, as RFC 4648 makes it clear that 
> case-insensitivity is a goal for Base32 encoding.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039474#comment-16039474
 ] 

Simon Spero commented on COMPRESS-400:
--

1. Should the appropriate method names be changed to from extra to either ext 
or extended? I was thinking of them as extra (to the ones already processed), 
and so mentally expanded exthdr to extra, contra PAX regem. 

2. Should I add methods to TarArchiveOutputStream to allow setting global 
extended headers to be emitted in a global header record when the next header 
set is pushed?

3. Should I change TarArchiveInputStream to propagate  input global extended 
header values to each entry?

> It should be possible for users to create and access extra PAX headers to tar 
> archives 
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries.  For 
> example, a tar file containing maven artifacts could have extra headers 
> carrying the groupid, artifactid, version, classifier, etc.  
> If the appropriate prefixes are used, these headers can be extracted to posix 
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra 
> headers, plus modifications to the TarArchive*Stream to save unrecognized 
> headers when reading, and to add any extra headers when writing. 
> I have created a prototype implementation, but have not merged it into my 
> fork of the project.  I don't have full tests written, because I was using 
> gnutar as an oracle.
>  I have also ignored the issue of writing values to standard headers like 
> size, though since the PAX specification states that doing things like 
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm 
> technically in compliance.  The temptation is  to do what was asked, then on 
> close pop up a "Were you sure?" dialog, but that's mean.  I guess I could use 
> this to set the appropriate entry fields if doing so makes sense, but the 
> easiest approach  is to block setting any headers that would be consumed by 
> the tar implementation when reading. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039473#comment-16039473
 ] 

ASF GitHub Bot commented on NUMBERS-38:
---

Github user coveralls commented on the issue:

https://github.com/apache/commons-numbers/pull/5
  

[![Coverage 
Status](https://coveralls.io/builds/11855086/badge)](https://coveralls.io/builds/11855086)

Coverage remained the same at 83.124% when pulling 
**0701cbfe7492510dc4ffe9d083b89b403f236b42 on ameyjadiye:master** into 
**c2bfc4fbf8fe325eaf254c37128948b7644e5687 on apache:master**.



> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
>  Issue Type: Test
>Reporter: Gilles
>  Labels: unit-test
> Fix For: 1.0
>
> Attachments: NUMBERS-38.patch
>
>
> The computation of the {{LanczosApproximation}} (package 
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not 
> checked by unit tests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (VALIDATOR-427) Race Condition in DomainValidator

[Steven Sheehy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VALIDATOR-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steven Sheehy reopened VALIDATOR-427:
-

I respectfully disagree and would appreciate some discussion on it before 
dismissing it out of hand.

- This issue ended up causing a NoClassDefFoundError in production since we 
were initializing updateTLDOverride in a static initializer and some other code 
was calling getInstance() before that code was called. This is a serious issue 
that deserves some thought.

- To your point about confusion after changing them, there would be no 
confusion since the developer is the one that changed that and would expect the 
result to change.

- What about the use case where the end user would want to add some custom 
domains dynamically via a UI? We have large enterprise customers who pick 
non-standard local TLDs and right now we're having to hardcode them.

- There are simply times when we cannot guarantee updateTLDOverride() is called 
first. Where would you suggest we call updateTLDOverride() to ensure that it is 
called first in a series of JUnit tests? The order JUnit runs tests is random 
and there is no concept of "execute this code before all tests" in JUnit. Or 
what about if a library I wrote depended upon updateTLDOverride() and had 
multiple classes that served as entry points, where would I initialize it there?

- The inUse flag serves no synchronization purpose, only an arbitrary technical 
requirement that TLDs can never be set after getInstance().

> Race Condition in DomainValidator
> -
>
> Key: VALIDATOR-427
> URL: https://issues.apache.org/jira/browse/VALIDATOR-427
> Project: Commons Validator
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Steven Sheehy
>
> There's a race condition in DomainValidator which causes our application to 
> fail sometimes. The issue occurs when the DomainValidator.getInstance() is 
> called before we can call DomainValidator.updateTLDOverride() and we receive 
> a IllegalStateException("Can only invoke this method before calling 
> getInstance"). In a multi-threaded environment, DomainValidator.getInstance() 
> can be called at any time and it is difficult to find a location in 
> application startup which ensures DomainValidator.updateTLDOverride() is 
> called before to initialize it. I was able to workaround during application 
> runtime it by placing the initialization in a Spring @Configuration class, 
> but there is no proper location in JUnit tests which can be called before any 
> tests run.
> Therefore, I think the proper approach to address this is to allow 
> DomainValidator.updateTLDOverride() to be updated at any time including after 
> calls to getInstance(). Examining the source, I see that the both methods are 
> synchronized and that the custom TLD arrays are all volatile. Therefore, 
> assuming Java 1.5 or greater and its guarantees about volatile assignments, 
> the code already guarantees proper synchronization for the TLD plus arrays 
> and the inUse flag is not needed and can be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (VALIDATOR-427) Race Condition in DomainValidator

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/VALIDATOR-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039400#comment-16039400
 ] 

Sebb commented on VALIDATOR-427:


There is no race condition here.
The rule is that DomainValidator.updateTLDOverride() must be called before 
DomainValidator.getInstance().
If an application does not do that, it is an application bug.

The override arrays are static, and apply to all threads that use the singleton 
instance.
If the overrides could be changed after getInstance has been called, then 
different threads can get different results, possibly changing between calls.
That would be very confusing.

> Race Condition in DomainValidator
> -
>
> Key: VALIDATOR-427
> URL: https://issues.apache.org/jira/browse/VALIDATOR-427
> Project: Commons Validator
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Steven Sheehy
>
> There's a race condition in DomainValidator which causes our application to 
> fail sometimes. The issue occurs when the DomainValidator.getInstance() is 
> called before we can call DomainValidator.updateTLDOverride() and we receive 
> a IllegalStateException("Can only invoke this method before calling 
> getInstance"). In a multi-threaded environment, DomainValidator.getInstance() 
> can be called at any time and it is difficult to find a location in 
> application startup which ensures DomainValidator.updateTLDOverride() is 
> called before to initialize it. I was able to workaround during application 
> runtime it by placing the initialization in a Spring @Configuration class, 
> but there is no proper location in JUnit tests which can be called before any 
> tests run.
> Therefore, I think the proper approach to address this is to allow 
> DomainValidator.updateTLDOverride() to be updated at any time including after 
> calls to getInstance(). Examining the source, I see that the both methods are 
> synchronized and that the custom TLD arrays are all volatile. Therefore, 
> assuming Java 1.5 or greater and its guarantees about volatile assignments, 
> the code already guarantees proper synchronization for the TLD plus arrays 
> and the inUse flag is not needed and can be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (VALIDATOR-427) Race Condition in DomainValidator

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VALIDATOR-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved VALIDATOR-427.

Resolution: Not A Problem

> Race Condition in DomainValidator
> -
>
> Key: VALIDATOR-427
> URL: https://issues.apache.org/jira/browse/VALIDATOR-427
> Project: Commons Validator
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Steven Sheehy
>
> There's a race condition in DomainValidator which causes our application to 
> fail sometimes. The issue occurs when the DomainValidator.getInstance() is 
> called before we can call DomainValidator.updateTLDOverride() and we receive 
> a IllegalStateException("Can only invoke this method before calling 
> getInstance"). In a multi-threaded environment, DomainValidator.getInstance() 
> can be called at any time and it is difficult to find a location in 
> application startup which ensures DomainValidator.updateTLDOverride() is 
> called before to initialize it. I was able to workaround during application 
> runtime it by placing the initialization in a Spring @Configuration class, 
> but there is no proper location in JUnit tests which can be called before any 
> tests run.
> Therefore, I think the proper approach to address this is to allow 
> DomainValidator.updateTLDOverride() to be updated at any time including after 
> calls to getInstance(). Examining the source, I see that the both methods are 
> synchronized and that the custom TLD arrays are all volatile. Therefore, 
> assuming Java 1.5 or greater and its guarantees about volatile assignments, 
> the code already guarantees proper synchronization for the TLD plus arrays 
> and the inUse flag is not needed and can be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (VALIDATOR-427) Race Condition in DomainValidator

[Steven Sheehy (JIRA)]

Steven Sheehy created VALIDATOR-427:
---

 Summary: Race Condition in DomainValidator
 Key: VALIDATOR-427
 URL: https://issues.apache.org/jira/browse/VALIDATOR-427
 Project: Commons Validator
  Issue Type: Bug
Affects Versions: 1.6
Reporter: Steven Sheehy


There's a race condition in DomainValidator which causes our application to 
fail sometimes. The issue occurs when the DomainValidator.getInstance() is 
called before we can call DomainValidator.updateTLDOverride() and we receive a 
IllegalStateException("Can only invoke this method before calling 
getInstance"). In a multi-threaded environment, DomainValidator.getInstance() 
can be called at any time and it is difficult to find a location in application 
startup which ensures DomainValidator.updateTLDOverride() is called before to 
initialize it. I was able to workaround during application runtime it by 
placing the initialization in a Spring @Configuration class, but there is no 
proper location in JUnit tests which can be called before any tests run.

Therefore, I think the proper approach to address this is to allow 
DomainValidator.updateTLDOverride() to be updated at any time including after 
calls to getInstance(). Examining the source, I see that the both methods are 
synchronized and that the custom TLD arrays are all volatile. Therefore, 
assuming Java 1.5 or greater and its guarantees about volatile assignments, the 
code already guarantees proper synchronization for the TLD plus arrays and the 
inUse flag is not needed and can be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLI-217) Optional partial matching for long options

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039275#comment-16039275
 ] 

Gary Gregory commented on CLI-217:
--

Hi Rubin,

CLI-217.patch does not apply either.

Gary

> Optional partial matching for long options
> --
>
> Key: CLI-217
> URL: https://issues.apache.org/jira/browse/CLI-217
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.3
>Reporter: Emmanuel Bourg
> Attachments: CLI-217.patch, optPartialMatch.patch
>
>
> DefaultParser support partial long options (i.e --ver matches --version if 
> there is no ambiguity), but for some cases it might be necessary to disable 
> this feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLI-217) Optional partial matching for long options

[Rubin Simons (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039233#comment-16039233
 ] 

Rubin Simons commented on CLI-217:
--

Hi Gary,

As far as I gather from the comments, the CLI-217.patch file is the newer 
variant; is that one also "out of date"? If yes, I will happily write a fresh 
one against 1.4. Let me know!


Rubin!

> Optional partial matching for long options
> --
>
> Key: CLI-217
> URL: https://issues.apache.org/jira/browse/CLI-217
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.3
>Reporter: Emmanuel Bourg
> Attachments: CLI-217.patch, optPartialMatch.patch
>
>
> DefaultParser support partial long options (i.e --ver matches --version if 
> there is no ambiguity), but for some cases it might be necessary to disable 
> this feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LANG-1336) Add NUL Byte To CharUtils

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039222#comment-16039222
 ] 

Gary Gregory commented on LANG-1336:


Hi,

Thank you for the patch but it does not apply cleanly for me. Can you do it 
again on top of the HEAD of master?

Gary

> Add NUL Byte To CharUtils
> -
>
> Key: LANG-1336
> URL: https://issues.apache.org/jira/browse/LANG-1336
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 2.6
>Reporter: BELUGA BEHR
>Priority: Minor
> Attachments: LANG-1336.1.patch
>
>
> {{CharUtils}} already defines LF and RF, please add NUL
> {code}
> public static final char NUL = '\0';
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLI-217) Optional partial matching for long options

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039176#comment-16039176
 ] 

Gary Gregory commented on CLI-217:
--

Hi [~rubin]:

I am guessing it was just an omission. The 2nd patch 
(https://issues.apache.org/jira/secure/attachment/12503660/optPartialMatch.patch)
 is now stale. If you provide a new patch that applies cleanly and passes the 
build, I or someone else will test it.

Gary

> Optional partial matching for long options
> --
>
> Key: CLI-217
> URL: https://issues.apache.org/jira/browse/CLI-217
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.3
>Reporter: Emmanuel Bourg
> Attachments: CLI-217.patch, optPartialMatch.patch
>
>
> DefaultParser support partial long options (i.e --ver matches --version if 
> there is no ambiguity), but for some cases it might be necessary to disable 
> this feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution

[Rob Tompkins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Tompkins resolved FILEUPLOAD-279.
-
Resolution: Fixed

Working on the release now.

> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation 
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
>  Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
>  Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can 
> be manipulated in such a way that when it is deserialized, it can write or 
> copy files to disk in arbitrary locations. Furthermore, while the Object can 
> be used alone, this new vector can be integrated with ysoserial to upload and 
> execute binaries in a single deserialization call. This may or may not work 
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s 
> yososerial tool to gain remote code execution on a variety of commercial 
> products, based on a presentation at AppSec Cali in January, 2015. The 
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and 
> Spring that do “unexpected” things during deserialization. Specifically, the 
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing 
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make 
> “it easy to add robust, high-performance, file upload capability to your 
> servlets and web applications.” One of the classes in the FileUpload library 
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads. 
> Interestingly, DiskFileItem is serializable and implements custom 
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository 
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the 
> JVMs are
> 639 * on different machines It is possible that the repository 
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null 
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after 
> analyzing the state of DiskFileItem after serialization it became clear that 
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not 
> serialized. dfos is regenerated by the getOutputStream() call above (which 
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid 
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to read in the file 
> from disk.
> That filename is always generated via getOutputStream.
> Serialized Object Modification
> The rules listed above do not take into account that someone might modify the 
> serialized data before it is 

[jira] [Reopened] (FILEUPLOAD-235) FileItem.getName() does not conform to the Java File.getName behaviour and *returns* a full path when provided with one

[Rob Tompkins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FILEUPLOAD-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Tompkins reopened FILEUPLOAD-235:
-

Ok. I'll put it into the 1.X category and re-open it.

> FileItem.getName() does not conform to the Java File.getName behaviour and 
> *returns* a full path when provided with one
> ---
>
> Key: FILEUPLOAD-235
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-235
> Project: Commons FileUpload
>  Issue Type: Bug
>Affects Versions: 1.3
>Reporter: David
>Assignee: Jochen Wiedmann
>Priority: Minor
> Fix For: 2.x
>
>
> I understand that FileItem is simply following RFC 1867, but the 
> implementation of 'getName' 
> method on a file related class IMHO should follow the behaviour of the java 
> File class which
> bq. Returns the name of the file or directory denoted by this abstract 
> pathname. This is just the last name in the pathname's name sequence. If the 
> pathname's name sequence is empty, then the empty string is returned. 
> http://docs.oracle.com/javase/7/docs/api/java/io/File.html#getName()
> I propose that FileItem.getName() is changed to *match* the java File class 
> behaviour and that another method called something like 'getRawName' be added 
> to the FileItem class. The rational for this change is to make it less easy 
> to shoot oneself in the foot (in no modern web application is a 'full 
> filepath' useful, especially when most browsers do not send one!).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LANG-1337) Fix test failures in IBM JDK 8 for ToStringBuilderTest

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039062#comment-16039062
 ] 

ASF GitHub Bot commented on LANG-1337:
--

Github user sebbASF commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/269#discussion_r120390348
  
--- Diff: 
src/test/java/org/apache/commons/lang3/builder/ToStringBuilderTest.java ---
@@ -316,7 +316,7 @@ public void testReflectionHierarchyArrayList() {
 // representation different for IBM JDK 1.6.0, LANG-727
 assumeFalse("IBM Corporation".equals(SystemUtils.JAVA_VENDOR) && 
"1.6".equals(SystemUtils.JAVA_SPECIFICATION_VERSION));
 assumeFalse("Oracle Corporation".equals(SystemUtils.JAVA_VENDOR) 
&& "1.6".compareTo(SystemUtils.JAVA_SPECIFICATION_VERSION) < 0);
-final List list = new ArrayList<>();
+final List list = new ArrayList<>(10);
--- End diff --

Thanks!

If the test fails when the initial size arg is omitted, does that not also 
affect the behaviour of the method being tested? i.e. do apps also have to 
ensure that they specify the min size when using 
ToStringBuilder.reflectionToString() ?


> Fix test failures in IBM JDK 8 for ToStringBuilderTest
> --
>
> Key: LANG-1337
> URL: https://issues.apache.org/jira/browse/LANG-1337
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.5
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
> 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> git sha 551101299da7f75ea5478db1a6bc194963e0ac34
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: ibm, ibm-jdk, test
> Fix For: 3.6
>
>
> From the 3.6 thread RC2. We had issues in the release. Two tests failed. One 
> of these tests happened on IBM JDK 8, and was related to time zones. Gary 
> Gregory quickly pointed that the very latest IBM JDK 8 released did not had 
> this issue.
> Indeed, I grabbed a JDK 8 from IBM and had this issue, and then after looking 
> for the latest version, I had only one test failing. This test in question 
> was ToStringBuilderTest#testReflectionHierarchyArrayList.
> Debugging the test in Eclipse, with the JDK pointing to IBM JDK 8 (and taking 
> care to not let the Eclipse maven integration change it), there is a part of 
> the code that receives an ArrayList object to create a String with reflection.
> In Oracle JDK 7, the object contains the default 10 empty positions, and thus 
> the generated String is.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={,},size=0,modCount=0]
> {noformat}
> But with IBM JDK 8, the ArrayList is empty, nada, and then I get the 
> following in the Eclipse debugger.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={},size=0,modCount=0]
> {noformat}
> The test is - as commented in LANG-727 - a bit flaky. However, the expected 
> string assumes ArrayList will have an initial 10 null values. So the pull 
> request in this issue simply creates an ArrayList with 10 initial capacity 
> :-) a naïve approach, but that I believe fixes this test.
> The changes in the pull request linked to this issue have all tests passing 
> with the following set-ups:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: 

[GitHub] commons-lang pull request #269: LANG-1337: Fix test failures in IBM JDK 8 fo...

[sebbASF]

Github user sebbASF commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/269#discussion_r120390348
  
--- Diff: 
src/test/java/org/apache/commons/lang3/builder/ToStringBuilderTest.java ---
@@ -316,7 +316,7 @@ public void testReflectionHierarchyArrayList() {
 // representation different for IBM JDK 1.6.0, LANG-727
 assumeFalse("IBM Corporation".equals(SystemUtils.JAVA_VENDOR) && 
"1.6".equals(SystemUtils.JAVA_SPECIFICATION_VERSION));
 assumeFalse("Oracle Corporation".equals(SystemUtils.JAVA_VENDOR) 
&& "1.6".compareTo(SystemUtils.JAVA_SPECIFICATION_VERSION) < 0);
-final List list = new ArrayList<>();
+final List list = new ArrayList<>(10);
--- End diff --

Thanks!

If the test fails when the initial size arg is omitted, does that not also 
affect the behaviour of the method being tested? i.e. do apps also have to 
ensure that they specify the min size when using 
ToStringBuilder.reflectionToString() ?


---
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-1337) Fix test failures in IBM JDK 8 for ToStringBuilderTest

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039038#comment-16039038
 ] 

ASF GitHub Bot commented on LANG-1337:
--

Github user andyklimczak commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/269#discussion_r120386094
  
--- Diff: 
src/test/java/org/apache/commons/lang3/builder/ToStringBuilderTest.java ---
@@ -316,7 +316,7 @@ public void testReflectionHierarchyArrayList() {
 // representation different for IBM JDK 1.6.0, LANG-727
 assumeFalse("IBM Corporation".equals(SystemUtils.JAVA_VENDOR) && 
"1.6".equals(SystemUtils.JAVA_SPECIFICATION_VERSION));
 assumeFalse("Oracle Corporation".equals(SystemUtils.JAVA_VENDOR) 
&& "1.6".compareTo(SystemUtils.JAVA_SPECIFICATION_VERSION) < 0);
-final List list = new ArrayList<>();
+final List list = new ArrayList<>(10);
--- End diff --

probably related to [this](https://stackoverflow.com/a/34250231)?


> Fix test failures in IBM JDK 8 for ToStringBuilderTest
> --
>
> Key: LANG-1337
> URL: https://issues.apache.org/jira/browse/LANG-1337
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.5
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
> 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> git sha 551101299da7f75ea5478db1a6bc194963e0ac34
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: ibm, ibm-jdk, test
> Fix For: 3.6
>
>
> From the 3.6 thread RC2. We had issues in the release. Two tests failed. One 
> of these tests happened on IBM JDK 8, and was related to time zones. Gary 
> Gregory quickly pointed that the very latest IBM JDK 8 released did not had 
> this issue.
> Indeed, I grabbed a JDK 8 from IBM and had this issue, and then after looking 
> for the latest version, I had only one test failing. This test in question 
> was ToStringBuilderTest#testReflectionHierarchyArrayList.
> Debugging the test in Eclipse, with the JDK pointing to IBM JDK 8 (and taking 
> care to not let the Eclipse maven integration change it), there is a part of 
> the code that receives an ArrayList object to create a String with reflection.
> In Oracle JDK 7, the object contains the default 10 empty positions, and thus 
> the generated String is.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={,},size=0,modCount=0]
> {noformat}
> But with IBM JDK 8, the ArrayList is empty, nada, and then I get the 
> following in the Eclipse debugger.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={},size=0,modCount=0]
> {noformat}
> The test is - as commented in LANG-727 - a bit flaky. However, the expected 
> string assumes ArrayList will have an initial 10 null values. So the pull 
> request in this issue simply creates an ArrayList with 10 initial capacity 
> :-) a naïve approach, but that I believe fixes this test.
> The changes in the pull request linked to this issue have all tests passing 
> with the following set-ups:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
> Apache 

[jira] [Commented] (LANG-1337) Fix test failures in IBM JDK 8 for ToStringBuilderTest

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039036#comment-16039036
 ] 

ASF GitHub Bot commented on LANG-1337:
--

Github user andyklimczak commented on the issue:

https://github.com/apache/commons-lang/pull/269
  
probably related to [this](https://stackoverflow.com/a/34250231)?


> Fix test failures in IBM JDK 8 for ToStringBuilderTest
> --
>
> Key: LANG-1337
> URL: https://issues.apache.org/jira/browse/LANG-1337
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.5
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
> 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> git sha 551101299da7f75ea5478db1a6bc194963e0ac34
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: ibm, ibm-jdk, test
> Fix For: 3.6
>
>
> From the 3.6 thread RC2. We had issues in the release. Two tests failed. One 
> of these tests happened on IBM JDK 8, and was related to time zones. Gary 
> Gregory quickly pointed that the very latest IBM JDK 8 released did not had 
> this issue.
> Indeed, I grabbed a JDK 8 from IBM and had this issue, and then after looking 
> for the latest version, I had only one test failing. This test in question 
> was ToStringBuilderTest#testReflectionHierarchyArrayList.
> Debugging the test in Eclipse, with the JDK pointing to IBM JDK 8 (and taking 
> care to not let the Eclipse maven integration change it), there is a part of 
> the code that receives an ArrayList object to create a String with reflection.
> In Oracle JDK 7, the object contains the default 10 empty positions, and thus 
> the generated String is.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={,},size=0,modCount=0]
> {noformat}
> But with IBM JDK 8, the ArrayList is empty, nada, and then I get the 
> following in the Eclipse debugger.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={},size=0,modCount=0]
> {noformat}
> The test is - as commented in LANG-727 - a bit flaky. However, the expected 
> string assumes ArrayList will have an initial 10 null values. So the pull 
> request in this issue simply creates an ArrayList with 10 initial capacity 
> :-) a naïve approach, but that I believe fixes this test.
> The changes in the pull request linked to this issue have all tests passing 
> with the following set-ups:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
> 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - 

[GitHub] commons-lang pull request #269: LANG-1337: Fix test failures in IBM JDK 8 fo...

[andyklimczak]

Github user andyklimczak commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/269#discussion_r120386094
  
--- Diff: 
src/test/java/org/apache/commons/lang3/builder/ToStringBuilderTest.java ---
@@ -316,7 +316,7 @@ public void testReflectionHierarchyArrayList() {
 // representation different for IBM JDK 1.6.0, LANG-727
 assumeFalse("IBM Corporation".equals(SystemUtils.JAVA_VENDOR) && 
"1.6".equals(SystemUtils.JAVA_SPECIFICATION_VERSION));
 assumeFalse("Oracle Corporation".equals(SystemUtils.JAVA_VENDOR) 
&& "1.6".compareTo(SystemUtils.JAVA_SPECIFICATION_VERSION) < 0);
-final List list = new ArrayList<>();
+final List list = new ArrayList<>(10);
--- End diff --

probably related to [this](https://stackoverflow.com/a/34250231)?


---
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 #269: LANG-1337: Fix test failures in IBM JDK 8 for ToStr...

[andyklimczak]

Github user andyklimczak commented on the issue:

https://github.com/apache/commons-lang/pull/269
  
probably related to [this](https://stackoverflow.com/a/34250231)?


---
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-1337) Fix test failures in IBM JDK 8 for ToStringBuilderTest

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039027#comment-16039027
 ] 

ASF GitHub Bot commented on LANG-1337:
--

Github user sebbASF commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/269#discussion_r120385458
  
--- Diff: 
src/test/java/org/apache/commons/lang3/builder/ToStringBuilderTest.java ---
@@ -316,7 +316,7 @@ public void testReflectionHierarchyArrayList() {
 // representation different for IBM JDK 1.6.0, LANG-727
 assumeFalse("IBM Corporation".equals(SystemUtils.JAVA_VENDOR) && 
"1.6".equals(SystemUtils.JAVA_SPECIFICATION_VERSION));
 assumeFalse("Oracle Corporation".equals(SystemUtils.JAVA_VENDOR) 
&& "1.6".compareTo(SystemUtils.JAVA_SPECIFICATION_VERSION) < 0);
-final List list = new ArrayList<>();
+final List list = new ArrayList<>(10);
--- End diff --

I think that needs a comment.
Is the magic number 10 significant?
If so, what determines the value?
Could it ever change?


> Fix test failures in IBM JDK 8 for ToStringBuilderTest
> --
>
> Key: LANG-1337
> URL: https://issues.apache.org/jira/browse/LANG-1337
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.5
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
> 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> git sha 551101299da7f75ea5478db1a6bc194963e0ac34
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: ibm, ibm-jdk, test
> Fix For: 3.6
>
>
> From the 3.6 thread RC2. We had issues in the release. Two tests failed. One 
> of these tests happened on IBM JDK 8, and was related to time zones. Gary 
> Gregory quickly pointed that the very latest IBM JDK 8 released did not had 
> this issue.
> Indeed, I grabbed a JDK 8 from IBM and had this issue, and then after looking 
> for the latest version, I had only one test failing. This test in question 
> was ToStringBuilderTest#testReflectionHierarchyArrayList.
> Debugging the test in Eclipse, with the JDK pointing to IBM JDK 8 (and taking 
> care to not let the Eclipse maven integration change it), there is a part of 
> the code that receives an ArrayList object to create a String with reflection.
> In Oracle JDK 7, the object contains the default 10 empty positions, and thus 
> the generated String is.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={,},size=0,modCount=0]
> {noformat}
> But with IBM JDK 8, the ArrayList is empty, nada, and then I get the 
> following in the Eclipse debugger.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={},size=0,modCount=0]
> {noformat}
> The test is - as commented in LANG-727 - a bit flaky. However, the expected 
> string assumes ArrayList will have an initial 10 null values. So the pull 
> request in this issue simply creates an ArrayList with 10 initial capacity 
> :-) a naïve approach, but that I believe fixes this test.
> The changes in the pull request linked to this issue have all tests passing 
> with the following set-ups:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java 

[GitHub] commons-lang pull request #269: LANG-1337: Fix test failures in IBM JDK 8 fo...

[sebbASF]

Github user sebbASF commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/269#discussion_r120385458
  
--- Diff: 
src/test/java/org/apache/commons/lang3/builder/ToStringBuilderTest.java ---
@@ -316,7 +316,7 @@ public void testReflectionHierarchyArrayList() {
 // representation different for IBM JDK 1.6.0, LANG-727
 assumeFalse("IBM Corporation".equals(SystemUtils.JAVA_VENDOR) && 
"1.6".equals(SystemUtils.JAVA_SPECIFICATION_VERSION));
 assumeFalse("Oracle Corporation".equals(SystemUtils.JAVA_VENDOR) 
&& "1.6".compareTo(SystemUtils.JAVA_SPECIFICATION_VERSION) < 0);
-final List list = new ArrayList<>();
+final List list = new ArrayList<>(10);
--- End diff --

I think that needs a comment.
Is the magic number 10 significant?
If so, what determines the value?
Could it ever change?


---
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] [Updated] (LANG-1336) Add NUL Byte To CharUtils

[BELUGA BEHR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

BELUGA BEHR updated LANG-1336:
--
Attachment: LANG-1336.1.patch

> Add NUL Byte To CharUtils
> -
>
> Key: LANG-1336
> URL: https://issues.apache.org/jira/browse/LANG-1336
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 2.6
>Reporter: BELUGA BEHR
> Attachments: LANG-1336.1.patch
>
>
> {{CharUtils}} already defines LF and RF, please add NUL
> {code}
> public static final char NUL = '\0';
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (LANG-1336) Add NUL Byte To CharUtils

[BELUGA BEHR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

BELUGA BEHR updated LANG-1336:
--
   Flags: Patch
Priority: Minor  (was: Major)

> Add NUL Byte To CharUtils
> -
>
> Key: LANG-1336
> URL: https://issues.apache.org/jira/browse/LANG-1336
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 2.6
>Reporter: BELUGA BEHR
>Priority: Minor
> Attachments: LANG-1336.1.patch
>
>
> {{CharUtils}} already defines LF and RF, please add NUL
> {code}
> public static final char NUL = '\0';
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IO-538) Non Synchronized CharArrayWriter

[Benedikt Ritter (JIRA)]

[ 
https://issues.apache.org/jira/browse/IO-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038787#comment-16038787
 ] 

Benedikt Ritter commented on IO-538:


Patches welcome!

> Non Synchronized CharArrayWriter 
> -
>
> Key: IO-538
> URL: https://issues.apache.org/jira/browse/IO-538
> Project: Commons IO
>  Issue Type: New Feature
>  Components: Streams/Writers
>Affects Versions: 2.5
>Reporter: BELUGA BEHR
>Priority: Minor
>
> There currently exists {{StringBuilderWriter}}. This implementation, as an 
> alternative to java.io.StringWriter, provides an un-synchronized (i.e. for 
> use in a single thread) implementation for better performance.
> It would be nice if there way one for CharArrayWriter as well.
> https://www.igorkromin.net/index.php/2015/08/20/java-stringwriter-vs-chararraywriter-which-one-to-choose-for-performance/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LANG-1337) Fix test failures in IBM JDK 8 for ToStringBuilderTest

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038755#comment-16038755
 ] 

ASF GitHub Bot commented on LANG-1337:
--

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/269
  

[![Coverage 
Status](https://coveralls.io/builds/11847788/badge)](https://coveralls.io/builds/11847788)

Coverage remained the same at 95.17% when pulling 
**65b08c4f91a4e5d78eb645b46d06d7a46f8c62dd on kinow:LANG-1337** into 
**551101299da7f75ea5478db1a6bc194963e0ac34 on apache:master**.



> Fix test failures in IBM JDK 8 for ToStringBuilderTest
> --
>
> Key: LANG-1337
> URL: https://issues.apache.org/jira/browse/LANG-1337
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.5
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
> 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> git sha 551101299da7f75ea5478db1a6bc194963e0ac34
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: ibm, ibm-jdk, test
> Fix For: 3.6
>
>
> From the 3.6 thread RC2. We had issues in the release. Two tests failed. One 
> of these tests happened on IBM JDK 8, and was related to time zones. Gary 
> Gregory quickly pointed that the very latest IBM JDK 8 released did not had 
> this issue.
> Indeed, I grabbed a JDK 8 from IBM and had this issue, and then after looking 
> for the latest version, I had only one test failing. This test in question 
> was ToStringBuilderTest#testReflectionHierarchyArrayList.
> Debugging the test in Eclipse, with the JDK pointing to IBM JDK 8 (and taking 
> care to not let the Eclipse maven integration change it), there is a part of 
> the code that receives an ArrayList object to create a String with reflection.
> In Oracle JDK 7, the object contains the default 10 empty positions, and thus 
> the generated String is.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={,},size=0,modCount=0]
> {noformat}
> But with IBM JDK 8, the ArrayList is empty, nada, and then I get the 
> following in the Eclipse debugger.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={},size=0,modCount=0]
> {noformat}
> The test is - as commented in LANG-727 - a bit flaky. However, the expected 
> string assumes ArrayList will have an initial 10 null values. So the pull 
> request in this issue simply creates an ArrayList with 10 initial capacity 
> :-) a naïve approach, but that I believe fixes this test.
> The changes in the pull request linked to this issue have all tests passing 
> with the following set-ups:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build 

[GitHub] commons-lang issue #269: LANG-1337: Fix test failures in IBM JDK 8 for ToStr...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/269
  

[![Coverage 
Status](https://coveralls.io/builds/11847788/badge)](https://coveralls.io/builds/11847788)

Coverage remained the same at 95.17% when pulling 
**65b08c4f91a4e5d78eb645b46d06d7a46f8c62dd on kinow:LANG-1337** into 
**551101299da7f75ea5478db1a6bc194963e0ac34 on apache:master**.



---
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] [Closed] (PROXY-25) Various utility methods dealing with Spring proxies

[Benedikt Ritter (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROXY-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter closed PROXY-25.


> Various utility methods dealing with Spring proxies
> ---
>
> Key: PROXY-25
> URL: https://issues.apache.org/jira/browse/PROXY-25
> Project: Commons Proxy
>  Issue Type: New Feature
>Reporter: Yasser Zamani
>Priority: Trivial
>  Labels: github-import
>
> I recently had an accepted merged contribution at [1] which I prefer to
> remove it to Apache Commons Proxy as it is common between developers.
> I plan to add it as [2] via a pull request.
> What do you think?
> [1] 
> https://github.com/apache/struts/blob/master/core/src/main/java/com/opensymphony/xwork2/util/ProxyUtil.java
> [2] 
> https://github.com/apache/commons-proxy/tree/trunk/spring/src/main/java/org/apache/commons/proxy2/spring/SpringUtils.java



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (PROXY-25) Various utility methods dealing with Spring proxies

[Benedikt Ritter (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROXY-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter resolved PROXY-25.
--
Resolution: Won't Do

> Various utility methods dealing with Spring proxies
> ---
>
> Key: PROXY-25
> URL: https://issues.apache.org/jira/browse/PROXY-25
> Project: Commons Proxy
>  Issue Type: New Feature
>Reporter: Yasser Zamani
>Priority: Trivial
>  Labels: github-import
>
> I recently had an accepted merged contribution at [1] which I prefer to
> remove it to Apache Commons Proxy as it is common between developers.
> I plan to add it as [2] via a pull request.
> What do you think?
> [1] 
> https://github.com/apache/struts/blob/master/core/src/main/java/com/opensymphony/xwork2/util/ProxyUtil.java
> [2] 
> https://github.com/apache/commons-proxy/tree/trunk/spring/src/main/java/org/apache/commons/proxy2/spring/SpringUtils.java



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (PROXY-25) Various utility methods dealing with Spring proxies

[Benedikt Ritter (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROXY-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038694#comment-16038694
 ] 

Benedikt Ritter commented on PROXY-25:
--

Hello [~yasser.zamani], sorry, I don't think that commons proxy is the right 
place for this. The use case seems to specific for me to add it to a general 
purpose library.

> Various utility methods dealing with Spring proxies
> ---
>
> Key: PROXY-25
> URL: https://issues.apache.org/jira/browse/PROXY-25
> Project: Commons Proxy
>  Issue Type: New Feature
>Reporter: Yasser Zamani
>Priority: Trivial
>  Labels: github-import
>
> I recently had an accepted merged contribution at [1] which I prefer to
> remove it to Apache Commons Proxy as it is common between developers.
> I plan to add it as [2] via a pull request.
> What do you think?
> [1] 
> https://github.com/apache/struts/blob/master/core/src/main/java/com/opensymphony/xwork2/util/ProxyUtil.java
> [2] 
> https://github.com/apache/commons-proxy/tree/trunk/spring/src/main/java/org/apache/commons/proxy2/spring/SpringUtils.java



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LANG-1337) Fix test failures in IBM JDK 8 for ToStringBuilderTest

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038689#comment-16038689
 ] 

ASF GitHub Bot commented on LANG-1337:
--

GitHub user kinow opened a pull request:

https://github.com/apache/commons-lang/pull/269

LANG-1337: Fix test failures in IBM JDK 8 for ToStringBuilderTest by 
specifying the ArrayList initial capacity.

See https://issues.apache.org/jira/browse/LANG-1337 for issue description 
and explanation of the changes here.

In summary, we specify the ArrayList's initial capacity, this way the 
String built through reflection has the expected value. Tested with Oracle JDK 
7 and 8, and IBM JDK 8.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kinow/commons-lang LANG-1337

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/269.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #269


commit 65b08c4f91a4e5d78eb645b46d06d7a46f8c62dd
Author: Bruno P. Kinoshita 
Date:   2017-06-06T11:41:31Z

LANG-1337: Fix test failures in IBM JDK 8 for ToStringBuilderTest by 
specifying the ArrayList initial capacity.




> Fix test failures in IBM JDK 8 for ToStringBuilderTest
> --
>
> Key: LANG-1337
> URL: https://issues.apache.org/jira/browse/LANG-1337
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.5
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
> 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> git sha 551101299da7f75ea5478db1a6bc194963e0ac34
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: ibm, ibm-jdk, test
> Fix For: 3.6
>
>
> From the 3.6 thread RC2. We had issues in the release. Two tests failed. One 
> of these tests happened on IBM JDK 8, and was related to time zones. Gary 
> Gregory quickly pointed that the very latest IBM JDK 8 released did not had 
> this issue.
> Indeed, I grabbed a JDK 8 from IBM and had this issue, and then after looking 
> for the latest version, I had only one test failing. This test in question 
> was ToStringBuilderTest#testReflectionHierarchyArrayList.
> Debugging the test in Eclipse, with the JDK pointing to IBM JDK 8 (and taking 
> care to not let the Eclipse maven integration change it), there is a part of 
> the code that receives an ArrayList object to create a String with reflection.
> In Oracle JDK 7, the object contains the default 10 empty positions, and thus 
> the generated String is.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={,},size=0,modCount=0]
> {noformat}
> But with IBM JDK 8, the ArrayList is empty, nada, and then I get the 
> following in the Eclipse debugger.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={},size=0,modCount=0]
> {noformat}
> The test is - as commented in LANG-727 - a bit flaky. However, the expected 
> string assumes ArrayList will have an initial 10 null values. So the pull 
> request in this issue simply creates an ArrayList with 10 initial capacity 
> :-) a naïve approach, but that I believe fixes this test.
> The changes in the pull request linked to this issue have all tests passing 
> with the following set-ups:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: 

[GitHub] commons-lang pull request #269: LANG-1337: Fix test failures in IBM JDK 8 fo...

[kinow]

GitHub user kinow opened a pull request:

https://github.com/apache/commons-lang/pull/269

LANG-1337: Fix test failures in IBM JDK 8 for ToStringBuilderTest by 
specifying the ArrayList initial capacity.

See https://issues.apache.org/jira/browse/LANG-1337 for issue description 
and explanation of the changes here.

In summary, we specify the ArrayList's initial capacity, this way the 
String built through reflection has the expected value. Tested with Oracle JDK 
7 and 8, and IBM JDK 8.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kinow/commons-lang LANG-1337

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/269.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #269


commit 65b08c4f91a4e5d78eb645b46d06d7a46f8c62dd
Author: Bruno P. Kinoshita 
Date:   2017-06-06T11:41:31Z

LANG-1337: Fix test failures in IBM JDK 8 for ToStringBuilderTest by 
specifying the ArrayList initial capacity.




---
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] [Created] (LANG-1337) Fix test failures in IBM JDK 8

[Bruno P. Kinoshita (JIRA)]

Bruno P. Kinoshita created LANG-1337:


 Summary: Fix test failures in IBM JDK 8
 Key: LANG-1337
 URL: https://issues.apache.org/jira/browse/LANG-1337
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.*
Affects Versions: 3.5
 Environment: java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
20170516_348050 (JIT enabled, AOT enabled)
J9VM - R28_20170516_1905_B348050
JIT  - tr.r14.java_20170516_348050
GC   - R28_20170516_1905_B348050_CMPRSS
J9CL - 20170516_348050)
JCL - 20170516_01 based on Oracle jdk8u131-b11

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0, vendor: IBM Corporation
Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"

git sha 551101299da7f75ea5478db1a6bc194963e0ac34
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita
Priority: Minor
 Fix For: 3.6


>From the 3.6 thread RC2. We had issues in the release. Two tests failed. One 
>of these tests happened on IBM JDK 8, and was related to time zones. Gary 
>Gregory quickly pointed that the very latest IBM JDK 8 released did not had 
>this issue.

Indeed, I grabbed a JDK 8 from IBM and had this issue, and then after looking 
for the latest version, I had only one test failing. This test in question was 
ToStringBuilderTest#testReflectionHierarchyArrayList.

Debugging the test in Eclipse, with the JDK pointing to IBM JDK 8 (and taking 
care to not let the Eclipse maven integration change it), there is a part of 
the code that receives an ArrayList object to create a String with reflection.

In Oracle JDK 7, the object contains the default 10 empty positions, and thus 
the generated String is.

{noformat}
java.util.ArrayList@761a4a3d[elementData={,},size=0,modCount=0]
{noformat}

But with IBM JDK 8, the ArrayList is empty, nada, and then I get the following 
in the Eclipse debugger.

{noformat}
java.util.ArrayList@761a4a3d[elementData={},size=0,modCount=0]
{noformat}

The test is - as commented in LANG-727 - a bit flaky. However, the expected 
string assumes ArrayList will have an initial 10 null values. So the pull 
request in this issue simply creates an ArrayList with 10 initial capacity :-) 
a naïve approach, but that I believe fixes this test.

The changes in the pull request linked to this issue have all tests passing 
with the following set-ups:

{noformat}
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
---
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
---
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0, vendor: IBM Corporation
Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
---
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
20170516_348050 (JIT enabled, AOT enabled)
J9VM - R28_20170516_1905_B348050
JIT  - tr.r14.java_20170516_348050
GC   - R28_20170516_1905_B348050_CMPRSS
J9CL - 20170516_348050)
JCL - 20170516_01 based on Oracle jdk8u131-b11
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (LANG-1337) Fix test failures in IBM JDK 8 for ToStringBuilderTest

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated LANG-1337:
-
Summary: Fix test failures in IBM JDK 8 for ToStringBuilderTest  (was: Fix 
test failures in IBM JDK 8)

> Fix test failures in IBM JDK 8 for ToStringBuilderTest
> --
>
> Key: LANG-1337
> URL: https://issues.apache.org/jira/browse/LANG-1337
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.5
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
> 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> git sha 551101299da7f75ea5478db1a6bc194963e0ac34
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: ibm, ibm-jdk, test
> Fix For: 3.6
>
>
> From the 3.6 thread RC2. We had issues in the release. Two tests failed. One 
> of these tests happened on IBM JDK 8, and was related to time zones. Gary 
> Gregory quickly pointed that the very latest IBM JDK 8 released did not had 
> this issue.
> Indeed, I grabbed a JDK 8 from IBM and had this issue, and then after looking 
> for the latest version, I had only one test failing. This test in question 
> was ToStringBuilderTest#testReflectionHierarchyArrayList.
> Debugging the test in Eclipse, with the JDK pointing to IBM JDK 8 (and taking 
> care to not let the Eclipse maven integration change it), there is a part of 
> the code that receives an ArrayList object to create a String with reflection.
> In Oracle JDK 7, the object contains the default 10 empty positions, and thus 
> the generated String is.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={,},size=0,modCount=0]
> {noformat}
> But with IBM JDK 8, the ArrayList is empty, nada, and then I get the 
> following in the Eclipse debugger.
> {noformat}
> java.util.ArrayList@761a4a3d[elementData={},size=0,modCount=0]
> {noformat}
> The test is - as commented in LANG-727 - a bit flaky. However, the expected 
> string assumes ArrayList will have an initial 10 null values. So the pull 
> request in this issue simply creates an ArrayList with 10 initial capacity 
> :-) a naïve approach, but that I believe fixes this test.
> The changes in the pull request linked to this issue have all tests passing 
> with the following set-ups:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-11T05:41:47+13:00)
> Maven home: /opt/maven
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: /home/kinow/Development/java/ibm-java-x86_64-80/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-78-generic", arch: "amd64", family: "unix"
> ---
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
> 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> {noformat}

[jira] [Commented] (COLLECTIONS-604) More uniform safe-null methods in CollectionUtils

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038520#comment-16038520
 ] 

Bruno P. Kinoshita commented on COLLECTIONS-604:


Hi [~jholtkamp],

>Should we design an approach together

+1

> or what is your favourite way of implementing this here?

I liked your arguments for an approach that follows the behaviour in 
`StringUtils`.

[~tn], any feedback on this? We might change some JavaDocs, and make it 
null-safe in some cases, without breaking binary compatibility, but still 
changing the behaviour. I was reading the last updates in the tickets, and I 
think we drove the design of many changes in 4.x. So if you have anything in 
mind I'd appreciate any feedback before we start changing the code. Later we 
may look at other classes to make this behaviour consistent across the whole 
[collections] component.

Cheers
Bruno 

> More uniform safe-null methods in CollectionUtils
> -
>
> Key: COLLECTIONS-604
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-604
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection
>Affects Versions: 4.1
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Attachments: COLLECTIONS-604.csv
>
>
> Currently, there are 65 public methods in `CollectionUtils`. And 53 without 
> the deprecated ones. Out of these, 24 handle `null` arguments. The remaining 
> methods throw a `NullPointerException` (NPE) at some part of its code.
> The methods that handle nulls, throw NPE, or return empty columns, boolean 
> values, or just doesn't do anything.
> As a user of the API, I would expect a more uniform behaviour across the 
> methods of `CollectionUtils`. COLLECTIONS-600 address one of these methods.
> `removeAll` (2x) and `retainAll` (2x) both state that a NPE will be thrown if 
> either parameter is `null`. However, they never check if the values are null, 
> and instead allow the code to run until a NPE is thrown.
> And the following code shows that `isEmpty` and `isFull` behave differently 
> too.
> {code:java}
> Collection c = null;
> System.out.println(CollectionUtils.isEmpty(c)); // return true
> System.out.println(CollectionUtils.isFull(c));  // throws a NPE
> {code}
> If I don't have to worry about `null`s with `#isEmpty`, I would expect the 
> same from its related-method `#isFull`.
> What would be a good approach for it? Define a behaviour to all methods? Or 
> leave as is, but add more documentation?
> There are a few methods that can easily be updated to check for `null` 
> values. Others would require a bit more thinking. An example if the method in 
> question for COLLECTIONS-600. It checks equality of collections, and when 
> both collections are `null`, it says that they are equals. Google Guava 
> [Iterables#elementsEqual|https://github.com/google/guava/blob/312aeb938bd35b5b7c8930e19ff5d1ca38e49424/guava/src/com/google/common/collect/Iterables.java#L232]
>  and 
> [Iterators#elementsEqual|https://github.com/google/guava/blob/312aeb938bd35b5b7c8930e19ff5d1ca38e49424/guava/src/com/google/common/collect/Iterators.java#L274]
>  do not check for null values, for what it is worth.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLI-216) Optional support for concatenated option in the DefaultParser

[Rubin Simons (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038359#comment-16038359
 ] 

Rubin Simons commented on CLI-216:
--

Question: is it possible to release an intermediate version 1.5 that includes 
the fixes proposed in this issue and in issue 
[#217|https://issues.apache.org/jira/browse/CLI-217]? This would give users 
some control over partial + combined matching of options.

> Optional support for concatenated option in the DefaultParser
> -
>
> Key: CLI-216
> URL: https://issues.apache.org/jira/browse/CLI-216
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.3
>Reporter: Emmanuel Bourg
>
> DefaultParser supports the concatenated options of the PosixParser (i.e tar 
> -zxvf), but in many cases this behavior is not desirable. This should be made 
> optional.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CLI-217) Optional partial matching for long options

[Rubin Simons (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038338#comment-16038338
 ] 

Rubin Simons edited comment on CLI-217 at 6/6/17 8:15 AM:
--

I was wondering why this issue didn't make it into 1.4. I'm affected by this 
issue in combination with combined options (like described in 
[#216|https://issues.apache.org/jira/browse/CLI-216]). Example:

{code}
Usage: foo [-c | -e | -h | -l | -s | -v] [-d]
 -c,--check Check configuration settings.
 -d,--debug Turn on debug messages.
 -e,--extract   Extract data from rdbms into csv files.
 -h,--help  Show this usage text.
 -l,--load  Load csv files into neo4j.
 -s,--setup Configure settings interactively.
 -v,--version   Show the version.
{code}

Specifying "-dc" passes debug and check to the application. However, specifying 
"-de" does not pass debug and extract to the application but is instead 
interpreted as a "long option, partially specified" namely "debug". Note that 
this occurs even though a single minus sign is used.




was (Author: rubin):
I was wondering why this issue didn't make it into 1.4. I'm affected by this 
issue in combination with combined options (like described in [#216]). Example:

{code}
Usage: foo [-c | -e | -h | -l | -s | -v] [-d]
 -c,--check Check configuration settings.
 -d,--debug Turn on debug messages.
 -e,--extract   Extract data from rdbms into csv files.
 -h,--help  Show this usage text.
 -l,--load  Load csv files into neo4j.
 -s,--setup Configure settings interactively.
 -v,--version   Show the version.
{code}

Specifying "-dc" passes debug and check to the application. However, specifying 
"-de" does not pass debug and extract to the application but is instead 
interpreted as a "long option, partially specified" namely "debug". Note that 
this occurs even though a single minus sign is used.



> Optional partial matching for long options
> --
>
> Key: CLI-217
> URL: https://issues.apache.org/jira/browse/CLI-217
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.3
>Reporter: Emmanuel Bourg
> Attachments: CLI-217.patch, optPartialMatch.patch
>
>
> DefaultParser support partial long options (i.e --ver matches --version if 
> there is no ambiguity), but for some cases it might be necessary to disable 
> this feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CLI-217) Optional partial matching for long options

[Rubin Simons (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038338#comment-16038338
 ] 

Rubin Simons edited comment on CLI-217 at 6/6/17 8:14 AM:
--

I was wondering why this issue didn't make it into 1.4. I'm affected by this 
issue in combination with combined options (like described in [#216]). Example:

{code}
Usage: foo [-c | -e | -h | -l | -s | -v] [-d]
 -c,--check Check configuration settings.
 -d,--debug Turn on debug messages.
 -e,--extract   Extract data from rdbms into csv files.
 -h,--help  Show this usage text.
 -l,--load  Load csv files into neo4j.
 -s,--setup Configure settings interactively.
 -v,--version   Show the version.
{code}

Specifying "-dc" passes debug and check to the application. However, specifying 
"-de" does not pass debug and extract to the application but is instead 
interpreted as a "long option, partially specified" namely "debug". Note that 
this occurs even though a single minus sign is used.




was (Author: rubin):
I was wondering why this issue didn't make it into 1.4. I'm affected by this 
issue in combination with combined options (like described in #216). Example:

{code}
Usage: foo [-c | -e | -h | -l | -s | -v] [-d]
 -c,--check Check configuration settings.
 -d,--debug Turn on debug messages.
 -e,--extract   Extract data from rdbms into csv files.
 -h,--help  Show this usage text.
 -l,--load  Load csv files into neo4j.
 -s,--setup Configure settings interactively.
 -v,--version   Show the version.
{code}

Specifying "-dc" passes debug and check to the application. However, specifying 
"-de" does not pass debug and extract to the application but is instead 
interpreted as a "long option, partially specified" namely "debug". Note that 
this occurs even though a single minus sign is used.



> Optional partial matching for long options
> --
>
> Key: CLI-217
> URL: https://issues.apache.org/jira/browse/CLI-217
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.3
>Reporter: Emmanuel Bourg
> Attachments: CLI-217.patch, optPartialMatch.patch
>
>
> DefaultParser support partial long options (i.e --ver matches --version if 
> there is no ambiguity), but for some cases it might be necessary to disable 
> this feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CLI-217) Optional partial matching for long options

[Rubin Simons (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038338#comment-16038338
 ] 

Rubin Simons edited comment on CLI-217 at 6/6/17 8:12 AM:
--

I was wondering why this issue didn't make it into 1.4. I'm affected by this 
issue in combination with combined options (like described in #216). Example:

{code}
Usage: foo [-c | -e | -h | -l | -s | -v] [-d]
 -c,--check Check configuration settings.
 -d,--debug Turn on debug messages.
 -e,--extract   Extract data from rdbms into csv files.
 -h,--help  Show this usage text.
 -l,--load  Load csv files into neo4j.
 -s,--setup Configure settings interactively.
 -v,--version   Show the version.
{code}

Specifying "-dc" passes debug and check to the application. However, specifying 
"-de" does not pass debug and extract to the application but is instead 
interpreted as a "long option", even though a single minus sign is used.




was (Author: rubin):
I was wondering why this issue didn't make it into 1.4. I'm affected by this 
issue in combination with combined options (like described in #216). Example:

{{
Usage: foo [-c | -e | -h | -l | -s | -v] [-d]
 -c,--check Check configuration settings.
 -d,--debug Turn on debug messages.
 -e,--extract   Extract data from rdbms into csv files.
 -h,--help  Show this usage text.
 -l,--load  Load csv files into neo4j.
 -s,--setup Configure settings interactively.
 -v,--version   Show the version.
}}

Specifying "-dc" passes debug and check to the application. However, specifying 
"-de" does not pass debug and extract to the application but is instead 
interpreted as a "long option", even though a single minus sign is used.



> Optional partial matching for long options
> --
>
> Key: CLI-217
> URL: https://issues.apache.org/jira/browse/CLI-217
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.3
>Reporter: Emmanuel Bourg
> Attachments: CLI-217.patch, optPartialMatch.patch
>
>
> DefaultParser support partial long options (i.e --ver matches --version if 
> there is no ambiguity), but for some cases it might be necessary to disable 
> this feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CLI-217) Optional partial matching for long options

[Rubin Simons (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038338#comment-16038338
 ] 

Rubin Simons edited comment on CLI-217 at 6/6/17 8:10 AM:
--

I was wondering why this issue didn't make it into 1.4. I'm affected by this 
issue in combination with combined options (like described in #216). Example:

{{
Usage: foo [-c | -e | -h | -l | -s | -v] [-d]
 -c,--check Check configuration settings.
 -d,--debug Turn on debug messages.
 -e,--extract   Extract data from rdbms into csv files.
 -h,--help  Show this usage text.
 -l,--load  Load csv files into neo4j.
 -s,--setup Configure settings interactively.
 -v,--version   Show the version.
}}

Specifying "-dc" passes debug and check to the application. However, specifying 
"-de" does not pass debug and extract to the application but is instead 
interpreted as a "long option", even though a single minus sign is used.




was (Author: rubin):
I was wondering why this issue didn't make it into 1.4. I'm affected by this 
issue in combination with combined options (like described in #216). Example:

Usage: foo [-c | -e | -h | -l | -s | -v] [-d]
 -c,--check Check configuration settings.
 -d,--debug Turn on debug messages.
 -e,--extract   Extract data from rdbms into csv files.
 -h,--help  Show this usage text.
 -l,--load  Load csv files into neo4j.
 -s,--setup Configure settings interactively.
 -v,--version   Show the version.

Specifying "-dc" passes debug and check to the application. However, specifying 
"-de" does not pass debug and extract to the application but is instead 
interpreted as a "long option", even though a single minus sign is used.



> Optional partial matching for long options
> --
>
> Key: CLI-217
> URL: https://issues.apache.org/jira/browse/CLI-217
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.3
>Reporter: Emmanuel Bourg
> Attachments: CLI-217.patch, optPartialMatch.patch
>
>
> DefaultParser support partial long options (i.e --ver matches --version if 
> there is no ambiguity), but for some cases it might be necessary to disable 
> this feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLI-217) Optional partial matching for long options

[Rubin Simons (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038338#comment-16038338
 ] 

Rubin Simons commented on CLI-217:
--

I was wondering why this issue didn't make it into 1.4. I'm affected by this 
issue in combination with combined options (like described in #216). Example:

Usage: foo [-c | -e | -h | -l | -s | -v] [-d]
 -c,--check Check configuration settings.
 -d,--debug Turn on debug messages.
 -e,--extract   Extract data from rdbms into csv files.
 -h,--help  Show this usage text.
 -l,--load  Load csv files into neo4j.
 -s,--setup Configure settings interactively.
 -v,--version   Show the version.

Specifying "-dc" passes debug and check to the application. However, specifying 
"-de" does not pass debug and extract to the application but is instead 
interpreted as a "long option", even though a single minus sign is used.



> Optional partial matching for long options
> --
>
> Key: CLI-217
> URL: https://issues.apache.org/jira/browse/CLI-217
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.3
>Reporter: Emmanuel Bourg
> Attachments: CLI-217.patch, optPartialMatch.patch
>
>
> DefaultParser support partial long options (i.e --ver matches --version if 
> there is no ambiguity), but for some cases it might be necessary to disable 
> this feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)