[jira] [Commented] (NUMBERS-40) Review exception usage in package "o.a.c.numbers.gamma"

2017-06-07 Thread Gilles (JIRA)

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

Gilles commented on NUMBERS-40:
---

Hi "tharakadesilva".

Thanks for your interest in this new component.
Design issues such as this one need to be discussed and agreed on the "dev" ML. 
Please subscribe if not done already, and let us know your rationale behind the 
suggested change.


> Review exception usage in package "o.a.c.numbers.gamma"
> ---
>
> Key: NUMBERS-40
> URL: https://issues.apache.org/jira/browse/NUMBERS-40
> Project: Commons Numbers
>  Issue Type: Bug
>Reporter: Gilles
>  Labels: exception
> Fix For: 1.0
>
>
> Exceptions raised should have a consistent type ({{ArithmeticException}} vs 
> {{IllegalArgumentException}}).



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


[jira] [Commented] (VFS-627) SFTP randomly hangs when copying a file on remote server

2017-06-07 Thread Bernd Eckenfels (JIRA)

[ 
https://issues.apache.org/jira/browse/VFS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041674#comment-16041674
 ] 

Bernd Eckenfels commented on VFS-627:
-

[~aditya0403] Could you please provide multiple "jstack -l" invocation results 
(with a few seconds in between) and the full stack trace of the seemingly 
blocking operation. Can you also provide "netstat -t" on client and server (and 
tell us wich established TCP connection it is).

> SFTP randomly hangs when copying a file on remote server
> 
>
> Key: VFS-627
> URL: https://issues.apache.org/jira/browse/VFS-627
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: Java 1.8.0_92
> VFS 2.1
> JSch 0.1.53
>Reporter: Henri Hagberg
>
> I have a process where a file is first copied over SFTP to local server and 
> then on the remote server the file is copied to another location on that 
> server for archiving. Both are done using {{FileObject#copyFrom}}. Now I've 
> encountered twice the situation where during archiving (on remote server) the 
> copy action hangs indefinitely (the process was left running for over 24 
> hours). In both cases the issue happened when around 2000 files had been 
> transferred (typical amount is under 100).
> The problem is difficult to reproduce since it doesn't always happen even 
> with large number of files. Based on the stacktrace and random occurrences it 
> might be a concurrency issue. The code using VFS however is single threaded.
> {code}
> Attaching to process ID 128021, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 25.92-b14
> Deadlock Detection:
> No deadlocks found.
> Thread 19073: (state = BLOCKED)
> Thread 128165: (state = BLOCKED)
>  - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be 
> imprecise)
>  - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Compiled 
> frame)
>  - org.apache.commons.vfs2.cache.SoftRefFilesCache$SoftRefReleaseThread.run() 
> @bci=26, line=84 (Compiled frame)
> Thread 128164: (state = BLOCKED)
>  - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be 
> imprecise)
>  - java.io.PipedInputStream.awaitSpace() @bci=23, line=273 (Compiled frame)
>  - java.io.PipedInputStream.receive(byte[], int, int) @bci=31, line=231 
> (Compiled frame)
>  - java.io.PipedOutputStream.write(byte[], int, int) @bci=77, line=149 
> (Compiled frame)
>  - com.jcraft.jsch.IO.put(byte[], int, int) @bci=7, line=64 (Compiled frame)
>  - com.jcraft.jsch.Channel.write(byte[], int, int) @bci=7, line=438 (Compiled 
> frame)
>  - com.jcraft.jsch.Session.run() @bci=1260, line=1624 (Compiled frame)
>  - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
> Thread 128139: (state = BLOCKED)
> Thread 128138: (state = BLOCKED)
>  - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be 
> imprecise)
>  - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Compiled 
> frame)
>  - java.lang.ref.ReferenceQueue.remove() @bci=2, line=164 (Compiled frame)
>  - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209 
> (Interpreted frame)
> Thread 128137: (state = BLOCKED)
>  - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be 
> imprecise)
>  - java.lang.Object.wait() @bci=2, line=502 (Compiled frame)
>  - java.lang.ref.Reference.tryHandlePending(boolean) @bci=54, line=191 
> (Compiled frame)
>  - java.lang.ref.Reference$ReferenceHandler.run() @bci=1, line=153 
> (Interpreted frame)
> Thread 128022: (state = BLOCKED)
>  - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be 
> imprecise)
>  - com.jcraft.jsch.Session.write(com.jcraft.jsch.Packet, 
> com.jcraft.jsch.Channel, int) @bci=89, line=1261 (Compiled frame)
>  - com.jcraft.jsch.ChannelSftp.sendWRITE(byte[], long, byte[], int, int) 
> @bci=191, line=2619 (Compiled frame)
>  - com.jcraft.jsch.ChannelSftp.access$100(com.jcraft.jsch.ChannelSftp, 
> byte[], long, byte[], int, int) @bci=9, line=36 (Compiled frame)
>  - com.jcraft.jsch.ChannelSftp$1.write(byte[], int, int) @bci=77, line=791 
> (Compiled frame)
>  - java.io.BufferedOutputStream.write(byte[], int, int) @bci=20, line=122 
> (Compiled frame)
>  - org.apache.commons.vfs2.util.MonitorOutputStream.write(byte[], int, int) 
> @bci=8, line=123 (Compiled frame)
>  - java.io.BufferedOutputStream.flushBuffer() @bci=20, line=82 (Compiled 
> frame)
>  - java.io.BufferedOutputStream.write(byte[], int, int) @bci=39, line=126 
> (Compiled frame)
>  - org.apache.commons.vfs2.util.MonitorOutputStream.write(byte[], int, int) 
> @bci=8, line=123 (Compiled frame)
>  - 
> org.apache.commons.vfs2.provider.DefaultFileContent.write(java.io.OutputStream,
>  int) @bci=35, line=892 (Compiled frame)
>  - 
> 

