[jira] [Commented] (LANG-1327) org.apache.commons.lang3.time.DateFormatUtils.formatUTC (10L, "") throws java.lang.StringIndexOutOfBoundsException exception

2017-05-02 Thread Bruno P. Kinoshita (JIRA) 

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

Bruno P. Kinoshita commented on LANG-1327:
--

(was writing probably at the same time [~chonton] closed the issue. Agree with 
his comment, but will leave mine here too FWIW)

Looks like that changed indeed from 3.4 to 3.5, but not in DateFormatUtils, but 
in FastDatePrinter. See:

{noformat}git diff LANG_3_4 master 
src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java{noformat}

Instead of simply calling the format method, now it's checking which rules it 
can apply, and in your case not applying anything, and simply returning an 
empty String.

Adding a note to DateFormatUtils#format(Long, String) for that, would mean 
adding a note to all other methods that receive a pattern argument iff the 
behaviour is consistent (i.e. if for all these methods, passing an empty 
pattern, returns an empty string). However, I would argue that it would make 
more sense to document an exception, such as StringIndexOutOfBoundsException, 
rather than document that we won't throw an exception, and instead will return 
empty.

Passing an empty pattern, users might guess that they will receive an empty 
date. I would be fine if the consensus was to document all methods stating that 
an empty pattern will return an empty formatted date but, my preferred solution 
is to close this as Won't Fix. 

> org.apache.commons.lang3.time.DateFormatUtils.formatUTC (10L, "") throws 
> java.lang.StringIndexOutOfBoundsException exception
> 
>
> Key: LANG-1327
> URL: https://issues.apache.org/jira/browse/LANG-1327
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.4, 3.5
> Environment: JRE 8
>Reporter: Gleison Brito Batista
>
> I am calling method formatUTC() of class
> org.apache.commons.lang3.time.DateFormatUtils
> as in this code:
> java.lang.String var2 = 
> org.apache.commons.lang3.time.DateFormatUtils.formatUTC (10L, "")
> In version 3.4, the call is throwing a
> java.lang.StringIndexOutOfBoundsException exception.
> But in version 3.5 it returns an empty string ("").
> According the documentation, the parameter patter can not be null.
> Is correct this method accept empty string as pattern parameter?



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

[jira] [Closed] (LANG-1327) org.apache.commons.lang3.time.DateFormatUtils.formatUTC (10L, "") throws java.lang.StringIndexOutOfBoundsException exception

2017-05-02 Thread Charles Honton (JIRA) 

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

Charles Honton closed LANG-1327.

Resolution: Not A Problem

> org.apache.commons.lang3.time.DateFormatUtils.formatUTC (10L, "") throws 
> java.lang.StringIndexOutOfBoundsException exception
> 
>
> Key: LANG-1327
> URL: https://issues.apache.org/jira/browse/LANG-1327
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.4, 3.5
> Environment: JRE 8
>Reporter: Gleison Brito Batista
>
> I am calling method formatUTC() of class
> org.apache.commons.lang3.time.DateFormatUtils
> as in this code:
> java.lang.String var2 = 
> org.apache.commons.lang3.time.DateFormatUtils.formatUTC (10L, "")
> In version 3.4, the call is throwing a
> java.lang.StringIndexOutOfBoundsException exception.
> But in version 3.5 it returns an empty string ("").
> According the documentation, the parameter patter can not be null.
> Is correct this method accept empty string as pattern parameter?



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

[jira] [Commented] (LANG-1327) org.apache.commons.lang3.time.DateFormatUtils.formatUTC (10L, "") throws java.lang.StringIndexOutOfBoundsException exception

2017-05-02 Thread Charles Honton (JIRA) 

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

Charles Honton commented on LANG-1327:
--

Empty format is legal, even if non-sensical. Since there are no format 
specifiers, the output should be an empty string. 

> org.apache.commons.lang3.time.DateFormatUtils.formatUTC (10L, "") throws 
> java.lang.StringIndexOutOfBoundsException exception
> 
>
> Key: LANG-1327
> URL: https://issues.apache.org/jira/browse/LANG-1327
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.4, 3.5
> Environment: JRE 8
>Reporter: Gleison Brito Batista
>
> I am calling method formatUTC() of class
> org.apache.commons.lang3.time.DateFormatUtils
> as in this code:
> java.lang.String var2 = 
> org.apache.commons.lang3.time.DateFormatUtils.formatUTC (10L, "")
> In version 3.4, the call is throwing a
> java.lang.StringIndexOutOfBoundsException exception.
> But in version 3.5 it returns an empty string ("").
> According the documentation, the parameter patter can not be null.
> Is correct this method accept empty string as pattern parameter?



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

