[GitHub] [commons-net] dependabot[bot] opened a new pull request #55: Bump commons-parent from 51 to 52

[GitBox]

dependabot[bot] opened a new pull request #55:
URL: https://github.com/apache/commons-net/pull/55


   Bumps commons-parent from 51 to 52.
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=org.apache.commons:commons-parent=maven=51=52)](https://help.github.com/articles/configuring-automated-security-fixes)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Work logged] (IO-670) IOUtils.contentEquals is of low performance. I will refine it.

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-670?focusedWorklogId=466022=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-466022
 ]

ASF GitHub Bot logged work on IO-670:
-

Author: ASF GitHub Bot
Created on: 04/Aug/20 04:11
Start Date: 04/Aug/20 04:11
Worklog Time Spent: 10m 
  Work Description: coveralls edited a comment on pull request #118:
URL: https://github.com/apache/commons-io/pull/118#issuecomment-636980413


   
   [![Coverage 
Status](https://coveralls.io/builds/32519545/badge)](https://coveralls.io/builds/32519545)
   
   Coverage increased (+0.4%) to 90.143% when pulling 
**93bbde3aea0a724bd9bf32d45d876bdb3fe76779 on XenoAmess:refine_contentEquals** 
into **0dbe95715197c3c9b8c983c0b9acbe87d5cee34d on apache:master**.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 466022)
Time Spent: 7h 50m  (was: 7h 40m)

> IOUtils.contentEquals is of low performance. I will refine it.
> --
>
> Key: IO-670
> URL: https://issues.apache.org/jira/browse/IO-670
> Project: Commons IO
>  Issue Type: Improvement
>Reporter: Jin Xu
>Priority: Critical
> Attachments: jmh-result.org.apache.json
>
>  Time Spent: 7h 50m
>  Remaining Estimate: 0h
>
> [https://github.com/apache/commons-io/pull/118]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-io] coveralls edited a comment on pull request #118: [IO-670] refine IOUtils.contentEquals(Reader, Reader)

[GitBox]

coveralls edited a comment on pull request #118:
URL: https://github.com/apache/commons-io/pull/118#issuecomment-636980413


   
   [![Coverage 
Status](https://coveralls.io/builds/32519545/badge)](https://coveralls.io/builds/32519545)
   
   Coverage increased (+0.4%) to 90.143% when pulling 
**93bbde3aea0a724bd9bf32d45d876bdb3fe76779 on XenoAmess:refine_contentEquals** 
into **0dbe95715197c3c9b8c983c0b9acbe87d5cee34d on apache:master**.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Work logged] (IO-670) IOUtils.contentEquals is of low performance. I will refine it.

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-670?focusedWorklogId=466013=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-466013
 ]

ASF GitHub Bot logged work on IO-670:
-

Author: ASF GitHub Bot
Created on: 04/Aug/20 03:29
Start Date: 04/Aug/20 03:29
Worklog Time Spent: 10m 
  Work Description: XenoAmess commented on pull request #118:
URL: https://github.com/apache/commons-io/pull/118#issuecomment-668359292


   @garydgregory 
   got it.
   new added class renamed as:
   
   org.apache.commons.io.input.buffer.UnsyncBufferedInputStream
   org.apache.commons.io.input.buffer.UnsyncBufferedReader
   org.apache.commons.io.input.buffer.LineEndUnifiedBufferedReader



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 466013)
Time Spent: 7h 40m  (was: 7.5h)

> IOUtils.contentEquals is of low performance. I will refine it.
> --
>
> Key: IO-670
> URL: https://issues.apache.org/jira/browse/IO-670
> Project: Commons IO
>  Issue Type: Improvement
>Reporter: Jin Xu
>Priority: Critical
> Attachments: jmh-result.org.apache.json
>
>  Time Spent: 7h 40m
>  Remaining Estimate: 0h
>
> [https://github.com/apache/commons-io/pull/118]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-io] XenoAmess commented on pull request #118: [IO-670] refine IOUtils.contentEquals(Reader, Reader)

[GitBox]

XenoAmess commented on pull request #118:
URL: https://github.com/apache/commons-io/pull/118#issuecomment-668359292


   @garydgregory 
   got it.
   new added class renamed as:
   
   org.apache.commons.io.input.buffer.UnsyncBufferedInputStream
   org.apache.commons.io.input.buffer.UnsyncBufferedReader
   org.apache.commons.io.input.buffer.LineEndUnifiedBufferedReader



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-vfs] garydgregory merged pull request #99: Add fail-fast : false for github actions maven.yml

[GitBox]

garydgregory merged pull request #99:
URL: https://github.com/apache/commons-vfs/pull/99


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Work logged] (IO-670) IOUtils.contentEquals is of low performance. I will refine it.

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-670?focusedWorklogId=465990=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-465990
 ]

ASF GitHub Bot logged work on IO-670:
-

Author: ASF GitHub Bot
Created on: 04/Aug/20 01:57
Start Date: 04/Aug/20 01:57
Worklog Time Spent: 10m 
  Work Description: garydgregory commented on pull request #118:
URL: https://github.com/apache/commons-io/pull/118#issuecomment-668333108


   On Mon, Aug 3, 2020 at 7:42 PM sebbASF  wrote:
   
   > The original comparison methods are easy to follow.
   > It would be good to keep the same clarity by defining new versions of
   > BufferedReader that have good single-threaded performance. Such classes
   > would also be useful elsewhere.
   > So for example
   > BufferedReader bufferedInput1 = toBufferedReader(input1);
   > would become something like:
   > FastBufferedReader bufferedInput1 = toFastBuffer(input1) (*)
   >
   > where toFastBuffer() works like buffer() but returns an instance of a
   > non-threadsafe FastBufferedReader.
   >
   > The FastBufferedxxx classes would also be useful in their own right
   > elsewhere in IO.
   > Obviously the documentation would need to make it clear that they are not
   > thread-safe.
   > I suspect they don't need to implement mark (which would make them
   > simpler).
   >
   > (*) FastBuffer is just a suggestion for the name. Maybe QandDBuffer would
   > be better (Quick and Dirty)!
   >
   
   I would really like to stay away from names like "Fast". Faster than what?
   What if we come up with something better but incompatible, would that be a
   "FasterThanFast" or "Fastest" ;-)
   
   We've run into this kind naming issue before and we decide to go with a
   prefix that describes the actual functionality which is "unsynchronized",
   see
   - org.apache.commons.io.input.UnsynchronizedByteArrayInputStream
   - org.apache.commons.io.output.UnsynchronizedByteArrayOutputStream
   
   Note that there is precedent for this kind of name in the JRE's copy of
   Apache's XML code:
   
   - com.sun.org.apache.xml.internal.security.utils.UnsyncBufferedOutputStream
   - com.sun.org.apache.xml.internal.security.utils.UnsyncByteArrayOutputStream
   
   Gary
   
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   >
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 465990)
Time Spent: 7.5h  (was: 7h 20m)