[jira] [Commented] (NUMBERS-40) Review exception usage in package "o.a.c.numbers.gamma"

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

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

Github user coveralls commented on the issue:

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

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

Coverage remained the same at 83.124% when pulling 
**aadb0f0962a76264c7d8607453f6495e432a89d5 on tharakadesilva:desilva/develop** 
into **c2bfc4fbf8fe325eaf254c37128948b7644e5687 on apache:master**.



> Review exception usage in package "o.a.c.numbers.gamma"
> ---
>
> Key: NUMBERS-40
> URL: https://issues.apache.org/jira/browse/NUMBERS-40
> Project: Commons Numbers
>  Issue Type: Bug
>Reporter: Gilles
>  Labels: exception
> Fix For: 1.0
>
>
> Exceptions raised should have a consistent type ({{ArithmeticException}} vs 
> {{IllegalArgumentException}}).



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


[jira] [Commented] (NUMBERS-40) Review exception usage in package "o.a.c.numbers.gamma"

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

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

GitHub user tharakadesilva opened a pull request:

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

NUMBERS-40

Modified "GammaException" to be a subclass of "ArithmeticException" instead 
of "IllegalArgumentException".
Modified the test assertions to expect for "GammaException"s instead of 
"IllegalArgumentException"s.

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

$ git pull https://github.com/tharakadesilva/commons-numbers desilva/develop

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

https://github.com/apache/commons-numbers/pull/6.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 #6


commit 813c6707ea0d47c78fc25ca79f6df990e6b8bf67
Author: Tharaka De Silva 
Date:   2017-06-07T19:21:23Z

modified GammaException to be a part of ArithmeticException instead of 
IllegalArgumentException

commit aadb0f0962a76264c7d8607453f6495e432a89d5
Author: Tharaka De Silva 
Date:   2017-06-07T19:25:01Z

modified the test assertions to assert for the GammaException




> Review exception usage in package "o.a.c.numbers.gamma"
> ---
>
> Key: NUMBERS-40
> URL: https://issues.apache.org/jira/browse/NUMBERS-40
> Project: Commons Numbers
>  Issue Type: Bug
>Reporter: Gilles
>  Labels: exception
> Fix For: 1.0
>
>
> Exceptions raised should have a consistent type ({{ArithmeticException}} vs 
> {{IllegalArgumentException}}).



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


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

2017-06-07 Thread Steven Sheehy (JIRA)

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

Steven Sheehy commented on VALIDATOR-427:
-

My main focus is on the 4th bullet point above about not guaranteeing 
updateTLDOverride() can be called first in all situations, so if we take the 
approach you recommend of setting at construction time, that would work for me 
as well.

Though I believe that link you specified about volatile does not apply here 
since the arrays are never modified after construction and are defensively 
copied when exposed. The volatile keyword guarantees member assignment is 
atomic and, in this case, any use of that member is read only and will at worse 
get an out of date object reference if updateTLDOverride() was called. If need 
be, the internal array representation can be changed to a 
Collections.unmodifiableCollection() to enforce immutability. I can submit a 
patch for this if you want? I'm not sure how to accomplish the other 
construction-based you mention.

> 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] (TEXT-80) StrLookup API confusing

2017-06-07 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TEXT-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041035#comment-16041035
 ] 

ASF GitHub Bot commented on TEXT-80:


Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/44
  