[jira] [Resolved] (TEXT-82) Bring WordUtils back in to the code base

2017-05-02 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins resolved TEXT-82.
--
Resolution: Implemented

Thanks to Amey Jadiye

> Bring WordUtils back in to the code base
> 
>
> Key: TEXT-82
> URL: https://issues.apache.org/jira/browse/TEXT-82
> Project: Commons Text
>  Issue Type: Task
>Reporter: Rob Tompkins
> Fix For: 1.1
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I would like to get {{WordUtils}}, either from commons-lang, or from the 
> branch "TEXT-55" specifically viewable here: 
> https://github.com/apache/commons-text/blob/TEXT-55/src/main/java/org/apache/commons/text/WordUtils.java
> Also insert any tests that go along with it.



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

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

2017-05-02 Thread Gary Gregory (JIRA) 

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

Gary Gregory commented on CODEC-234:


Hi All,

I'm OK with making the mappings {{0-O 1-I}} optional. I'd like community 
feedback on what the default should be.

Gary

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



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

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

2017-05-02 Thread Christopher Schultz (JIRA) 

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

Christopher Schultz commented on CODEC-234:
---

[~garydgregory] Yeah, that's the passage to which I was referring.

It's worth noting that the Hex class is already case-insensitive, as a result 
of its use of Character.digit(char,int) method.

I'm okay not supporting 0 (zero) as an alias for O (capital oh) and 1 as an 
alias for "I" (capital eye), at least not as a default.

But as it stands, this class behaves in a *very* surprising way for lower-case 
input.

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



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

[jira] [Comment Edited] (COMPRESS-392) Add Brotli decoder based on the Google Brotli library

2017-05-02 Thread Gary Gregory (JIRA) 

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

Gary Gregory edited comment on COMPRESS-392 at 5/2/17 7:36 PM:
---

Patch committed and further tweaked (missing {{\@Override}}s and such), thank 
you!

[~p.moua...@ubik-ingenierie.com]: Can you please provide updates in a separate 
patch (you can attach it here or use GitHub, up to you) for our pages: 
- https://commons.apache.org/proper/commons-compress/examples.html See the 
source file src/site/xdoc/examples.xml.
- https://commons.apache.org/proper/commons-compress/limitations.html See the 
source file src/site/xdoc/limitations.xml.

Tank you,
Gary


was (Author: garydgregory):
Patch committed and further tweaked ({{missing @Override}}s), thank you!

[~p.moua...@ubik-ingenierie.com]: Can you please provide updates in a separate 
patch (you can attach it here or use GitHub, up to you) for our pages: 
- https://commons.apache.org/proper/commons-compress/examples.html See the 
source file src/site/xdoc/examples.xml.
- https://commons.apache.org/proper/commons-compress/limitations.html See the 
source file src/site/xdoc/limitations.xml.

Tank you,
Gary

> Add Brotli decoder based on the Google Brotli library
> -
>
> Key: COMPRESS-392
> URL: https://issues.apache.org/jira/browse/COMPRESS-392
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Compressors
>Affects Versions: 1.10
>Reporter: Philippe Mouawad
>Assignee: Gary Gregory
> Fix For: 1.14
>
>
> PR:
> - https://github.com/apache/commons-compress/pull/23
> See also:
> - https://github.com/google/brotli
> - 
> https://opensource.googleblog.com/2015/09/introducing-brotli-new-compression.html



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

[jira] [Comment Edited] (COMPRESS-392) Add Brotli decoder based on the Google Brotli library

2017-05-02 Thread Gary Gregory (JIRA) 

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

Gary Gregory edited comment on COMPRESS-392 at 5/2/17 7:35 PM:
---

Patch committed and further tweaked ({{missing @Override}}s), thank you!

[~p.moua...@ubik-ingenierie.com]: Can you please provide updates in a separate 
patch (you can attach it here or use GitHub, up to you) for our pages: 
- https://commons.apache.org/proper/commons-compress/examples.html See the 
source file src/site/xdoc/examples.xml.
- https://commons.apache.org/proper/commons-compress/limitations.html See the 
source file src/site/xdoc/limitations.xml.