> IOUtils.contentEquals is of low performance. I will refine it.
> --
>
> Key: IO-670
> URL: https://issues.apache.org/jira/browse/IO-670
> Project: Commons IO
>  Issue Type: Improvement
>Reporter: Jin Xu
>Priority: Critical
> Attachments: jmh-result.org.apache.json
>
>  Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> [https://github.com/apache/commons-io/pull/118]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-io] garydgregory commented on pull request #118: [IO-670] refine IOUtils.contentEquals(Reader, Reader)

[GitBox]

garydgregory commented on pull request #118:
URL: https://github.com/apache/commons-io/pull/118#issuecomment-668333108


   On Mon, Aug 3, 2020 at 7:42 PM sebbASF  wrote:
   
   > The original comparison methods are easy to follow.
   > It would be good to keep the same clarity by defining new versions of
   > BufferedReader that have good single-threaded performance. Such classes
   > would also be useful elsewhere.
   > So for example
   > BufferedReader bufferedInput1 = toBufferedReader(input1);
   > would become something like:
   > FastBufferedReader bufferedInput1 = toFastBuffer(input1) (*)
   >
   > where toFastBuffer() works like buffer() but returns an instance of a
   > non-threadsafe FastBufferedReader.
   >
   > The FastBufferedxxx classes would also be useful in their own right
   > elsewhere in IO.
   > Obviously the documentation would need to make it clear that they are not
   > thread-safe.
   > I suspect they don't need to implement mark (which would make them
   > simpler).
   >
   > (*) FastBuffer is just a suggestion for the name. Maybe QandDBuffer would
   > be better (Quick and Dirty)!
   >
   
   I would really like to stay away from names like "Fast". Faster than what?
   What if we come up with something better but incompatible, would that be a
   "FasterThanFast" or "Fastest" ;-)
   
   We've run into this kind naming issue before and we decide to go with a
   prefix that describes the actual functionality which is "unsynchronized",
   see
   - org.apache.commons.io.input.UnsynchronizedByteArrayInputStream
   - org.apache.commons.io.output.UnsynchronizedByteArrayOutputStream
   
   Note that there is precedent for this kind of name in the JRE's copy of
   Apache's XML code:
   
   - com.sun.org.apache.xml.internal.security.utils.UnsyncBufferedOutputStream
   - com.sun.org.apache.xml.internal.security.utils.UnsyncByteArrayOutputStream
   
   Gary
   
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   >
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-io] sebbASF commented on pull request #118: [IO-670] refine IOUtils.contentEquals(Reader, Reader)

[GitBox]

sebbASF commented on pull request #118:
URL: https://github.com/apache/commons-io/pull/118#issuecomment-668293267


   The original comparison methods are easy to follow.
   It would be good to keep the same clarity by defining new versions of 
BufferedReader that have good single-threaded performance. Such classes would 
also be useful elsewhere.
   So for example
   BufferedReader bufferedInput1 = toBufferedReader(input1);
   would become something like:
   FastBufferedReader bufferedInput1 = toFastBuffer(input1) (*)
   
   where toFastBuffer() works like buffer() but returns an instance of a 
non-threadsafe FastBufferedReader.
   
   The FastBufferedxxx classes would also be useful in their own right 
elsewhere in IO.
   Obviously the documentation would need to make it clear that they are not 
thread-safe.
   I suspect they don't need to implement mark (which would make them simpler).
   
   (*) FastBuffer is just a suggestion for the name. Maybe QandDBuffer would be 
better (Quick and Dirty)!



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Work logged] (IO-670) IOUtils.contentEquals is of low performance. I will refine it.

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/IO-670?focusedWorklogId=465956=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-465956
 ]

ASF GitHub Bot logged work on IO-670:
-

Author: ASF GitHub Bot
Created on: 03/Aug/20 23:42
Start Date: 03/Aug/20 23:42
Worklog Time Spent: 10m 
  Work Description: sebbASF commented on pull request #118:
URL: https://github.com/apache/commons-io/pull/118#issuecomment-668293267


   The original comparison methods are easy to follow.
   It would be good to keep the same clarity by defining new versions of 
BufferedReader that have good single-threaded performance. Such classes would 
also be useful elsewhere.
   So for example
   BufferedReader bufferedInput1 = toBufferedReader(input1);
   would become something like:
   FastBufferedReader bufferedInput1 = toFastBuffer(input1) (*)
   
   where toFastBuffer() works like buffer() but returns an instance of a 
non-threadsafe FastBufferedReader.
   
   The FastBufferedxxx classes would also be useful in their own right 
elsewhere in IO.
   Obviously the documentation would need to make it clear that they are not 
thread-safe.
   I suspect they don't need to implement mark (which would make them simpler).
   
   (*) FastBuffer is just a suggestion for the name. Maybe QandDBuffer would be 
better (Quick and Dirty)!



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 465956)
Time Spent: 7h 20m  (was: 7h 10m)

> IOUtils.contentEquals is of low performance. I will refine it.
> --
>
> Key: IO-670
> URL: https://issues.apache.org/jira/browse/IO-670
> Project: Commons IO
>  Issue Type: Improvement
>Reporter: Jin Xu
>Priority: Critical
> Attachments: jmh-result.org.apache.json
>
>  Time Spent: 7h 20m
>  Remaining Estimate: 0h
>
> [https://github.com/apache/commons-io/pull/118]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-validator] sebbASF opened a new pull request #36: Bring up to date

[GitBox]

sebbASF opened a new pull request #36:
URL: https://github.com/apache/commons-validator/pull/36


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-validator] sebbASF merged pull request #36: Bring up to date

[GitBox]

sebbASF merged pull request #36:
URL: https://github.com/apache/commons-validator/pull/36


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] garydgregory merged pull request #597: Bump junit-pioneer from 0.7.0 to 0.8.0

[GitBox]

garydgregory merged pull request #597:
URL: https://github.com/apache/commons-lang/pull/597


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-io] garydgregory merged pull request #135: Bump junit-pioneer from 0.7.0 to 0.8.0

[GitBox]

garydgregory merged pull request #135:
URL: https://github.com/apache/commons-io/pull/135


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-vfs] garydgregory merged pull request #108: Add proxy config for some Http/Https test

[GitBox]

garydgregory merged pull request #108:
URL: https://github.com/apache/commons-vfs/pull/108


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (LANG-1593) Common behaviour for StringUtils join APIs when called with char or String delimiter

[Kiruahxh (Jira)]

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

Kiruahxh updated LANG-1593:
---
Description: 
For now, join(int[], char) is working well.
 However, the same join method called with a string delimiter behaves 
differently : it returns a single memory address which is not the desired 
behavior.
 I think that, for coherence, calling StringUtils with a char or String 
delimiter should return the exact same value.

Ex :
{code:java}
CLASSPATH="./commons-lang3-3.11.jar" jshell 
|  Welcome to JShell -- Version 11.0.8
jshell> import org.apache.commons.lang3.StringUtils
jshell> int[] arr = {1, 2, 3, 4, 5, 6, 7};
jshell> String result = StringUtils.join(arr, '-');
result ==> "1-2-3-4-5-6-7"
jshell> String result = StringUtils.join(arr, "-");
result ==> "[I@69663380-"
{code}
 

  was:
For now, join(int[], char) is working well.
 However, the same join method called with a string delimiter behaves 
differently : it returns  a single memory addresses which is not the desired 
behavior.
 I think that, for coherence, calling StringUtils with a char or String 
delimiter should return the exact same value.

Ex :
{code:java}
CLASSPATH="./commons-lang3-3.11.jar" jshell 
|  Welcome to JShell -- Version 11.0.8
jshell> import org.apache.commons.lang3.StringUtils
jshell> int[] arr = {1, 2, 3, 4, 5, 6, 7};
jshell> String result = StringUtils.join(arr, '-');
result ==> "1-2-3-4-5-6-7"
jshell> String result = StringUtils.join(arr, "-");
result ==> "[I@69663380-"
{code}
 


> Common behaviour for StringUtils join APIs when called with char or String 
> delimiter
> 
>
> Key: LANG-1593
> URL: https://issues.apache.org/jira/browse/LANG-1593
> Project: Commons Lang
>  Issue Type: Improvement
>Affects Versions: 3.4, 3.11
>Reporter: Kiruahxh
>Priority: Minor
>
> For now, join(int[], char) is working well.
>  However, the same join method called with a string delimiter behaves 
> differently : it returns a single memory address which is not the desired 
> behavior.
>  I think that, for coherence, calling StringUtils with a char or String 
> delimiter should return the exact same value.
> Ex :
> {code:java}
> CLASSPATH="./commons-lang3-3.11.jar" jshell 
> |  Welcome to JShell -- Version 11.0.8
> jshell> import org.apache.commons.lang3.StringUtils
> jshell> int[] arr = {1, 2, 3, 4, 5, 6, 7};
> jshell> String result = StringUtils.join(arr, '-');
> result ==> "1-2-3-4-5-6-7"
> jshell> String result = StringUtils.join(arr, "-");
> result ==> "[I@69663380-"
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (NET-686) Most files aren't downloaded completely from an FTP server