Hi @chtompki , since commons-text is relatively new there are very [low 
usage](https://mvnrepository.com/artifact/org.apache.commons/commons-text), 
```clirr:check``` is also passed whoever is using it and wants to bump version 
needs minor change in their code, but its ok we can park it till 2.X release.


> StrLookup API confusing
> ---
>
> Key: TEXT-80
> URL: https://issues.apache.org/jira/browse/TEXT-80
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Etienne Neveu
> Fix For: 1.x
>
>
> [bayard: copying this from LANG-564]
> I don't see the point of having a generic type parameter on the StrLookup 
> class, if it's not used anywhere. No method / field in StrLookup references 
> this type parameter. IntelliJ IDEA itself reports a warning: "Type parameter 
> 'V' is never used". Moreover, Java generics are not reified, so there is no 
> reliable way to access the type parameter at runtime (and I don't see the 
> point of doing that anyway...).
> While the Javadoc tries to clarify the purpose of a StrLookup, the unused 
> type parameter is still confusing, and the client code has to un-necessarily 
> specify type parameters. For example, I have to write:
> StrLookup lookup = StrLookup.noneLookup();
> StrLookup lookup2 = StrLookup.systemPropertiesLookup();
> StrLookup lookup3 = StrLookup.mapLookup(integerMap);
> instead of
> StrLookup lookup = StrLookup.noneLookup();
> StrLookup lookup2 = StrLookup.systemPropertiesLookup();
> StrLookup lookup3 = StrLookup.mapLookup(integerMap);
> My best guess is that this type parameter was added when commons-lang was 
> generified, because StringLookup.mapLookup() takes a generified Map. Doing 
> this is not really needed, though: we could remove the  type parameter 
> everywhere, and replace the StrLookup.mapLookup()'s Map with a 
> Map (which is the same as Map, but 
> shorter).
> I guess it's too late to change this now, due to backward compatibility... 
> But I thought I'd comment just in case it's still possible.



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


[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

2017-06-07 Thread Arun Vinud (JIRA)

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040890#comment-16040890
 ] 

Arun Vinud  commented on TEXT-85:
-

Sounds like a great idea and indeed it would be a very useful addition . I can 
work on this and looks like an ideal start for my contribution to this amazing 
community .

> Create CaseUtils class. Add toCamelCase
> ---
>
> Key: TEXT-85
> URL: https://issues.apache.org/jira/browse/TEXT-85
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>
> Based on the conversation here:
> http://markmail.org/message/7nvizsbykvxpr7g5
> We wish to have a {{toCamelCase}} method. The suggestion is to create a 
> {{CaseUtils}} class.
> I wonder if we should think about deprecating the case management in 
> {{WordUtils}} and move it over? Maybe, maybe not.
> I would think our method signature would look something like:
> {code}
> String toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)
> {code}
> potentially with {{String}} replaced with {{CharSequence}}.
> Lastly, {{WordUtils.capitalizeFully(String str, final char... delimiters)}} 
> might be a good starting point. 
> https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/WordUtils.java#L467-L499



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


[jira] [Commented] (TEXT-80) StrLookup API confusing

2017-06-07 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TEXT-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040852#comment-16040852
 ] 

ASF GitHub Bot commented on TEXT-80:


Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/44
  
The change is generally all right with me, but we can't release this until 
a 2.X release though because of signature changes.


> StrLookup API confusing
> ---
>
> Key: TEXT-80
> URL: https://issues.apache.org/jira/browse/TEXT-80
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Etienne Neveu
> Fix For: 1.x
>
>
> [bayard: copying this from LANG-564]
> I don't see the point of having a generic type parameter on the StrLookup 
> class, if it's not used anywhere. No method / field in StrLookup references 
> this type parameter. IntelliJ IDEA itself reports a warning: "Type parameter 
> 'V' is never used". Moreover, Java generics are not reified, so there is no 
> reliable way to access the type parameter at runtime (and I don't see the 
> point of doing that anyway...).
> While the Javadoc tries to clarify the purpose of a StrLookup, the unused 
> type parameter is still confusing, and the client code has to un-necessarily 
> specify type parameters. For example, I have to write:
> StrLookup lookup = StrLookup.noneLookup();
> StrLookup lookup2 = StrLookup.systemPropertiesLookup();
> StrLookup lookup3 = StrLookup.mapLookup(integerMap);
> instead of
> StrLookup lookup = StrLookup.noneLookup();
> StrLookup lookup2 = StrLookup.systemPropertiesLookup();
> StrLookup lookup3 = StrLookup.mapLookup(integerMap);
> My best guess is that this type parameter was added when commons-lang was 
> generified, because StringLookup.mapLookup() takes a generified Map. Doing 
> this is not really needed, though: we could remove the  type parameter 
> everywhere, and replace the StrLookup.mapLookup()'s Map with a 
> Map (which is the same as Map, but 
> shorter).
> I guess it's too late to change this now, due to backward compatibility... 
> But I thought I'd comment just in case it's still possible.



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