Tank you,
Gary


was (Author: garydgregory):
Patch committed and further tweaked ({{missing @Override}}s), thank you!

[~p.moua...@ubik-ingenierie.com]: Can you please provide updates in a separate 
patch (you can attach it here or use GitHub, up to you) for our pages: 
- https://commons.apache.org/proper/commons-compress/examples.html ? See the 
source file src/site/xdoc/examples.xml.
- https://commons.apache.org/proper/commons-compress/limitations.html See the 
source file src/site/xdoc/limitations.xml.

Tank you,
Gary

> Add Brotli decoder based on the Google Brotli library
> -
>
> Key: COMPRESS-392
> URL: https://issues.apache.org/jira/browse/COMPRESS-392
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Compressors
>Affects Versions: 1.10
>Reporter: Philippe Mouawad
>Assignee: Gary Gregory
> Fix For: 1.14
>
>
> PR:
> - https://github.com/apache/commons-compress/pull/23
> See also:
> - https://github.com/google/brotli
> - 
> https://opensource.googleblog.com/2015/09/introducing-brotli-new-compression.html



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

[jira] [Commented] (COMPRESS-392) Add Brotli decoder based on the Google Brotli library

2017-05-02 Thread Gary Gregory (JIRA) 

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

Gary Gregory commented on COMPRESS-392:
---

Patch committed and further tweaked ({{missing @Override}}s), thank you!

[~p.moua...@ubik-ingenierie.com]: Can you please provide updates in a separate 
patch (you can attach it here or use GitHub, up to you) for our pages: 
- https://commons.apache.org/proper/commons-compress/examples.html ? See the 
source file src/site/xdoc/examples.xml.
- https://commons.apache.org/proper/commons-compress/limitations.html See the 
source file src/site/xdoc/limitations.xml.

Tank you,
Gary

> Add Brotli decoder based on the Google Brotli library
> -
>
> Key: COMPRESS-392
> URL: https://issues.apache.org/jira/browse/COMPRESS-392
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Compressors
>Affects Versions: 1.10
>Reporter: Philippe Mouawad
>Assignee: Gary Gregory
> Fix For: 1.14
>
>
> PR:
> - https://github.com/apache/commons-compress/pull/23
> See also:
> - https://github.com/google/brotli
> - 
> https://opensource.googleblog.com/2015/09/introducing-brotli-new-compression.html



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

[jira] [Updated] (COMPRESS-392) Add Brotli decoder based on the Google Brotli library

2017-05-02 Thread Gary Gregory (JIRA) 

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

Gary Gregory updated COMPRESS-392:
--
Assignee: Gary Gregory

> Add Brotli decoder based on the Google Brotli library
> -
>
> Key: COMPRESS-392
> URL: https://issues.apache.org/jira/browse/COMPRESS-392
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Compressors
>Affects Versions: 1.10
>Reporter: Philippe Mouawad
>Assignee: Gary Gregory
> Fix For: 1.14
>
>
> PR:
> - https://github.com/apache/commons-compress/pull/23
> See also:
> - https://github.com/google/brotli
> - 
> https://opensource.googleblog.com/2015/09/introducing-brotli-new-compression.html



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

[jira] [Updated] (COMPRESS-392) Add Brotli decoder based on the Google Brotli library

2017-05-02 Thread Gary Gregory (JIRA) 

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

Gary Gregory updated COMPRESS-392:
--
Description: 
PR:

- https://github.com/apache/commons-compress/pull/23

See also:
- https://github.com/google/brotli
- 
https://opensource.googleblog.com/2015/09/introducing-brotli-new-compression.html

  was:
PR:

- https://github.com/apache/commons-compress/pull/23


> Add Brotli decoder based on the Google Brotli library
> -
>
> Key: COMPRESS-392
> URL: https://issues.apache.org/jira/browse/COMPRESS-392
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Compressors
>Affects Versions: 1.10
>Reporter: Philippe Mouawad
> Fix For: 1.14
>
>
> PR:
> - https://github.com/apache/commons-compress/pull/23
> See also:
> - https://github.com/google/brotli
> - 
> https://opensource.googleblog.com/2015/09/introducing-brotli-new-compression.html



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

[jira] [Updated] (COMPRESS-392) Add Brotli decoder based on the Google Brotli library

2017-05-02 Thread Gary Gregory (JIRA) 

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