[Bernd Eckenfels (Jira)]

[ 
https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169901#comment-17169901
 ] 

Bernd Eckenfels commented on NET-686:
-

Can you provide a binary difference what exactly is wrong or provide a Testfile 
and it's corrupt result? Is the same test file always broken when you request 
it multiple times?

 Btw you don't need the buffered input stream if you read with larger buffer.

I would move the setFileType before the retrieve (after the list files).

> Most files aren't downloaded completely from an FTP server
> --
>
> Key: NET-686
> URL: https://issues.apache.org/jira/browse/NET-686
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.6
> Environment: Win 10
> Java 8
> Android Studio 3.6.1 (min SDK 24, target SDK 27)
>Reporter: JRRR
>Priority: Major
> Attachments: DownloadProblem.java
>
>
> About a month ago I opened another 
> [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because 
> it wasn't reproducible with macOS and a public FTP server.
> Short summary: Downloading files from an FTP server results in these files 
> randomly missing bytes. It looks like the download always "completes" and 
> there are no error messages/exceptions but random bytes in random files are 
> simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe 
> 40, bytes smaller than the original), and are then also visibly corrupt, than 
> text files (usually only 2-3 bytes smaller, rarely more).
> I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK 
> 24, target SDK 27), which I'm testing with FTP servers in the same network 
> (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what 
> method in the library I use (retrieveFile, retrieveFileStream, 
> sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
> single file that's corrupted.
> I also tested the same code with public servers and even though I didn't have 
> a lot of time because those servers regularely delete uploaded files, I never 
> experienced said problem with them.
> I even wrote my own mini-library (just for login/logout and download) using 
> Java's default "Socket" but I still had the same problem on Android Studio's 
> simulator/a real device. BUT: When I used the same code to create a small 
> Windows/Swing/Java app, there were no more corrupted files.
> It looks like this bug is only affecting a very specific combination of 
> OS,...:
> Android (emulator/real device) + Java (8) + FTP server in the same network 
> (accessed via IP)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (LANG-1593) Common behaviour for StringUtils join APIs when called with char or String delimiter

[Gilles Sadowski (Jira)]

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

Gilles Sadowski commented on LANG-1593:
---

Currently failing unit test added in commit 
4897c8869b7050ba98b19c743762c10a56581ee4.

> Common behaviour for StringUtils join APIs when called with char or String 
> delimiter
> 
>
> Key: LANG-1593
> URL: https://issues.apache.org/jira/browse/LANG-1593
> Project: Commons Lang
>  Issue Type: Improvement
>Affects Versions: 3.4, 3.11
>Reporter: Kiruahxh
>Priority: Minor
>
> For now, join(int[], char) is working well.
>  However, the same join method called with a string delimiter behaves 
> differently : it returns  a single memory addresses which is not the desired 
> behavior.
>  I think that, for coherence, calling StringUtils with a char or String 
> delimiter should return the exact same value.
> Ex :
> {code:java}
> CLASSPATH="./commons-lang3-3.11.jar" jshell 
> |  Welcome to JShell -- Version 11.0.8
> jshell> import org.apache.commons.lang3.StringUtils
> jshell> int[] arr = {1, 2, 3, 4, 5, 6, 7};
> jshell> String result = StringUtils.join(arr, '-');
> result ==> "1-2-3-4-5-6-7"
> jshell> String result = StringUtils.join(arr, "-");
> result ==> "[I@69663380-"
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (LANG-1593) Common behaviour for StringUtils join APIs when called with char or String delimiter

[Gilles Sadowski (Jira)]

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

Gilles Sadowski commented on LANG-1593:
---

A bug indeed, IMO.

The test method delegates to
{code:java}
public static  String join(final T... elements)
{code}
that ultimately calls
{code:java}
public static String join(final Object[] array, final String separator)
{code}
with arguments
 * {{array == [ [I@21da4b5f, - ]}}
 * {{separator == null}}

I guess that the fix would be to define an overloaded method for each type of 
primitive array, a.o. (in this use-case):
{code:java}
public static String join(final int[] array, final String separator)
{code}
(as was done for methods where the {{separator}} is of type {{char)}}.

> Common behaviour for StringUtils join APIs when called with char or String 
> delimiter
> 
>
> Key: LANG-1593
> URL: https://issues.apache.org/jira/browse/LANG-1593
> Project: Commons Lang
>  Issue Type: Improvement
>Affects Versions: 3.4, 3.11
>Reporter: Kiruahxh
>Priority: Minor
>
> For now, join(int[], char) is working well.
>  However, the same join method called with a string delimiter behaves 
> differently : it returns  a single memory addresses which is not the desired 
> behavior.
>  I think that, for coherence, calling StringUtils with a char or String 
> delimiter should return the exact same value.
> Ex :
> {code:java}
> CLASSPATH="./commons-lang3-3.11.jar" jshell 
> |  Welcome to JShell -- Version 11.0.8
> jshell> import org.apache.commons.lang3.StringUtils
> jshell> int[] arr = {1, 2, 3, 4, 5, 6, 7};
> jshell> String result = StringUtils.join(arr, '-');
> result ==> "1-2-3-4-5-6-7"
> jshell> String result = StringUtils.join(arr, "-");
> result ==> "[I@69663380-"
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (NET-686) Most files aren't downloaded completely from an FTP server

[JRRR (Jira)]

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

JRRR updated NET-686:
-
Description: 
About a month ago I opened another 
[issue|https://issues.apache.org/jira/browse/NET-684] that was closed because 
it wasn't reproducible with macOS and a public FTP server.

Short summary: Downloading files from an FTP server results in these files 
randomly missing bytes. It looks like the download always "completes" and there 
are no error messages/exceptions but random bytes in random files are simply 
skipped. Images (jpg & png) are usually affected more (up to 30, maybe 40, 
bytes smaller than the original), and are then also visibly corrupt, than text 
files (usually only 2-3 bytes smaller, rarely more).

I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK 
24, target SDK 27), which I'm testing with FTP servers in the same network (1x 
Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what method 
in the library I use (retrieveFile, retrieveFileStream, 
sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
single file that's corrupted.

I also tested the same code with public servers and even though I didn't have a 
lot of time because those servers regularely delete uploaded files, I never 
experienced said problem with them.

I even wrote my own mini-library (just for login/logout and download) using 
Java's default "Socket" but I still had the same problem on Android Studio's 
simulator/a real device. BUT: When I used the same code to create a small 
Windows/Swing/Java app, there were no more corrupted files.

It looks like this bug is only affecting a very specific combination of OS,...:

Android (emulator/real device) + Java (8) + FTP server in the same network 
(accessed via IP)

  was:
About a month ago I opened another 
[[issue||http://example.com/]https://issues.apache.org/jira/browse/NET-684 
[]|http://example.com/] that was closed because it wasn't reproducible with 
macOS and a public FTP server.

Short summary: Downloading files from an FTP server results in these files 
randomly missing bytes. It looks like the download always "completes" and there 
are no error messages/exceptions but random bytes in random files are simply 
skipped. Images (jpg & png) are usually affected more (up to 30, maybe 40, 
bytes smaller than the original), and are then also visibly corrupt, than text 
files (usually only 2-3 bytes smaller, rarely more).

I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK 
24, target SDK 27), which I'm testing with FTP servers in the same network (1x 
Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what method 
in the library I use (retrieveFile, retrieveFileStream, 
sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
single file that's corrupted.

I also tested the same code with public servers and even though I didn't have a 
lot of time because those servers regularely delete uploaded files, I never 
experienced said problem with them.

I even wrote my own mini-library (just for login/logout and download) using 
Java's default "Socket" but I still had the same problem on Android Studio's 
simulator/a real device. BUT: When I used the same code to create a small 
Windows/Swing/Java app, there were no more corrupted files.

It looks like this bug is only affecting a very specific combination of OS,...:

Android (emulator/real device) + Java (8) + FTP server in the same network 
(accessed via IP)


> Most files aren't downloaded completely from an FTP server
> --
>
> Key: NET-686
> URL: https://issues.apache.org/jira/browse/NET-686
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.6
> Environment: Win 10
> Java 8
> Android Studio 3.6.1 (min SDK 24, target SDK 27)
>Reporter: JRRR
>Priority: Major
> Attachments: DownloadProblem.java
>
>
> About a month ago I opened another 
> [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because 
> it wasn't reproducible with macOS and a public FTP server.
> Short summary: Downloading files from an FTP server results in these files 
> randomly missing bytes. It looks like the download always "completes" and 
> there are no error messages/exceptions but random bytes in random files are 
> simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe 
> 40, bytes smaller than the original), and are then also visibly corrupt, than 
> text files (usually only 2-3 bytes smaller, rarely more).
> I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK 
> 24, target SDK 27), which I'm testing with FTP servers in the same network 
> (1x Win 10, 1x Linux, both accessed via IP - 

[jira] [Updated] (NET-686) Most files aren't downloaded completely from an FTP server

[JRRR (Jira)]

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

JRRR updated NET-686:
-
Description: 
About a month ago I opened another 
[[issue||http://example.com/]https://issues.apache.org/jira/browse/NET-684 
[]|http://example.com/] that was closed because it wasn't reproducible with 
macOS and a public FTP server.

Short summary: Downloading files from an FTP server results in these files 
randomly missing bytes. It looks like the download always "completes" and there 
are no error messages/exceptions but random bytes in random files are simply 
skipped. Images (jpg & png) are usually affected more (up to 30, maybe 40, 
bytes smaller than the original), and are then also visibly corrupt, than text 
files (usually only 2-3 bytes smaller, rarely more).

I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK 
24, target SDK 27), which I'm testing with FTP servers in the same network (1x 
Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what method 
in the library I use (retrieveFile, retrieveFileStream, 
sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
single file that's corrupted.

I also tested the same code with public servers and even though I didn't have a 
lot of time because those servers regularely delete uploaded files, I never 
experienced said problem with them.

I even wrote my own mini-library (just for login/logout and download) using 
Java's default "Socket" but I still had the same problem on Android Studio's 
simulator/a real device. BUT: When I used the same code to create a small 
Windows/Swing/Java app, there were no more corrupted files.

It looks like this bug is only affecting a very specific combination of OS,...:

Android (emulator/real device) + Java (8) + FTP server in the same network 
(accessed via IP)

  was:
About a month ago I opened another [issue|http://example.com] that was closed 
because it wasn't reproducible with macOS and a public FTP server.

Short summary: Downloading files from an FTP server results in these files 
randomly missing bytes. It looks like the download always "completes" and there 
are no error messages/exceptions but random bytes in random files are simply 
skipped. Images (jpg & png) are usually affected more (up to 30, maybe 40, 
bytes smaller than the original), and are then also visibly corrupt, than text 
files (usually only 2-3 bytes smaller, rarely more).

I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK 
24, target SDK 27), which I'm testing with FTP servers in the same network (1x 
Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what method 
in the library I use (retrieveFile, retrieveFileStream, 
sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
single file that's corrupted.

I also tested the same code with public servers and even though I didn't have a 
lot of time because those servers regularely delete uploaded files, I never 
experienced said problem with them.

I even wrote my own mini-library (just for login/logout and download) using 
Java's default "Socket" but I still had the same problem on Android Studio's 
simulator/a real device. BUT: When I used the same code to create a small 
Windows/Swing/Java app, there were no more corrupted files.

It looks like this bug is only affecting a very specific combination of OS,...:

Android (emulator/real device) + Java (8) + FTP server in the same network 
(accessed via IP)


> Most files aren't downloaded completely from an FTP server
> --
>
> Key: NET-686
> URL: https://issues.apache.org/jira/browse/NET-686
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.6
> Environment: Win 10
> Java 8
> Android Studio 3.6.1 (min SDK 24, target SDK 27)
>Reporter: JRRR
>Priority: Major
> Attachments: DownloadProblem.java
>
>
> About a month ago I opened another 
> [[issue||http://example.com/]https://issues.apache.org/jira/browse/NET-684 
> []|http://example.com/] that was closed because it wasn't reproducible with 
> macOS and a public FTP server.
> Short summary: Downloading files from an FTP server results in these files 
> randomly missing bytes. It looks like the download always "completes" and 
> there are no error messages/exceptions but random bytes in random files are 
> simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe 
> 40, bytes smaller than the original), and are then also visibly corrupt, than 
> text files (usually only 2-3 bytes smaller, rarely more).
> I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK 
> 24, target SDK 27), which I'm testing with FTP servers in the same network 
> (1x Win 10, 1x Linux, both accessed 

[jira] [Updated] (NET-686) Most files aren't downloaded completely from an FTP server

[JRRR (Jira)]

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

JRRR updated NET-686:
-
Description: 
About a month ago I opened another [issue|http://example.com] that was closed 
because it wasn't reproducible with macOS and a public FTP server.

Short summary: Downloading files from an FTP server results in these files 
randomly missing bytes. It looks like the download always "completes" and there 
are no error messages/exceptions but random bytes in random files are simply 
skipped. Images (jpg & png) are usually affected more (up to 30, maybe 40, 
bytes smaller than the original), and are then also visibly corrupt, than text 
files (usually only 2-3 bytes smaller, rarely more).

I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK 
24, target SDK 27), which I'm testing with FTP servers in the same network (1x 
Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what method 
in the library I use (retrieveFile, retrieveFileStream, 
sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
single file that's corrupted.

I also tested the same code with public servers and even though I didn't have a 
lot of time because those servers regularely delete uploaded files, I never 
experienced said problem with them.

I even wrote my own mini-library (just for login/logout and download) using 
Java's default "Socket" but I still had the same problem on Android Studio's 
simulator/a real device. BUT: When I used the same code to create a small 
Windows/Swing/Java app, there were no more corrupted files.

It looks like this bug is only affecting a very specific combination of OS,...:

Android (emulator/real device) + Java (8) + FTP server in the same network 
(accessed via IP)

  was:
About a month ago I opened another issue that was closed because it wasn't 
reproducible with macOS and a public FTP server.

Short summary: Downloading files from an FTP server results in these files 
randomly missing bytes. It looks like the download always "completes" and there 
are no error messages/exceptions but random bytes in random files are simply 
skipped. Images (jpg & png) are usually affected more (up to 30, maybe 40, 
bytes smaller than the original), and are then also visibly corrupt, than text 
files (usually only 2-3 bytes smaller, rarely more).

I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK 
24, target SDK 27), which I'm testing with FTP servers in the same network (1x 
Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what method 
in the library I use (retrieveFile, retrieveFileStream, 
sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
single file that's corrupted.

I also tested the same code with public servers and even though I didn't have a 
lot of time because those servers regularely delete uploaded files, I never 
experienced said problem with them.

I even wrote my own mini-library (just for login/logout and download) using 
Java's default "Socket" but I still had the same problem on Android Studio's 
simulator/a real device. BUT: When I used the same code to create a small 
Windows/Swing/Java app, there were no more corrupted files.

It looks like this bug is only affecting a very specific combination of OS,...:

Android (emulator/real device) + Java (8) + FTP server in the same network 
(accessed via IP)


> Most files aren't downloaded completely from an FTP server
> --
>
> Key: NET-686
> URL: https://issues.apache.org/jira/browse/NET-686
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.6
> Environment: Win 10
> Java 8
> Android Studio 3.6.1 (min SDK 24, target SDK 27)
>Reporter: JRRR
>Priority: Major
> Attachments: DownloadProblem.java
>
>
> About a month ago I opened another [issue|http://example.com] that was closed 
> because it wasn't reproducible with macOS and a public FTP server.
> Short summary: Downloading files from an FTP server results in these files 
> randomly missing bytes. It looks like the download always "completes" and 
> there are no error messages/exceptions but random bytes in random files are 
> simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe 
> 40, bytes smaller than the original), and are then also visibly corrupt, than 
> text files (usually only 2-3 bytes smaller, rarely more).
> I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK 
> 24, target SDK 27), which I'm testing with FTP servers in the same network 
> (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what 
> method in the library I use (retrieveFile, retrieveFileStream, 
> sendCommand(FTPCmd.RETRIEVE, filename)), most of the time 

[jira] [Updated] (NET-686) Most files aren't downloaded completely from an FTP server

[JRRR (Jira)]

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

JRRR updated NET-686:
-
Description: 
About a month ago I opened another issue that was closed because it wasn't 
reproducible with macOS and a public FTP server.

Short summary: Downloading files from an FTP server results in these files 
randomly missing bytes. It looks like the download always "completes" and there 
are no error messages/exceptions but random bytes in random files are simply 
skipped. Images (jpg & png) are usually affected more (up to 30, maybe 40, 
bytes smaller than the original), and are then also visibly corrupt, than text 
files (usually only 2-3 bytes smaller, rarely more).

I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK 
24, target SDK 27), which I'm testing with FTP servers in the same network (1x 
Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what method 
in the library I use (retrieveFile, retrieveFileStream, 
sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
single file that's corrupted.

I also tested the same code with public servers and even though I didn't have a 
lot of time because those servers regularely delete uploaded files, I never 
experienced said problem with them.

I even wrote my own mini-library (just for login/logout and download) using 
Java's default "Socket" but I still had the same problem on Android Studio's 
simulator/a real device. BUT: When I used the same code to create a small 
Windows/Swing/Java app, there were no more corrupted files.

It looks like this bug is only affecting a very specific combination of OS,...:

Android (emulator/real device) + Java (8) + FTP server in the same network 
(accessed via IP)

  was:
About a month ago I opened another 
[issue|https://issues.apache.org/jira/browse/NET-684] that was closed because 
it wasn't reproducible with macOS and a public FTP server.

Short summary: Downloading files from an FTP server results in these files 
randomly missing bytes. It looks like the download always "completes" and there 
are no error messages/exceptions but random bytes in random files are simply 
skipped. Images (jpg & png) are usually affected more (up to 30, maybe 40, 
bytes smaller than the original), and are then also visibly corrupt, than text 
files (usually only 2-3 bytes smaller, rarely more).

I'm working on an Android app (Win 10, Java 8, Androis Studio 3.6.1, min SDK 
24, target SDK 27), which I'm testing with FTP servers in the same network (1x 
Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what method 
in the library I use (retrieveFile, retrieveFileStream, 
sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
single file that's corrupted.

I also tested the same code with public servers and even though I didn't have a 
lot of time because those servers regularely delete uploaded files, I never 
experienced said problem with them.

I even wrote my own mini-library (just for login/logout and download) using 
Java's default "Socket" but I still had the same problem on Android Studio's 
simulator/a real device. BUT: When I used the same code to create a small 
Windows/Swing/Java app, there were no more corrupted files.

It looks like this bug is only affecting a very specific combination of OS,...:

Android (emulator/real device) + Java (8) + FTP server in the same network 
(accessed via IP)


> Most files aren't downloaded completely from an FTP server
> --
>
> Key: NET-686
> URL: https://issues.apache.org/jira/browse/NET-686
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.6
> Environment: Win 10
> Java 8
> Android Studio 3.6.1 (min SDK 24, target SDK 27)
>Reporter: JRRR
>Priority: Major
> Attachments: DownloadProblem.java
>
>
> About a month ago I opened another issue that was closed because it wasn't 
> reproducible with macOS and a public FTP server.
> Short summary: Downloading files from an FTP server results in these files 
> randomly missing bytes. It looks like the download always "completes" and 
> there are no error messages/exceptions but random bytes in random files are 
> simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe 
> 40, bytes smaller than the original), and are then also visibly corrupt, than 
> text files (usually only 2-3 bytes smaller, rarely more).
> I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK 
> 24, target SDK 27), which I'm testing with FTP servers in the same network 
> (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what 
> method in the library I use (retrieveFile, retrieveFileStream, 
> sendCommand(FTPCmd.RETRIEVE, filename)), most of the time 

[jira] [Comment Edited] (NET-686) Most files aren't downloaded completely from an FTP server

[JRRR (Jira)]

[ 
https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169852#comment-17169852
 ] 

JRRR edited comment on NET-686 at 8/3/20, 9:40 AM:
---

[~sebb] Sorry, I already changed that in my code but forgot to change it in the 
file too. I re-uploaded the file.


was (Author: jrrr):
[~sebb] Sorry, I already changed that in my code but forgot to change it in the 
file too.

> Most files aren't downloaded completely from an FTP server
> --
>
> Key: NET-686
> URL: https://issues.apache.org/jira/browse/NET-686
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.6
> Environment: Win 10
> Java 8
> Android Studio 3.6.1 (min SDK 24, target SDK 27)
>Reporter: JRRR
>Priority: Major
> Attachments: DownloadProblem.java
>
>
> About a month ago I opened another 
> [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because 
> it wasn't reproducible with macOS and a public FTP server.
> Short summary: Downloading files from an FTP server results in these files 
> randomly missing bytes. It looks like the download always "completes" and 
> there are no error messages/exceptions but random bytes in random files are 
> simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe 
> 40, bytes smaller than the original), and are then also visibly corrupt, than 
> text files (usually only 2-3 bytes smaller, rarely more).
> I'm working on an Android app (Win 10, Java 8, Androis Studio 3.6.1, min SDK 
> 24, target SDK 27), which I'm testing with FTP servers in the same network 
> (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what 
> method in the library I use (retrieveFile, retrieveFileStream, 
> sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
> single file that's corrupted.
> I also tested the same code with public servers and even though I didn't have 
> a lot of time because those servers regularely delete uploaded files, I never 
> experienced said problem with them.
> I even wrote my own mini-library (just for login/logout and download) using 
> Java's default "Socket" but I still had the same problem on Android Studio's 
> simulator/a real device. BUT: When I used the same code to create a small 
> Windows/Swing/Java app, there were no more corrupted files.
> It looks like this bug is only affecting a very specific combination of 
> OS,...:
> Android (emulator/real device) + Java (8) + FTP server in the same network 
> (accessed via IP)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Reopened] (NET-686) Most files aren't downloaded completely from an FTP server

[JRRR (Jira)]

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

JRRR reopened NET-686:
--

Sorry, I fixed the code and re-uploaded the file.

The bug is still a problem.

> Most files aren't downloaded completely from an FTP server
> --
>
> Key: NET-686
> URL: https://issues.apache.org/jira/browse/NET-686
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.6
> Environment: Win 10
> Java 8
> Android Studio 3.6.1 (min SDK 24, target SDK 27)
>Reporter: JRRR
>Priority: Major
> Attachments: DownloadProblem.java
>
>
> About a month ago I opened another 
> [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because 
> it wasn't reproducible with macOS and a public FTP server.
> Short summary: Downloading files from an FTP server results in these files 
> randomly missing bytes. It looks like the download always "completes" and 
> there are no error messages/exceptions but random bytes in random files are 
> simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe 
> 40, bytes smaller than the original), and are then also visibly corrupt, than 
> text files (usually only 2-3 bytes smaller, rarely more).
> I'm working on an Android app (Win 10, Java 8, Androis Studio 3.6.1, min SDK 
> 24, target SDK 27), which I'm testing with FTP servers in the same network 
> (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what 
> method in the library I use (retrieveFile, retrieveFileStream, 
> sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
> single file that's corrupted.
> I also tested the same code with public servers and even though I didn't have 
> a lot of time because those servers regularely delete uploaded files, I never 
> experienced said problem with them.
> I even wrote my own mini-library (just for login/logout and download) using 
> Java's default "Socket" but I still had the same problem on Android Studio's 
> simulator/a real device. BUT: When I used the same code to create a small 
> Windows/Swing/Java app, there were no more corrupted files.
> It looks like this bug is only affecting a very specific combination of 
> OS,...:
> Android (emulator/real device) + Java (8) + FTP server in the same network 
> (accessed via IP)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (NET-686) Most files aren't downloaded completely from an FTP server

[JRRR (Jira)]

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

JRRR updated NET-686:
-
Attachment: DownloadProblem.java

> Most files aren't downloaded completely from an FTP server
> --
>
> Key: NET-686
> URL: https://issues.apache.org/jira/browse/NET-686
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.6
> Environment: Win 10
> Java 8
> Android Studio 3.6.1 (min SDK 24, target SDK 27)
>Reporter: JRRR
>Priority: Major
> Attachments: DownloadProblem.java
>
>
> About a month ago I opened another 
> [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because 
> it wasn't reproducible with macOS and a public FTP server.
> Short summary: Downloading files from an FTP server results in these files 
> randomly missing bytes. It looks like the download always "completes" and 
> there are no error messages/exceptions but random bytes in random files are 
> simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe 
> 40, bytes smaller than the original), and are then also visibly corrupt, than 
> text files (usually only 2-3 bytes smaller, rarely more).
> I'm working on an Android app (Win 10, Java 8, Androis Studio 3.6.1, min SDK 
> 24, target SDK 27), which I'm testing with FTP servers in the same network 
> (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what 
> method in the library I use (retrieveFile, retrieveFileStream, 
> sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
> single file that's corrupted.
> I also tested the same code with public servers and even though I didn't have 
> a lot of time because those servers regularely delete uploaded files, I never 
> experienced said problem with them.
> I even wrote my own mini-library (just for login/logout and download) using 
> Java's default "Socket" but I still had the same problem on Android Studio's 
> simulator/a real device. BUT: When I used the same code to create a small 
> Windows/Swing/Java app, there were no more corrupted files.
> It looks like this bug is only affecting a very specific combination of 
> OS,...:
> Android (emulator/real device) + Java (8) + FTP server in the same network 
> (accessed via IP)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (NET-686) Most files aren't downloaded completely from an FTP server

[JRRR (Jira)]

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

JRRR updated NET-686:
-
Attachment: (was: DownloadProblem.java)

> Most files aren't downloaded completely from an FTP server
> --
>
> Key: NET-686
> URL: https://issues.apache.org/jira/browse/NET-686
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.6
> Environment: Win 10
> Java 8
> Android Studio 3.6.1 (min SDK 24, target SDK 27)
>Reporter: JRRR
>Priority: Major
> Attachments: DownloadProblem.java
>
>
> About a month ago I opened another 
> [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because 
> it wasn't reproducible with macOS and a public FTP server.
> Short summary: Downloading files from an FTP server results in these files 
> randomly missing bytes. It looks like the download always "completes" and 
> there are no error messages/exceptions but random bytes in random files are 
> simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe 
> 40, bytes smaller than the original), and are then also visibly corrupt, than 
> text files (usually only 2-3 bytes smaller, rarely more).
> I'm working on an Android app (Win 10, Java 8, Androis Studio 3.6.1, min SDK 
> 24, target SDK 27), which I'm testing with FTP servers in the same network 
> (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what 
> method in the library I use (retrieveFile, retrieveFileStream, 
> sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
> single file that's corrupted.
> I also tested the same code with public servers and even though I didn't have 
> a lot of time because those servers regularely delete uploaded files, I never 
> experienced said problem with them.
> I even wrote my own mini-library (just for login/logout and download) using 
> Java's default "Socket" but I still had the same problem on Android Studio's 
> simulator/a real device. BUT: When I used the same code to create a small 
> Windows/Swing/Java app, there were no more corrupted files.
> It looks like this bug is only affecting a very specific combination of 
> OS,...:
> Android (emulator/real device) + Java (8) + FTP server in the same network 
> (accessed via IP)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (NET-686) Most files aren't downloaded completely from an FTP server

[JRRR (Jira)]

[ 
https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169852#comment-17169852
 ] 

JRRR commented on NET-686:
--

[~sebb] Sorry, I already changed that in my code but forgot to change it in the 
file too.

> Most files aren't downloaded completely from an FTP server
> --
>
> Key: NET-686
> URL: https://issues.apache.org/jira/browse/NET-686
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.6
> Environment: Win 10
> Java 8
> Android Studio 3.6.1 (min SDK 24, target SDK 27)
>Reporter: JRRR
>Priority: Major
> Attachments: DownloadProblem.java
>
>
> About a month ago I opened another 
> [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because 
> it wasn't reproducible with macOS and a public FTP server.
> Short summary: Downloading files from an FTP server results in these files 
> randomly missing bytes. It looks like the download always "completes" and 
> there are no error messages/exceptions but random bytes in random files are 
> simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe 
> 40, bytes smaller than the original), and are then also visibly corrupt, than 
> text files (usually only 2-3 bytes smaller, rarely more).
> I'm working on an Android app (Win 10, Java 8, Androis Studio 3.6.1, min SDK 
> 24, target SDK 27), which I'm testing with FTP servers in the same network 
> (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what 
> method in the library I use (retrieveFile, retrieveFileStream, 
> sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a 
> single file that's corrupted.
> I also tested the same code with public servers and even though I didn't have 
> a lot of time because those servers regularely delete uploaded files, I never 
> experienced said problem with them.
> I even wrote my own mini-library (just for login/logout and download) using 
> Java's default "Socket" but I still had the same problem on Android Studio's 
> simulator/a real device. BUT: When I used the same code to create a small 
> Windows/Swing/Java app, there were no more corrupted files.
> It looks like this bug is only affecting a very specific combination of 
> OS,...:
> Android (emulator/real device) + Java (8) + FTP server in the same network 
> (accessed via IP)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (LANG-1593) Common behaviour for StringUtils join APIs when called with char or String delimiter

[Kiruahxh (Jira)]

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

Kiruahxh updated LANG-1593:
---
Description: 
For now, join(int[], char) is working well.
 However, the same join method called with a string delimiter behaves 
differently : it returns  a single memory addresses which is not the desired 
behavior.
 I think that, for coherence, calling StringUtils with a char or String 
delimiter should return the exact same value.

Ex :
{code:java}
CLASSPATH="./commons-lang3-3.11.jar" jshell 
|  Welcome to JShell -- Version 11.0.8
jshell> import org.apache.commons.lang3.StringUtils
jshell> int[] arr = {1, 2, 3, 4, 5, 6, 7};
jshell> String result = StringUtils.join(arr, '-');
result ==> "1-2-3-4-5-6-7"
jshell> String result = StringUtils.join(arr, "-");
result ==> "[I@69663380-"
{code}
 

  was:
For now, join(int[], char) is working well.
 However, the same join method called with a string delimiter behaves 
differently : it returns memory addresses which is rarely the desired behavior.
 I think that, for coherence, calling StringUtils with a char or String 
delimiter should return the exact same value.

Ex :
{code:java}
CLASSPATH="./commons-lang3-3.4.jar" jshell 
|  Welcome to JShell -- Version 11.0.8
|  For an introduction type: /help intro

jshell> /env -class-path commons-lang3-3.4.jar
|  Setting new options and restoring state.
jshell> import org.apache.commons.lang3.StringUtils;jshell>

int[] arr = new int[] {1, 2, 3, 4, 5, 6, 7};
jshell> String result = StringUtils.join(arr, '-');
result ==> "1-2-3-4-5-6-7"
jshell> String result = StringUtils.join(arr, "-");
result ==> "[I@69663380-"
{code}
 


> Common behaviour for StringUtils join APIs when called with char or String 
> delimiter
> 
>
> Key: LANG-1593
> URL: https://issues.apache.org/jira/browse/LANG-1593
> Project: Commons Lang
>  Issue Type: Improvement
>Affects Versions: 3.4, 3.11
>Reporter: Kiruahxh
>Priority: Minor
>
> For now, join(int[], char) is working well.
>  However, the same join method called with a string delimiter behaves 
> differently : it returns  a single memory addresses which is not the desired 
> behavior.
>  I think that, for coherence, calling StringUtils with a char or String 
> delimiter should return the exact same value.
> Ex :
> {code:java}
> CLASSPATH="./commons-lang3-3.11.jar" jshell 
> |  Welcome to JShell -- Version 11.0.8
> jshell> import org.apache.commons.lang3.StringUtils
> jshell> int[] arr = {1, 2, 3, 4, 5, 6, 7};
> jshell> String result = StringUtils.join(arr, '-');
> result ==> "1-2-3-4-5-6-7"
> jshell> String result = StringUtils.join(arr, "-");
> result ==> "[I@69663380-"
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (LANG-1593) Common behaviour for StringUtils join APIs when called with char or String delimiter

[Kiruahxh (Jira)]

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

Kiruahxh updated LANG-1593:
---
Affects Version/s: 3.11

> Common behaviour for StringUtils join APIs when called with char or String 
> delimiter
> 
>
> Key: LANG-1593
> URL: https://issues.apache.org/jira/browse/LANG-1593
> Project: Commons Lang
>  Issue Type: Improvement
>Affects Versions: 3.4, 3.11
>Reporter: Kiruahxh
>Priority: Minor
>
> For now, join(int[], char) is working well.
>  However, the same join method called with a string delimiter behaves 
> differently : it returns memory addresses which is rarely the desired 
> behavior.
>  I think that, for coherence, calling StringUtils with a char or String 
> delimiter should return the exact same value.
> Ex :
> {code:java}
> CLASSPATH="./commons-lang3-3.4.jar" jshell 
> |  Welcome to JShell -- Version 11.0.8
> |  For an introduction type: /help intro
> jshell> /env -class-path commons-lang3-3.4.jar
> |  Setting new options and restoring state.
> jshell> import org.apache.commons.lang3.StringUtils;jshell>
> int[] arr = new int[] {1, 2, 3, 4, 5, 6, 7};
> jshell> String result = StringUtils.join(arr, '-');
> result ==> "1-2-3-4-5-6-7"
> jshell> String result = StringUtils.join(arr, "-");
> result ==> "[I@69663380-"
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (LANG-1593) Common behaviour for StringUtils join APIs when called with char or String delimiter

[Kiruahxh (Jira)]

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

Kiruahxh updated LANG-1593:
---
Description: 
For now, join(int[], char) is working well.
 However, the same join method called with a string delimiter behaves 
differently : it returns memory addresses which is rarely the desired behavior.
 I think that, for coherence, calling StringUtils with a char or String 
delimiter should return the exact same value.

Ex :
{code:java}
CLASSPATH="./commons-lang3-3.4.jar" jshell 
|  Welcome to JShell -- Version 11.0.8
|  For an introduction type: /help intro

jshell> /env -class-path commons-lang3-3.4.jar
|  Setting new options and restoring state.
jshell> import org.apache.commons.lang3.StringUtils;jshell>

int[] arr = new int[] {1, 2, 3, 4, 5, 6, 7};
jshell> String result = StringUtils.join(arr, '-');
result ==> "1-2-3-4-5-6-7"
jshell> String result = StringUtils.join(arr, "-");
result ==> "[I@69663380-"
{code}
 

  was:
For now, join(int[], char) is working well.
However, the same join method called with a string delimiter behaves 
differently : it returns memory addresses which is rarely the desired behavior.
I think that, for coherence, calling StringUtils with a char or String 
delimiter should return the exact same value.


> Common behaviour for StringUtils join APIs when called with char or String 
> delimiter
> 
>
> Key: LANG-1593
> URL: https://issues.apache.org/jira/browse/LANG-1593
> Project: Commons Lang
>  Issue Type: Improvement
>Affects Versions: 3.4
>Reporter: Kiruahxh
>Priority: Minor
>
> For now, join(int[], char) is working well.
>  However, the same join method called with a string delimiter behaves 
> differently : it returns memory addresses which is rarely the desired 
> behavior.
>  I think that, for coherence, calling StringUtils with a char or String 
> delimiter should return the exact same value.
> Ex :
> {code:java}
> CLASSPATH="./commons-lang3-3.4.jar" jshell 
> |  Welcome to JShell -- Version 11.0.8
> |  For an introduction type: /help intro
> jshell> /env -class-path commons-lang3-3.4.jar
> |  Setting new options and restoring state.
> jshell> import org.apache.commons.lang3.StringUtils;jshell>
> int[] arr = new int[] {1, 2, 3, 4, 5, 6, 7};
> jshell> String result = StringUtils.join(arr, '-');
> result ==> "1-2-3-4-5-6-7"
> jshell> String result = StringUtils.join(arr, "-");
> result ==> "[I@69663380-"
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (LANG-1593) Common behaviour for StringUtils join APIs when called with char or String delimiter

[Kiruahxh (Jira)]

Kiruahxh created LANG-1593:
--

 Summary: Common behaviour for StringUtils join APIs when called 
with char or String delimiter
 Key: LANG-1593
 URL: https://issues.apache.org/jira/browse/LANG-1593
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 3.4
Reporter: Kiruahxh


For now, join(int[], char) is working well.
However, the same join method called with a string delimiter behaves 
differently : it returns memory addresses which is rarely the desired behavior.
I think that, for coherence, calling StringUtils with a char or String 
delimiter should return the exact same value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-io] coveralls commented on pull request #135: Bump junit-pioneer from 0.7.0 to 0.8.0

[GitBox]

coveralls commented on pull request #135:
URL: https://github.com/apache/commons-io/pull/135#issuecomment-667841079


   
   [![Coverage 
Status](https://coveralls.io/builds/32494743/badge)](https://coveralls.io/builds/32494743)
   
   Coverage remained the same at 89.935% when pulling 
**3eed86c334d88306e23a216d8523df320adf232a on 
dependabot/maven/org.junit-pioneer-junit-pioneer-0.8.0** into 
**e24da2b905c93685a3dbcc5e8758d360b6f6be56 on master**.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] coveralls commented on pull request #597: Bump junit-pioneer from 0.7.0 to 0.8.0

[GitBox]

coveralls commented on pull request #597:
URL: https://github.com/apache/commons-lang/pull/597#issuecomment-667837259


   
   [![Coverage 
Status](https://coveralls.io/builds/32494566/badge)](https://coveralls.io/builds/32494566)
   
   Coverage remained the same at 94.665% when pulling 
**d1ab9d77397e184c6923f3b41849ead1a0eec342 on 
dependabot/maven/org.junit-pioneer-junit-pioneer-0.8.0** into 
**26dc0118d486ef89f463a0da0837cca86950dcbf on master**.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-lang] dependabot[bot] opened a new pull request #597: Bump junit-pioneer from 0.7.0 to 0.8.0

[GitBox]

dependabot[bot] opened a new pull request #597:
URL: https://github.com/apache/commons-lang/pull/597


   Bumps [junit-pioneer](https://github.com/junit-pioneer/junit-pioneer) from 
0.7.0 to 0.8.0.
   
   Release notes
   Sourced from https://github.com/junit-pioneer/junit-pioneer/releases;>junit-pioneer's 
releases.
   
   v0.8.0
   
   2020-07-30 - https://github.com/junit-pioneer/junit-pioneer/compare/v0.7.0...v0.8.0;>7 
commits by 5 authors - published to https://bintray.com/junit-pioneer/junit-pioneer/junit-pioneer/0.8.0;>https://img.shields.io/badge/Bintray-0.8.0-green.svg; alt="Bintray" 
/>
   Commits: https://github.com/Bukama;>Matthias Bünger (2), https://github.com/aepfli;>Simon Schrottner (2), https://github.com/Michael1993;>Mihály Verhás (1), https://github.com/nicolaiparlog;>Nicolai Parlog (1), sullis (1)
   Fixing gradle-wrapper-validation action [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/304;>#304)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/304;>junit-pioneer/junit-pioneer#304)
   enable Gradle wrapper validation [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/302;>#302)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/302;>junit-pioneer/junit-pioneer#302)
   Provide proposal for new PR template (https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/286;>#286)
 [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/301;>#301)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/301;>junit-pioneer/junit-pioneer#301)
   Add Bradford Hovinen to list of contributors [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/300;>#300)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/300;>junit-pioneer/junit-pioneer#300)
   Adding experimental build for multiple JUnit5 versions (https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/296;>#296)
 [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/297;>#297)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/297;>junit-pioneer/junit-pioneer#297)
   Multiversion build with different JUnit versions [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/296;>#296)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/296;>junit-pioneer/junit-pioneer#296)
   Do not corrupt ProcessEnvironment.theEnvironment on non-Windows 
platforms. [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/288;>#288)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/288;>junit-pioneer/junit-pioneer#288)
   https://github.com/SetEnvironmentVariable;>@SetEnvironmentVariable 
corrupts JDK-internal structures in some cases [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/287;>#287)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/287;>junit-pioneer/junit-pioneer#287)
   Update PR-Template [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/286;>#286)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/286;>junit-pioneer/junit-pioneer#286)
   Revamp/improvement of StdIoExtension [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/275;>#275)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/275;>junit-pioneer/junit-pioneer#275)
   Improvements to StdIOExtension [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/274;>#274)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/274;>junit-pioneer/junit-pioneer#274)
   
   
   
   
   Changelog
   Sourced from https://github.com/junit-pioneer/junit-pioneer/blob/master/docs/release-notes.md;>junit-pioneer's
 changelog.
   
   0.8.0
   
   2020-07-30 - https://github.com/junit-pioneer/junit-pioneer/compare/v0.7.0...v0.8.0;>7 
commits by 5 authors - published to https://bintray.com/junit-pioneer/junit-pioneer/junit-pioneer/0.8.0;>https://img.shields.io/badge/Bintray-0.8.0-green.svg; alt="Bintray" 
/>
   Commits: https://github.com/Bukama;>Matthias Bünger (2), https://github.com/aepfli;>Simon Schrottner (2), https://github.com/Michael1993;>Mihály Verhás (1), https://github.com/nicolaiparlog;>Nicolai Parlog (1), sullis (1)
   Fixing gradle-wrapper-validation action [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/304;>#304)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/304;>junit-pioneer/junit-pioneer#304)
   enable Gradle wrapper validation [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/302;>#302)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/302;>junit-pioneer/junit-pioneer#302)
   Provide proposal for new PR template 

[GitHub] [commons-io] dependabot[bot] opened a new pull request #135: Bump junit-pioneer from 0.7.0 to 0.8.0

[GitBox]

dependabot[bot] opened a new pull request #135:
URL: https://github.com/apache/commons-io/pull/135


   Bumps [junit-pioneer](https://github.com/junit-pioneer/junit-pioneer) from 
0.7.0 to 0.8.0.
   
   Release notes
   Sourced from https://github.com/junit-pioneer/junit-pioneer/releases;>junit-pioneer's 
releases.
   
   v0.8.0
   
   2020-07-30 - https://github.com/junit-pioneer/junit-pioneer/compare/v0.7.0...v0.8.0;>7 
commits by 5 authors - published to https://bintray.com/junit-pioneer/junit-pioneer/junit-pioneer/0.8.0;>https://img.shields.io/badge/Bintray-0.8.0-green.svg; alt="Bintray" 
/>
   Commits: https://github.com/Bukama;>Matthias Bünger (2), https://github.com/aepfli;>Simon Schrottner (2), https://github.com/Michael1993;>Mihály Verhás (1), https://github.com/nicolaiparlog;>Nicolai Parlog (1), sullis (1)
   Fixing gradle-wrapper-validation action [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/304;>#304)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/304;>junit-pioneer/junit-pioneer#304)
   enable Gradle wrapper validation [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/302;>#302)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/302;>junit-pioneer/junit-pioneer#302)
   Provide proposal for new PR template (https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/286;>#286)
 [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/301;>#301)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/301;>junit-pioneer/junit-pioneer#301)
   Add Bradford Hovinen to list of contributors [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/300;>#300)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/300;>junit-pioneer/junit-pioneer#300)
   Adding experimental build for multiple JUnit5 versions (https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/296;>#296)
 [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/297;>#297)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/297;>junit-pioneer/junit-pioneer#297)
   Multiversion build with different JUnit versions [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/296;>#296)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/296;>junit-pioneer/junit-pioneer#296)
   Do not corrupt ProcessEnvironment.theEnvironment on non-Windows 
platforms. [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/288;>#288)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/288;>junit-pioneer/junit-pioneer#288)
   https://github.com/SetEnvironmentVariable;>@SetEnvironmentVariable 
corrupts JDK-internal structures in some cases [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/287;>#287)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/287;>junit-pioneer/junit-pioneer#287)
   Update PR-Template [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/286;>#286)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/286;>junit-pioneer/junit-pioneer#286)
   Revamp/improvement of StdIoExtension [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/275;>#275)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/275;>junit-pioneer/junit-pioneer#275)
   Improvements to StdIOExtension [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/274;>#274)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/274;>junit-pioneer/junit-pioneer#274)
   
   
   
   
   Changelog
   Sourced from https://github.com/junit-pioneer/junit-pioneer/blob/master/docs/release-notes.md;>junit-pioneer's
 changelog.
   
   0.8.0
   
   2020-07-30 - https://github.com/junit-pioneer/junit-pioneer/compare/v0.7.0...v0.8.0;>7 
commits by 5 authors - published to https://bintray.com/junit-pioneer/junit-pioneer/junit-pioneer/0.8.0;>https://img.shields.io/badge/Bintray-0.8.0-green.svg; alt="Bintray" 
/>
   Commits: https://github.com/Bukama;>Matthias Bünger (2), https://github.com/aepfli;>Simon Schrottner (2), https://github.com/Michael1993;>Mihály Verhás (1), https://github.com/nicolaiparlog;>Nicolai Parlog (1), sullis (1)
   Fixing gradle-wrapper-validation action [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/304;>#304)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/304;>junit-pioneer/junit-pioneer#304)
   enable Gradle wrapper validation [(https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/issues/302;>#302)](https://github-redirect.dependabot.com/junit-pioneer/junit-pioneer/pull/302;>junit-pioneer/junit-pioneer#302)
   Provide proposal for new PR template