[jira] [Created] (TEXT-85) Create CaseUtils class. Add toCamelCase

2017-06-07 Thread Rob Tompkins (JIRA)
Rob Tompkins created TEXT-85:


 Summary: Create CaseUtils class. Add toCamelCase
 Key: TEXT-85
 URL: https://issues.apache.org/jira/browse/TEXT-85
 Project: Commons Text
  Issue Type: Improvement
Reporter: Rob Tompkins


Based on the conversation here:
http://markmail.org/message/7nvizsbykvxpr7g5

We wish to have a {{toCamelCase}} method. The suggestion is to create a 
{{CaseUtils}} class.

I wonder if we should think about deprecating the case management in 
{{WordUtils}} and move it over? Maybe, maybe not.

I would think our method signature would look something like:
{code}
String toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)
{code}
potentially with {{String}} replaced with {{CharSequence}}.

Lastly, {{WordUtils.capitalizeFully(String str, final char... delimiters)}} 
might be a good starting point. 
https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/WordUtils.java#L467-L499



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


[jira] [Commented] (VFS-627) SFTP randomly hangs when copying a file on remote server

2017-06-07 Thread Aditya Kunkolienkar (JIRA)

[ 
https://issues.apache.org/jira/browse/VFS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040745#comment-16040745
 ] 

Aditya Kunkolienkar commented on VFS-627:
-

I am facing similar issue where it gets stuck in DefaultFileContent line number 
894.

It gets stuck in below while loop after few iterations:
final byte[] buffer = new byte[bufferSize];
int n = 0;
while (-1 != (n = input.read(buffer)))
{
output.write(buffer, 0, n);
count += n;
}

> SFTP randomly hangs when copying a file on remote server
> 
>
> Key: VFS-627
> URL: https://issues.apache.org/jira/browse/VFS-627
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: Java 1.8.0_92
> VFS 2.1
> JSch 0.1.53
>Reporter: Henri Hagberg
>
> I have a process where a file is first copied over SFTP to local server and 
> then on the remote server the file is copied to another location on that 
> server for archiving. Both are done using {{FileObject#copyFrom}}. Now I've 
> encountered twice the situation where during archiving (on remote server) the 
> copy action hangs indefinitely (the process was left running for over 24 
> hours). In both cases the issue happened when around 2000 files had been 
> transferred (typical amount is under 100).
> The problem is difficult to reproduce since it doesn't always happen even 
> with large number of files. Based on the stacktrace and random occurrences it 
> might be a concurrency issue. The code using VFS however is single threaded.
> {code}
> Attaching to process ID 128021, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 25.92-b14
> Deadlock Detection:
> No deadlocks found.
> Thread 19073: (state = BLOCKED)
> Thread 128165: (state = BLOCKED)
>  - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be 
> imprecise)
>  - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Compiled 
> frame)
>  - org.apache.commons.vfs2.cache.SoftRefFilesCache$SoftRefReleaseThread.run() 
> @bci=26, line=84 (Compiled frame)
> Thread 128164: (state = BLOCKED)
>  - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be 
> imprecise)
>  - java.io.PipedInputStream.awaitSpace() @bci=23, line=273 (Compiled frame)
>  - java.io.PipedInputStream.receive(byte[], int, int) @bci=31, line=231 
> (Compiled frame)
>  - java.io.PipedOutputStream.write(byte[], int, int) @bci=77, line=149 
> (Compiled frame)
>  - com.jcraft.jsch.IO.put(byte[], int, int) @bci=7, line=64 (Compiled frame)
>  - com.jcraft.jsch.Channel.write(byte[], int, int) @bci=7, line=438 (Compiled 
> frame)
>  - com.jcraft.jsch.Session.run() @bci=1260, line=1624 (Compiled frame)
>  - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
> Thread 128139: (state = BLOCKED)
> Thread 128138: (state = BLOCKED)
>  - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be 
> imprecise)
>  - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Compiled 
> frame)
>  - java.lang.ref.ReferenceQueue.remove() @bci=2, line=164 (Compiled frame)
>  - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209 
> (Interpreted frame)
> Thread 128137: (state = BLOCKED)
>  - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be 
> imprecise)
>  - java.lang.Object.wait() @bci=2, line=502 (Compiled frame)
>  - java.lang.ref.Reference.tryHandlePending(boolean) @bci=54, line=191 
> (Compiled frame)
>  - java.lang.ref.Reference$ReferenceHandler.run() @bci=1, line=153 
> (Interpreted frame)
> Thread 128022: (state = BLOCKED)
>  - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be 
> imprecise)
>  - com.jcraft.jsch.Session.write(com.jcraft.jsch.Packet, 
> com.jcraft.jsch.Channel, int) @bci=89, line=1261 (Compiled frame)
>  - com.jcraft.jsch.ChannelSftp.sendWRITE(byte[], long, byte[], int, int) 
> @bci=191, line=2619 (Compiled frame)
>  - com.jcraft.jsch.ChannelSftp.access$100(com.jcraft.jsch.ChannelSftp, 
> byte[], long, byte[], int, int) @bci=9, line=36 (Compiled frame)
>  - com.jcraft.jsch.ChannelSftp$1.write(byte[], int, int) @bci=77, line=791 
> (Compiled frame)
>  - java.io.BufferedOutputStream.write(byte[], int, int) @bci=20, line=122 
> (Compiled frame)
>  - org.apache.commons.vfs2.util.MonitorOutputStream.write(byte[], int, int) 
> @bci=8, line=123 (Compiled frame)
>  - java.io.BufferedOutputStream.flushBuffer() @bci=20, line=82 (Compiled 
> frame)
>  - java.io.BufferedOutputStream.write(byte[], int, int) @bci=39, line=126 
> (Compiled frame)
>  - org.apache.commons.vfs2.util.MonitorOutputStream.write(byte[], int, int) 
> @bci=8, line=123 (Compiled frame)
>  - 
> 