Gary Gregory updated COMPRESS-392:
--
Summary: Add Brotli decoder based on the Google Brotli library  (was: Add 
Brotli decoder based on google Brotli library)

> Add Brotli decoder based on the Google Brotli library
> -
>
> Key: COMPRESS-392
> URL: https://issues.apache.org/jira/browse/COMPRESS-392
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Compressors
>Affects Versions: 1.10
>Reporter: Philippe Mouawad
> Fix For: 1.14
>
>
> PR:
> - https://github.com/apache/commons-compress/pull/23



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

[jira] [Commented] (TEXT-55) Move WordUtils off on to its own branch

2017-05-02 Thread Amey Jadiye (JIRA) 

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

Amey Jadiye commented on TEXT-55:
-

pushing this back to master for release 1.1

> Move WordUtils off on to its own branch
> ---
>
> Key: TEXT-55
> URL: https://issues.apache.org/jira/browse/TEXT-55
> Project: Commons Text
>  Issue Type: Task
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
> Fix For: 1.0
>
>
> Create a branch for WordUtils and delete from master.



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

[jira] [Updated] (IO-535) FileAlterationMonitor

2017-05-02 Thread Anthony RAYMOND (JIRA) 

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

Anthony RAYMOND updated IO-535:
---
Description: 
The thread in FileAlterationMonitor wasn't stopped by the `stop(int)` method, 
which forbid application to shutdown until all `Thread` are exited (if 
FileAlterationMonitor is part of a DI managed component).

This behavior conflict with the method javadoc `@param stopInterval the amount 
of time in milliseconds to wait for the thread to finish.`

h5. Simple example to understand

Bad behavior
{code:java}
Thread t = new Thread(() -> {
try {
Thread.sleep(50);
} catch (final InterruptedException e) {
}
});
t.start();
t.join(50);
   // Ok, we reach this point until 50ms are elapsed, but the thread is 
still alive.
   //   because Thread#join(int) does not kill the thread. And the thread 
remains alive.
{code}

Good behavior
{code:java}
Thread t = new Thread(() -> {
try {
Thread.sleep(50);
} catch (final InterruptedException e) {
}
});
t.start();
t.join(50);
t.interupt();
   // Thread is exited
{code}

In this case, we waited the given time BEFORE exiting the `Thread`, as 
described in the javadoc, and the `Thread` is now finished and killed.

  was:
The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, 
which forbid application to shutdown unless all `Thread` are exited (if 
FileAlterationMonitor is part of a DI managed component).

This behavior conflict with the method javadoc `@param stopInterval the amount 
of time in milliseconds to wait for the thread to finish.`

h5. Simple example to understand

Bad behavior
{code:java}
Thread t = new Thread(() -> {
try {
Thread.sleep(50);
} catch (final InterruptedException e) {
}
});
t.start();
t.join(50);
   // Ok, we reach this point until 50ms are elapsed, but the thread is 
still alive.
   //   because Thread#join(int) does not kill the thread. And the thread 
remains alive.
{code}

Good behavior
{code:java}
Thread t = new Thread(() -> {
try {
Thread.sleep(50);
} catch (final InterruptedException e) {
}
});
t.start();
t.join(50);
t.interupt();
   // Thread is exited
{code}

In this case, we waited the given time BEFORE exiting the `Thread`, as 
described in the javadoc, and the `Thread` is now finished and killed.

Component/s: Utilities

> FileAlterationMonitor
> -
>
> Key: IO-535
> URL: https://issues.apache.org/jira/browse/IO-535
> Project: Commons IO
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 2.5
> Environment: Components managed by a DI Framework
>Reporter: Anthony RAYMOND
>Priority: Critical
>  Labels: easyfix, patch, performance
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> The thread in FileAlterationMonitor wasn't stopped by the `stop(int)` method, 
> which forbid application to shutdown until all `Thread` are exited (if 
> FileAlterationMonitor is part of a DI managed component).
> This behavior conflict with the method javadoc `@param stopInterval the 
> amount of time in milliseconds to wait for the thread to finish.`
> h5. Simple example to understand
> Bad behavior
> {code:java}
> Thread t = new Thread(() -> {
> try {
> Thread.sleep(50);
> } catch (final InterruptedException e) {
> }
> });
> t.start();
> t.join(50);
>// Ok, we reach this point until 50ms are elapsed, but the thread is 
> still alive.
>//   because Thread#join(int) does not kill the thread. And the thread 
> remains alive.
> {code}
> Good behavior
> {code:java}
> Thread t = new Thread(() -> {
> try {
> Thread.sleep(50);
> } catch (final InterruptedException e) {
> }
> });
> t.start();
> t.join(50);
> t.interupt();
>// Thread is exited
> {code}
> In this case, we waited the given time BEFORE exiting the `Thread`, as 
> described in the javadoc, and the `Thread` is now finished and killed.



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