[jira] [Commented] (LANG-1338) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on LANG-1338:
--

Github user coveralls commented on the issue:

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

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

Coverage increased (+0.05%) to 95.221% when pulling 
**1cada6e9561ef261db31bcc8f70be55b3091ad0e on britter:LANG-1338** into 
**ad648cf8a8a90bdee129266ca7b686a5b9a87561 on apache:master**.



> Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
> -
>
> Key: LANG-1338
> URL: https://issues.apache.org/jira/browse/LANG-1338
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
>  Labels: Java9
> Fix For: 3.6
>
>
> In order to make Commons Lang usable in Java 9 module system, we need to add 
> a new entry to the MANIFEST file as a temporary fix before we we can compile 
> on Java 9 and add a module-info.java file.
> We had discussions on the ML on how to fix this in parent pom (see 
> http://markmail.org/message/5imtc5q4gsbg4alm), but we haven't reached 
> consensus about how to implement this.



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


[GitHub] commons-lang issue #270: LANG-1338: Add Automatic-Module-Name MANIFEST entry...

2017-06-07 Thread coveralls
Github user coveralls commented on the issue:

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

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

Coverage increased (+0.05%) to 95.221% when pulling 
**1cada6e9561ef261db31bcc8f70be55b3091ad0e on britter:LANG-1338** into 
**ad648cf8a8a90bdee129266ca7b686a5b9a87561 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] [Commented] (LANG-1338) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on LANG-1338:
--

GitHub user britter opened a pull request:

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

LANG-1338: Add Automatic-Module-Name MANIFEST entry for Java 9 
compatibility.

This change duplicates the maven-jar-plugin configuration from parent
pom. After we have implemented a solution for this in parent pom, this
commit should be reverted.

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

$ git pull https://github.com/britter/commons-lang LANG-1338

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

https://github.com/apache/commons-lang/pull/270.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 #270






> Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
> -
>
> Key: LANG-1338
> URL: https://issues.apache.org/jira/browse/LANG-1338
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
>  Labels: Java9
> Fix For: 3.6
>
>
> In order to make Commons Lang usable in Java 9 module system, we need to add 
> a new entry to the MANIFEST file as a temporary fix before we we can compile 
> on Java 9 and add a module-info.java file.
> We had discussions on the ML on how to fix this in parent pom (see 
> http://markmail.org/message/5imtc5q4gsbg4alm), but we haven't reached 
> consensus about how to implement this.



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


[GitHub] commons-lang pull request #270: LANG-1338: Add Automatic-Module-Name MANIFES...

2017-06-07 Thread britter
GitHub user britter opened a pull request:

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

LANG-1338: Add Automatic-Module-Name MANIFEST entry for Java 9 
compatibility.

This change duplicates the maven-jar-plugin configuration from parent
pom. After we have implemented a solution for this in parent pom, this
commit should be reverted.

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

$ git pull https://github.com/britter/commons-lang LANG-1338

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

https://github.com/apache/commons-lang/pull/270.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 #270






---
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-1339) Some classes depend on the java.desktop profile

2017-06-07 Thread Benedikt Ritter (JIRA)

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

Benedikt Ritter updated LANG-1339:
--
Fix Version/s: 3.7

> Some classes depend on the java.desktop profile
> ---
>
> Key: LANG-1339
> URL: https://issues.apache.org/jira/browse/LANG-1339
> Project: Commons Lang
>  Issue Type: Task
>Reporter: Benedikt Ritter
>  Labels: Java9
> Fix For: 3.7
>
>
> Commons Lang currently depends on java.desktop. This seems like an 
> unnecessary heavy dependency for a library like Commons Lang. We need to find 
> a way to fix this, without breaking bc. For more information see 
> https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E



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


[jira] [Created] (LANG-1339) Some classes depend on the java.desktop profile

2017-06-07 Thread Benedikt Ritter (JIRA)
Benedikt Ritter created LANG-1339:
-

 Summary: Some classes depend on the java.desktop profile
 Key: LANG-1339
 URL: https://issues.apache.org/jira/browse/LANG-1339
 Project: Commons Lang
  Issue Type: Task
Reporter: Benedikt Ritter


Commons Lang currently depends on java.desktop. This seems like an unnecessary 
heavy dependency for a library like Commons Lang. We need to find a way to fix 
this, without breaking bc. For more information see 
https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E



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


[jira] [Updated] (LANG-1338) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility

2017-06-07 Thread Benedikt Ritter (JIRA)

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

Benedikt Ritter updated LANG-1338:
--
Labels: Java9  (was: )

> Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
> -
>
> Key: LANG-1338
> URL: https://issues.apache.org/jira/browse/LANG-1338
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
>  Labels: Java9
> Fix For: 3.6
>
>
> In order to make Commons Lang usable in Java 9 module system, we need to add 
> a new entry to the MANIFEST file as a temporary fix before we we can compile 
> on Java 9 and add a module-info.java file.
> We had discussions on the ML on how to fix this in parent pom (see 
> http://markmail.org/message/5imtc5q4gsbg4alm), but we haven't reached 
> consensus about how to implement this.



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


[jira] [Updated] (LANG-1338) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility

2017-06-07 Thread Benedikt Ritter (JIRA)

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

Benedikt Ritter updated LANG-1338:
--
Fix Version/s: 3.6

> Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
> -
>
> Key: LANG-1338
> URL: https://issues.apache.org/jira/browse/LANG-1338
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
>  Labels: Java9
> Fix For: 3.6
>
>
> In order to make Commons Lang usable in Java 9 module system, we need to add 
> a new entry to the MANIFEST file as a temporary fix before we we can compile 
> on Java 9 and add a module-info.java file.
> We had discussions on the ML on how to fix this in parent pom (see 
> http://markmail.org/message/5imtc5q4gsbg4alm), but we haven't reached 
> consensus about how to implement this.



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


[jira] [Commented] (LANG-1338) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility

2017-06-07 Thread Benedikt Ritter (JIRA)

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

Benedikt Ritter commented on LANG-1338:
---

I don't want to delay the 3.6 release any longer, so I'm going to temporary 
duplicate the maven-jar-plugin configuration from parent pom in Lang with the 
addition of the Automatic-Module-Name entry.

> Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
> -
>
> Key: LANG-1338
> URL: https://issues.apache.org/jira/browse/LANG-1338
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
>
> In order to make Commons Lang usable in Java 9 module system, we need to add 
> a new entry to the MANIFEST file as a temporary fix before we we can compile 
> on Java 9 and add a module-info.java file.
> We had discussions on the ML on how to fix this in parent pom (see 
> http://markmail.org/message/5imtc5q4gsbg4alm), but we haven't reached 
> consensus about how to implement this.



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


[jira] [Created] (LANG-1338) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility

2017-06-07 Thread Benedikt Ritter (JIRA)
Benedikt Ritter created LANG-1338:
-

 Summary: Add Automatic-Module-Name MANIFEST entry for Java 9 
compatibility
 Key: LANG-1338
 URL: https://issues.apache.org/jira/browse/LANG-1338
 Project: Commons Lang
  Issue Type: Improvement
Reporter: Benedikt Ritter
Assignee: Benedikt Ritter


In order to make Commons Lang usable in Java 9 module system, we need to add a 
new entry to the MANIFEST file as a temporary fix before we we can compile on 
Java 9 and add a module-info.java file.

We had discussions on the ML on how to fix this in parent pom (see 
http://markmail.org/message/5imtc5q4gsbg4alm), but we haven't reached consensus 
about how to implement this.



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


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

2017-06-07 Thread Benedikt Ritter (JIRA)

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

Benedikt Ritter resolved LANG-1336.
---
   Resolution: Fixed
Fix Version/s: 3.6

{code}
Counting objects: 22, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (13/13), done.
Writing objects: 100% (22/22), 3.90 KiB | 0 bytes/s, done.
Total 22 (delta 8), reused 0 (delta 0)
remote: [lang] LANG-1336: Add NUL Byte To CharUtils. Thanks to Beluga Behr.
To https://git-wip-us.apache.org/repos/asf/commons-lang.git
   21bab1d3..ad648cf8  master -> master
{code}

Thank you!

Note, that you can also contribute using our GitHub mirror at 
https://github.com/apache/commons-lang

> 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
>Assignee: Benedikt Ritter
>Priority: Minor
> Fix For: 3.6
>
> 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] [Resolved] (LANG-1337) Fix test failures in IBM JDK 8 for ToStringBuilderTest

2017-06-07 Thread Benedikt Ritter (JIRA)

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

Benedikt Ritter resolved LANG-1337.
---
Resolution: Fixed

Merged PR. Thank you!

> 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}



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


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

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on LANG-1337:
--

Github user asfgit closed the pull request at:

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


> 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 

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

2017-06-07 Thread asfgit
Github user asfgit closed the pull request at:

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


---
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...

2017-06-07 Thread coveralls
Github user coveralls commented on the issue:

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

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

Coverage increased (+0.05%) to 95.221% when pulling 
**c68285bb3392665827595ac408a5fad828b0351f 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] [Commented] (LANG-1337) Fix test failures in IBM JDK 8 for ToStringBuilderTest

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

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/11862777/badge)](https://coveralls.io/builds/11862777)

Coverage increased (+0.05%) to 95.221% when pulling 
**c68285bb3392665827595ac408a5fad828b0351f 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 

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

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on LANG-1337:
--

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/269
  
Comments added, received some feedback, but would still be useful someone 
with the last IBM JDK 8 to give it a try and confirm it works for him/her :)