[jira] [Updated] (IO-535) FileAlterationMonitor

2017-05-02 Thread Anthony RAYMOND (JIRA) 

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

Anthony RAYMOND updated IO-535:
---
Remaining Estimate: 5m  (was: 1h)
 Original Estimate: 5m  (was: 1h)

> FileAlterationMonitor
> -
>
> Key: IO-535
> URL: https://issues.apache.org/jira/browse/IO-535
> Project: Commons IO
>  Issue Type: Bug
>Affects Versions: 2.5
> Environment: Components managed by a DI Framework
>Reporter: Anthony RAYMOND
>Priority: Critical
>  Labels: easyfix, patch, performance
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, 
> which forbid application to shutdown unless all `Thread` are exited (if 
> FileAlterationMonitor is part of a DI managed component).
> This behavior conflict with the method javadoc `@param stopInterval the 
> amount of time in milliseconds to wait for the thread to finish.`
> h5. Simple example to understand
> Bad behavior
> {code:java}
> Thread t = new Thread(() -> {
> try {
> Thread.sleep(50);
> } catch (final InterruptedException e) {
> }
> });
> t.start();
> t.join(50);
>// Ok, we reach this point until 50ms are elapsed, but the thread is 
> still alive.
>//   because Thread#join(int) does not kill the thread. And the thread 
> remains alive.
> {code}
> Good behavior
> {code:java}
> Thread t = new Thread(() -> {
> try {
> Thread.sleep(50);
> } catch (final InterruptedException e) {
> }
> });
> t.start();
> t.join(50);
> t.interupt();
>// Thread is exited
> {code}
> In this case, we waited the given time BEFORE exiting the `Thread`, as 
> described in the javadoc, and the `Thread` is now finished and killed.



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

[jira] [Commented] (NET-407) Change lenientFutureDates to default to true

2017-05-02 Thread Sebb (JIRA) 

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

Sebb commented on NET-407:
--

Thanks:

URL: http://svn.apache.org/viewvc?rev=1793530=rev
Log:
Javadoc fix (NET-407)

Modified:

commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/FTPClientConfig.java


> Change lenientFutureDates to default to true
> 
>
> Key: NET-407
> URL: https://issues.apache.org/jira/browse/NET-407
> Project: Commons Net
>  Issue Type: Improvement
>  Components: FTP
>Affects Versions: 2.2
>Reporter: Sebb
> Fix For: 3.0
>
>
> [See 
> http://mail-archives.apache.org/mod_mbox/commons-dev/201105.mbox/%3CBANLkTi=b9kg-kptgtho2op4cut2dt1h...@mail.gmail.com%3E]
> NET-83 added an option to allow dates to be up to 1 day in the future, but 
> this is not the default.
> This means that FTP will assume the wrong year when listing recent files 
> which are on servers with a clock which is ahead of the client.
> This includes servers in a different timezone (unless the user specifies the 
> server timezone) - e.g. client in US listing files on a server in the UK.
> As far as I can tell, Unix servers use short dates for dates within about +/- 
> 6 months of the current date, so this should not cause any
> problems. But of course it is possible that some servers use short dates for 
> past dates only.
> The behaviour of FTP parsing is likely to be improved overall by changing the 
> default to allow dates up to 1 day into the future.



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

[jira] [Created] (LANG-1327) org.apache.commons.lang3.time.DateFormatUtils.formatUTC (10L, "") throws java.lang.StringIndexOutOfBoundsException exception

2017-05-02 Thread Gleison Brito Batista (JIRA) 
Gleison Brito Batista created LANG-1327:
---

 Summary: org.apache.commons.lang3.time.DateFormatUtils.formatUTC 
(10L, "") throws java.lang.StringIndexOutOfBoundsException exception
 Key: LANG-1327
 URL: https://issues.apache.org/jira/browse/LANG-1327
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.time.*
Affects Versions: 3.5, 3.4
 Environment: JRE 8
Reporter: Gleison Brito Batista


I am calling method formatUTC() of class
org.apache.commons.lang3.time.DateFormatUtils
as in this code:
java.lang.String var2 = org.apache.commons.lang3.time.DateFormatUtils.formatUTC 
(10L, "")
In version 3.4, the call is throwing a
java.lang.StringIndexOutOfBoundsException exception.
But in version 3.5 it returns an empty string ("").
According the documentation, the parameter patter can not be null.
Is correct this method accept empty string as pattern parameter?



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

[jira] [Commented] (NET-407) Change lenientFutureDates to default to true

2017-05-02 Thread Marnix Kammer (JIRA) 

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

Marnix Kammer commented on NET-407:
---

The JavaDoc of FTPClientConfig#setLenientFutureDates has not been modified to 
reflect this improvement - it still says that false is the default value of 
lenientFutureDates.

> Change lenientFutureDates to default to true
> 
>
> Key: NET-407
> URL: https://issues.apache.org/jira/browse/NET-407
> Project: Commons Net
>  Issue Type: Improvement
>  Components: FTP
>Affects Versions: 2.2
>Reporter: Sebb
> Fix For: 3.0
>
>
> [See 
> http://mail-archives.apache.org/mod_mbox/commons-dev/201105.mbox/%3CBANLkTi=b9kg-kptgtho2op4cut2dt1h...@mail.gmail.com%3E]
> NET-83 added an option to allow dates to be up to 1 day in the future, but 
> this is not the default.
> This means that FTP will assume the wrong year when listing recent files 
> which are on servers with a clock which is ahead of the client.
> This includes servers in a different timezone (unless the user specifies the 
> server timezone) - e.g. client in US listing files on a server in the UK.
> As far as I can tell, Unix servers use short dates for dates within about +/- 
> 6 months of the current date, so this should not cause any
> problems. But of course it is possible that some servers use short dates for 
> past dates only.
> The behaviour of FTP parsing is likely to be improved overall by changing the 
> default to allow dates up to 1 day into the future.



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

[jira] [Updated] (COMPRESS-392) Add Brotli decoder based on google Brotli library

2017-05-02 Thread Philippe Mouawad (JIRA) 

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

Philippe Mouawad updated COMPRESS-392:
--
Description: 
PR:

- https://github.com/apache/commons-compress/pull/23

  was:
PR:

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


> Add Brotli decoder based on google Brotli library
> -
>
> Key: COMPRESS-392
> URL: https://issues.apache.org/jira/browse/COMPRESS-392
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Compressors
>Affects Versions: 1.10
>Reporter: Philippe Mouawad
> Fix For: 1.14
>
>
> PR:
> - https://github.com/apache/commons-compress/pull/23



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

[jira] [Commented] (COMPRESS-392) Add Brotli decoder based on google Brotli library

2017-05-02 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on COMPRESS-392:
-

GitHub user pmouawad opened a pull request:

https://github.com/apache/commons-compress/pull/23

Add Brotli Support

Fix for:
https://issues.apache.org/jira/browse/COMPRESS-392

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

$ git pull https://github.com/pmouawad/commons-compress BROTLI_SUPPORT

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

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


commit 3763178324921dc4110d683682b341f2d2e0fd5e
Author: pmouawad 
Date:   2017-05-02T06:37:26Z

Add Brotli Support




> Add Brotli decoder based on google Brotli library
> -
>
> Key: COMPRESS-392
> URL: https://issues.apache.org/jira/browse/COMPRESS-392
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Compressors
>Affects Versions: 1.10
>Reporter: Philippe Mouawad
> Fix For: 1.14
>
>
> PR:
> - https://github.com/apache/commons-codec/pull/6



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

[jira] [Updated] (COMPRESS-392) Add Brotli decoder based on google Brotli library

2017-05-02 Thread Philippe Mouawad (JIRA) 

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

Philippe Mouawad updated COMPRESS-392:
--
Fix Version/s: (was: 1.11)
   1.14

> Add Brotli decoder based on google Brotli library
> -
>
> Key: COMPRESS-392
> URL: https://issues.apache.org/jira/browse/COMPRESS-392
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Compressors
>Affects Versions: 1.10
>Reporter: Philippe Mouawad
> Fix For: 1.14
>
>
> PR:
> - https://github.com/apache/commons-codec/pull/6



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