> 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 - 

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

2017-06-07 Thread kinow
Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/269
  
Comments added, received some feedback, but would still be useful someone 
with the last IBM JDK 8 to give it a try and confirm it works for him/her :)


---
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] (VFS-438) Please promote vfs-smb currently in the sandbox

2017-06-07 Thread Gary Gregory (JIRA)

[ 
https://issues.apache.org/jira/browse/VFS-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040373#comment-16040373
 ] 

Gary Gregory commented on VFS-438:
--

Yes, I suppose that is OK. Thank you for the link.

> Please promote vfs-smb currently in the sandbox
> ---
>
> Key: VFS-438
> URL: https://issues.apache.org/jira/browse/VFS-438
> Project: Commons VFS
>  Issue Type: New Feature
>Affects Versions: 2.0
> Environment: windows/unix
>Reporter: Dan Tran
>
> Current smb provider in the sandbox is mature enough to proceed with 
> promotion out of sandbox for general use. 
> Detail discussion is here 
> http://apache-commons.680414.n4.nabble.com/Promote-vfs-cift-out-of-sandbox-td4636519.html
> The sandbox also tests hookup to current test suite, all we need is to 
> provide a external URI using VFS test suite instructions.
> There are currently 2 classloader specific failures
> Tests in error:
>   testLoadClass(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests):
> code.ClassToLoad
>   testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests):
> code.sealed.AnotherClass
> Tests run: 1745, Failures: 0, Errors: 2, Skipped: 0
> require cifs  1.3.17 with one line change at 
> SmbFileObject.java line number 227 to 
> if (e.getNtStatus() == SmbException.NT_STATUS_NO_SUCH_FILE)



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


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

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on LANG-1337:
--

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

https://github.com/apache/commons-lang/pull/269#discussion_r120550160
  
--- Diff: 
src/test/java/org/apache/commons/lang3/builder/ToStringBuilderTest.java ---
@@ -316,7 +317,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<>(arraylistInitialCapacity);
--- End diff --

Roger that. Will add a note to myself to fix the other final member 
variables later... trying to be concise, but I'm clearly missing the point here 
:-) was supposedly to be a very simple fix for this issue. Pushing a new commit 
in a few minutes, just finishing to review commons-fileupload vote.


> 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: 

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

2017-06-07 Thread kinow
Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/269#discussion_r120550160
  
--- Diff: 
src/test/java/org/apache/commons/lang3/builder/ToStringBuilderTest.java ---
@@ -316,7 +317,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<>(arraylistInitialCapacity);
--- End diff --

Roger that. Will add a note to myself to fix the other final member 
variables later... trying to be concise, but I'm clearly missing the point here 
:-) was supposedly to be a very simple fix for this issue. Pushing a new commit 
in a few minutes, just finishing to review commons-fileupload vote.


---
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

2017-06-07 Thread Benedikt Ritter (JIRA)

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

Benedikt Ritter updated LANG-1336:
--
Assignee: Benedikt Ritter

> 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
>Assignee: Benedikt Ritter
>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)


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

2017-06-07 Thread britter
Github user britter commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/269#discussion_r120549733
  
--- Diff: 
src/test/java/org/apache/commons/lang3/builder/ToStringBuilderTest.java ---
@@ -316,7 +317,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<>(arraylistInitialCapacity);
--- End diff --

Sorry to be nitpicking, but this should be a constant and wie should add a 
comment referencing JIRA-1337 with an explanation why we need to pass the 
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] [Commented] (LANG-1337) Fix test failures in IBM JDK 8 for ToStringBuilderTest

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on LANG-1337:
--

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

https://github.com/apache/commons-lang/pull/269#discussion_r120549733
  
--- Diff: 
src/test/java/org/apache/commons/lang3/builder/ToStringBuilderTest.java ---
@@ -316,7 +317,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<>(arraylistInitialCapacity);
--- End diff --

Sorry to be nitpicking, but this should be a constant and wie should add a 
comment referencing JIRA-1337 with an explanation why we need to pass the 
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: /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) 

[jira] [Commented] (VFS-438) Please promote vfs-smb currently in the sandbox

2017-06-07 Thread Christoph Obexer (JIRA)

[ 
https://issues.apache.org/jira/browse/VFS-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040346#comment-16040346
 ] 

Christoph Obexer commented on VFS-438:
--

According to http://www.apache.org/licenses/LICENSE-2.0#apply that is how you 
are supposed to use the Apache license?!

> Please promote vfs-smb currently in the sandbox
> ---
>
> Key: VFS-438
> URL: https://issues.apache.org/jira/browse/VFS-438
> Project: Commons VFS
>  Issue Type: New Feature
>Affects Versions: 2.0
> Environment: windows/unix
>Reporter: Dan Tran
>
> Current smb provider in the sandbox is mature enough to proceed with 
> promotion out of sandbox for general use. 
> Detail discussion is here 
> http://apache-commons.680414.n4.nabble.com/Promote-vfs-cift-out-of-sandbox-td4636519.html
> The sandbox also tests hookup to current test suite, all we need is to 
> provide a external URI using VFS test suite instructions.
> There are currently 2 classloader specific failures
> Tests in error:
>   testLoadClass(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests):
> code.ClassToLoad
>   testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests):
> code.sealed.AnotherClass
> Tests run: 1745, Failures: 0, Errors: 2, Skipped: 0
> require cifs  1.3.17 with one line change at 
> SmbFileObject.java line number 227 to 
> if (e.getNtStatus() == SmbException.NT_STATUS_NO_SUCH_FILE)



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


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

2017-06-07 Thread coveralls
Github user coveralls commented on the issue:

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

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

Coverage increased (+0.05%) to 95.221% when pulling 
**0344ca3f2d43e3732bf16370262303be8761a523 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] [Commented] (LANG-1337) Fix test failures in IBM JDK 8 for ToStringBuilderTest

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

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/11862419/badge)](https://coveralls.io/builds/11862419)

Coverage increased (+0.05%) to 95.221% when pulling 
**0344ca3f2d43e3732bf16370262303be8761a523 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 

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

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

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/11862419/badge)](https://coveralls.io/builds/11862419)

Coverage increased (+0.05%) to 95.221% when pulling 
**0344ca3f2d43e3732bf16370262303be8761a523 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...

2017-06-07 Thread coveralls
Github user coveralls commented on the issue:

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

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

Coverage increased (+0.05%) to 95.221% when pulling 
**0344ca3f2d43e3732bf16370262303be8761a523 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] [Commented] (LANG-1337) Fix test failures in IBM JDK 8 for ToStringBuilderTest

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on LANG-1337:
--

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

https://github.com/apache/commons-lang/pull/269#discussion_r120546260
  
--- 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 --

>If the test fails when the initial size arg is omitted, does that not also 
affect the behaviour of the method being tested?

Not really. The test simply checks the string built for an arraylist 
through reflection. The issue was caused for believing that the lazy 
initialization (as @andyklimczak) would work in the same independent of the JVM.

What the test is verifying is correct, the current approach could be 
improved to make the test less flaky.


> 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: 

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

2017-06-07 Thread kinow
Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/269#discussion_r120546260
  
--- 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 --

>If the test fails when the initial size arg is omitted, does that not also 
affect the behaviour of the method being tested?

Not really. The test simply checks the string built for an arraylist 
through reflection. The issue was caused for believing that the lazy 
initialization (as @andyklimczak) would work in the same independent of the JVM.

What the test is verifying is correct, the current approach could be 
improved to make the test less flaky.


---
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

2017-06-07 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on LANG-1337:
--

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

https://github.com/apache/commons-lang/pull/269#discussion_r120545692
  
--- 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 --

Fair enough on the magic number. I'd thought about that, then noticed a few 
other tests with numbers. But one broken window doesn't mean I can break 
another one :-) fixing in another commit.


> 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) 

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

2017-06-07 Thread kinow
Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/269#discussion_r120545692
  
--- 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 --

Fair enough on the magic number. I'd thought about that, then noticed a few 
other tests with numbers. But one broken window doesn't mean I can break 
another one :-) fixing in another commit.


---
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.
---