[jira] [Commented] (COMPRESS-390) Expose zip stream offset and size via API
[ https://issues.apache.org/jira/browse/COMPRESS-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15992323#comment-15992323 ] ASF GitHub Bot commented on COMPRESS-390: - Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/22 [](https://coveralls.io/builds/11326518) Coverage increased (+0.04%) to 84.329% when pulling **0f74248f5fcfdcc4f4b6782fbacf2ed17674faf7 on kvr000:feature/COMPRESS-390-expose-file-offset-via-api** into **65184bc08140c7695ed6b39aa0e77b0dba61be92 on apache:master**. > Expose zip stream offset and size via API > - > > Key: COMPRESS-390 > URL: https://issues.apache.org/jira/browse/COMPRESS-390 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.13 >Reporter: Zbynek Vyskovsky > Labels: features, github-import, patch > Fix For: 1.14 > > > In certain cases it may be useful to get information about where in the > archive the stream starts and ends. Typically when zip is used as resource > container and the resources are then mapped directly into memory, but not > only. > The size and compressed size are already available but not the stream offset. > This can be applied to other archive types as well, therefore it would make > sense to put this into basic interface - ArchiveEntry. But not necessarily > all of them have to support it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IO-535) FileAlterationMonitor
[
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 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.
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
{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}
{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.
> 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: 1h
> Remaining Estimate: 1h
>
> 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] (IO-535) FileAlterationMonitor
[
https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15991817#comment-15991817
]
Anthony RAYMOND commented on IO-535:
GitHub pull request : https://github.com/apache/commons-io/pull/36
> 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: 1h
> Remaining Estimate: 1h
>
> 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
> {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}
> {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
[
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 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.`
hn5 Simple example to understand
{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}
{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.`
hn.5 Simple example to understand
{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}
{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.
> 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: 1h
> Remaining Estimate: 1h
>
> 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.`
> hn5 Simple example to understand
> {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}
> {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
[
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 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
{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}
{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.`
hn5 Simple example to understand
{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}
{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.
> 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: 1h
> Remaining Estimate: 1h
>
> 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
> {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}
> {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
[
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 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
{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}
{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
{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}
{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.
> 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: 1h
> Remaining Estimate: 1h
>
> 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
> {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}
> {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
[
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 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.`
hn.5 Simple example to understand
{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}
{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.`
### Simple example to understand
{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}
{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.
> 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: 1h
> Remaining Estimate: 1h
>
> 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.`
> hn.5 Simple example to understand
> {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}
> {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
[
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 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.`
### Simple example to understand
{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}
{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.`
### Simple example to understand
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.
Thread t = new Thread(() -> {
try {
Thread.sleep(50);
} catch (final InterruptedException e) {
}
});
t.start();
t.join(50);
t.interupt();
// Thread is exited
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.
> 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: 1h
> Remaining Estimate: 1h
>
> 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.`
> ### Simple example to understand
> {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}
> {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] [Resolved] (MATH-1354) Easy conversion from BigDecimal to BigFraction
[
https://issues.apache.org/jira/browse/MATH-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-1354.
--
Resolution: Won't Do
Moved to "Commons Numbers" project.
> Easy conversion from BigDecimal to BigFraction
> --
>
> Key: MATH-1354
> URL: https://issues.apache.org/jira/browse/MATH-1354
> Project: Commons Math
> Issue Type: Wish
>Reporter: Dobes Vandermeer
> Labels: commons-numbers
> Fix For: 4.0
>
>
> Users of BigFraction might also be working with BigDecimal. Here's a simple
> way to convert BigDecimal to BigFraction:
> {code}
> public static BigFraction bigDecimalToBigFraction(BigDecimal bd) {
> int scale = bd.scale();
> // If scale >= 0 then the value is bd.unscaledValue() / 10^scale
> if(scale >= 0)
> return new BigFraction(bd.unscaledValue(),
> BigInteger.TEN.pow(scale));
> // If scale < 0 then the value is bd.unscaledValue() * 10^-scale
> return new
> BigFraction(bd.unscaledValue().multiply(BigInteger.TEN.pow(-scale)));
> }
> {code}
> It might be nice to have this incorporated into the BigFraction class as a
> constructor.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IO-535) FileAlterationMonitor
[
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 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.`
### Simple example to understand
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.
Thread t = new Thread(() -> {
try {
Thread.sleep(50);
} catch (final InterruptedException e) {
}
});
t.start();
t.join(50);
t.interupt();
// Thread is exited
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.`
### Simple exemple to understand
```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.
```
```java
Thread t = new Thread(() -> {
try {
Thread.sleep(50);
} catch (final InterruptedException e) {
}
});
t.start();
t.join(50);
t.interupt();
// Thread is exited
```
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.
> 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: 1h
> Remaining Estimate: 1h
>
> 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.`
> ### Simple example to understand
> 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.
> Thread t = new Thread(() -> {
> try {
> Thread.sleep(50);
> } catch (final InterruptedException e) {
> }
> });
> t.start();
> t.join(50);
> t.interupt();
>// Thread is exited
> 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] [Created] (IO-535) FileAlterationMonitor
Anthony RAYMOND created IO-535:
--
Summary: 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
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.`
### Simple exemple to understand
```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.
```
```java
Thread t = new Thread(() -> {
try {
Thread.sleep(50);
} catch (final InterruptedException e) {
}
});
t.start();
t.join(50);
t.interupt();
// Thread is exited
```
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] [Created] (NUMBERS-32) MATH-1354 (fraction)
Gilles created NUMBERS-32: - Summary: MATH-1354 (fraction) Key: NUMBERS-32 URL: https://issues.apache.org/jira/browse/NUMBERS-32 Project: Commons Numbers Issue Type: Task Reporter: Gilles Priority: Minor Fix For: 1.0 Issue moved from "Commons Math". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MATH-1397) Complex.ZERO.pow(2.0) is NaN
[
https://issues.apache.org/jira/browse/MATH-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-1397.
--
Resolution: Won't Do
Issue moved to "Commons Numbers", and fixed there.
> Complex.ZERO.pow(2.0) is NaN
>
>
> Key: MATH-1397
> URL: https://issues.apache.org/jira/browse/MATH-1397
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: Linux, Java1.7/Java1.8
>Reporter: Mario Wenzel
>Assignee: Eric Barnhill
>Priority: Minor
> Fix For: 4.0
>
>
> ```
> package complextest;
> import org.apache.commons.math3.complex.Complex;
> public class T {
> public static void main(String[] args) {
> System.out.println(Complex.ZERO.pow(2.0));
> }
> }
> ```
> This is the code and the readout is `(NaN, NaN)`. This surely isn't right.
> For one, it should actually be zero
> (https://www.wolframalpha.com/input/?i=(0%2B0i)%5E2) and second of all, the
> documentation doesn't state that anything could go wrong from a Complex
> number that has no NaNs and Infs.
> The other definition states that it doesn't work when the base is Zero, but
> it surely should. This strange corner case destroys any naive implementation
> of stuff wrt the mandelbrot set.
> It would be nice to not have to implement this exception myself.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MATH-1382) MultivariateNormalDistribution.density() unnecessarily copies means array in loop
[ https://issues.apache.org/jira/browse/MATH-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-1382. -- Resolution: Fixed commit dff1a0953d97d46290750a46d01be1e1519ae698 Thanks for the report (and sorry for the delay in updating the code). > MultivariateNormalDistribution.density() unnecessarily copies means array in > loop > - > > Key: MATH-1382 > URL: https://issues.apache.org/jira/browse/MATH-1382 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Stefan Bunk >Priority: Trivial > Labels: easyfix > Fix For: 4.0 > > > In the class MultivariateNormalDistribution, the public method density() > calls the private method getExponentTerm(), which first centers the given > instance by the mean. > However, it is using the method getMeans(), which creates a copy of means > array each time, just for reading the i-th index. > See > https://github.com/apache/commons-math/blob/3.6.1-release/src/main/java/org/apache/commons/math3/distribution/MultivariateNormalDistribution.java#L238 > A solution should use the private variable `means` directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CODEC-234) Base32.decode should support lowercase letters
[
https://issues.apache.org/jira/browse/CODEC-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15991752#comment-15991752
]
Gary Gregory commented on CODEC-234:
How about quote from section 6 in https://tools.ietf.org/html/rfc4648:
{quote}
The Base 32 encoding is designed to represent arbitrary sequences of
octets in a form that needs to be case insensitive but that need not
be human readable.
{quote}
There is the same kind of text WRT base16, which would be neat to support (just
for fun ;-)
> 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] [Resolved] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-1414.
--
Resolution: Won't Do
Issue to be fixed in "Commons Numbers": see NUMBERS-22.
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
> Fix For: 4.0
>
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MATH-1332) For 4.0, deprecate method name getArgument() and replace with arg()
[ https://issues.apache.org/jira/browse/MATH-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-1332. -- Resolution: Won't Do Issue to be dealt with in the refactoring that now happens in the "Commons Numbers" component. > For 4.0, deprecate method name getArgument() and replace with arg() > --- > > Key: MATH-1332 > URL: https://issues.apache.org/jira/browse/MATH-1332 > Project: Commons Math > Issue Type: Improvement >Reporter: Eric Barnhill >Priority: Trivial > Labels: commons-numbers > Fix For: 4.0 > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Currently magnitude of complex is returned by calling abs while phase angle > is returned by calling getArgument(). I propose deprecating getArgument and > using arg() because: > -- it's not really an accessor method since the argument is computed > -- arg() is shorter, more elegant and similar to abs() with which its usage > will sometimes be paired -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CODEC-234) Base32.decode should support lowercase letters
[
https://issues.apache.org/jira/browse/CODEC-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15991707#comment-15991707
]
Sebb commented on CODEC-234:
bq. RFC 4648 makes it clear that case-insensitivity is a goal for Base32
encoding.
I could not find a reference to that.
I'm not sure that accepting 0 and 1 is a good idea.
In any case, I don't think it's a good idea to unconditionally change the
default behaviour.
Any such change (if agreed) ought to be optional.
> 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] [Resolved] (MATH-667) Representations of the complex numbers
[
https://issues.apache.org/jira/browse/MATH-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-667.
-
Resolution: Won't Do
Issue moved to "Commons Numbers": see NUMBERS-31.
> Representations of the complex numbers
> --
>
> Key: MATH-667
> URL: https://issues.apache.org/jira/browse/MATH-667
> Project: Commons Math
> Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
> Labels: commons-numbers, features
> Fix For: 4.0
>
>
> Several issues have been raised about the current behaviour of the "Complex"
> class, located in package "o.a.c.m.complex" (e.g. MATH-657, MATH-620).
> The ensuing discussion revealed various, sometimes incompatible, requirements
> with focus on efficiency or consistency or backwards compatibility or
> comparison with other math packages (Octave) or faithfulness to standards
> (C99x).
> It is thus proposed to create several classes, each with a clearly defined
> purpose.
> The consensus seems to be that the first task is to implement a new
> "BasicComplex" class where the computational formulae (for computing real and
> imaginary part of a complex) will be applied directly without worrying about
> limiting cases (NaNs and infinities). Doing so will automatically produce a
> behaviour similar to the Java {{double}} primitive. It is also assumed that
> it will be the most efficient implementation for "normal" use (i.e. not
> involving limiting cases).
> This task would consist in copying most of the code in the existing "Complex"
> class over to "BasicComplex". And similarly with "ComplexTest". Then, in
> "BasicComplex", one would remove all variables that refer to NaNs and
> infinities together with checks and special assignments, and adapt the unit
> tests along the way.
> A new "ExtendedComplex" class would inherit from "BasicComplex". This class
> would aim at representing the compactified space of the complex numbers (one
> point-at-infinity).
> A new "C99Complex" class would inherit from "BasicComplex". This class would
> aim at implementing the C99x standard.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (NUMBERS-31) MATH-667 (complex numbers)
Gilles created NUMBERS-31: - Summary: MATH-667 (complex numbers) Key: NUMBERS-31 URL: https://issues.apache.org/jira/browse/NUMBERS-31 Project: Commons Numbers Issue Type: Task Reporter: Gilles Fix For: 1.0 Copy of "Commons Math" request that is now part of "Commons Numbers". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NUMBERS-29) Move combinatorics utilities from "Commons Math"
[
https://issues.apache.org/jira/browse/NUMBERS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated NUMBERS-29:
--
Description: Create a new {{commons-numbers-combinatorics}} module to
contain the code in classes {{CombinatoricsUtils}} and {{Combinations}}
(located in package {{o.a.c.math4.util}}). (was: Create a new
{{commons-numbers-combinatorics}} to contain the code in classes
{{CombinatoricsUtils}} and {{Combinations}} (located in package
{{o.a.c.math4.util}}).)
> Move combinatorics utilities from "Commons Math"
>
>
> Key: NUMBERS-29
> URL: https://issues.apache.org/jira/browse/NUMBERS-29
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Gilles
>Priority: Minor
> Labels: module, move
> Fix For: 1.0
>
>
> Create a new {{commons-numbers-combinatorics}} module to contain the code in
> classes {{CombinatoricsUtils}} and {{Combinations}} (located in package
> {{o.a.c.math4.util}}).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (NUMBERS-26) Update "Commons" main site
[ https://issues.apache.org/jira/browse/NUMBERS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved NUMBERS-26. --- Resolution: Done > Update "Commons" main site > -- > > Key: NUMBERS-26 > URL: https://issues.apache.org/jira/browse/NUMBERS-26 > Project: Commons Numbers > Issue Type: Task >Reporter: Gilles >Priority: Minor > Labels: web-site > > "Commons Numbers" should appear on the "Commons" web page. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (COMPRESS-392) Add Brotli decoder based on google Brotli library
Philippe Mouawad created COMPRESS-392: - Summary: 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.11 PR: - https://github.com/apache/commons-codec/pull/6 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CODEC-234) Base32.decode should support lowercase letters
[
https://issues.apache.org/jira/browse/CODEC-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Schultz updated CODEC-234:
--
Attachment: CODEC-234.diff
Proposed patch to support lowercase input.
This patch also recognizes "1" (numeral one) as an alias for "I" (upper case
eye) as well as "0" (numeral zero) as an alias for "O" (upper case oh).
This patch has been written with patch-readability in mind. It can be minimized
with further alterations to the declaration of the DECODE_TABLE static member
in the Base32 class.
> 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] [Created] (CODEC-234) Base32.decode should support lowercase letters
Christopher Schultz created CODEC-234:
-
Summary: 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
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] [Resolved] (IO-367) Add convenience methods for copyToDirectory
[
https://issues.apache.org/jira/browse/IO-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher resolved IO-367.
--
Resolution: Fixed
Assignee: Pascal Schumacher
Fix Version/s: 2.6
Patch applied (with small changes)! Thanks!
> Add convenience methods for copyToDirectory
> ---
>
> Key: IO-367
> URL: https://issues.apache.org/jira/browse/IO-367
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Affects Versions: 2.5
>Reporter: Cornelius Lilge
>Assignee: Pascal Schumacher
>Priority: Minor
> Labels: features
> Fix For: 2.6
>
> Attachments: IO-367.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I suggest adding the following convenience methods:
> First:
> {{void copyToDirectory(final File src, final File destDir)}} which will
> simply select either
> {{copyFileToDirectory}}
> or
> {{copyDirectoryToDirectory}}.
> Second:
> {{void copyToDirectory(final Collection srcs, final File destDir)}}
> which will simply use {{copyToDirectory}} for each file object.
> Implementation of these methods should be straight foward as they would only
> recombine methods that are already existing and tested.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IO-367) Add convenience methods for copyToDirectory
[
https://issues.apache.org/jira/browse/IO-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990928#comment-15990928
]
ASF GitHub Bot commented on IO-367:
---
Github user asfgit closed the pull request at:
https://github.com/apache/commons-io/pull/34
> Add convenience methods for copyToDirectory
> ---
>
> Key: IO-367
> URL: https://issues.apache.org/jira/browse/IO-367
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Affects Versions: 2.5
>Reporter: Cornelius Lilge
>Priority: Minor
> Labels: features
> Attachments: IO-367.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I suggest adding the following convenience methods:
> First:
> {{void copyToDirectory(final File src, final File destDir)}} which will
> simply select either
> {{copyFileToDirectory}}
> or
> {{copyDirectoryToDirectory}}.
> Second:
> {{void copyToDirectory(final Collection srcs, final File destDir)}}
> which will simply use {{copyToDirectory}} for each file object.
> Implementation of these methods should be straight foward as they would only
> recombine methods that are already existing and tested.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1304) Add a method in StringUtils to check for mixed case in string
[
https://issues.apache.org/jira/browse/LANG-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990802#comment-15990802
]
ASF GitHub Bot commented on LANG-1304:
--
Github user arbasha commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/223#discussion_r114124824
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -7193,6 +7193,45 @@ public static boolean isAllUpperCase(final
CharSequence cs) {
return true;
}
+/**
+ * Checks if the CharSequence contains mixed casing of both
uppercase and lowercase characters.
+ *
+ * {@code null} will return {@code false}.
+ * An empty String (length()=0) will return {@code false}.
+ *
+ *
+ * StringUtils.isMixedCase(null)= false
+ * StringUtils.isMixedCase("") = false
+ * StringUtils.isMixedCase("aBc") = true
+ * StringUtils.isMixedCase("ABC") = false
+ * StringUtils.isMixedCase("abc") = false
+ * StringUtils.isMixedCase("A c") = false
+ * StringUtils.isMixedCase("A1c") = false
+ * StringUtils.isMixedCase("a/C") = false
+ *
+ *
+ * @param cs the CharSequence to check, may be null
+ * @return {@code true} if contains both uppercase and lowercase
characters, and is non-null
+ */
+public static boolean isMixedCase(final CharSequence cs) {
+if (cs == null || isEmpty(cs)) {
+return false;
+}
+boolean containsUppercase = false;
+boolean containsLowercase = false;
+final int sz = cs.length();
+for (int i = 0; i < sz; i++) {
--- End diff --
Hi, @PascalSchumacher I second @bindul's point, this method should return
true if the CharSequence has at least one upperCase and one lowerCase
character. As a requester of this feature I would like to see this method
behave that way.
> Add a method in StringUtils to check for mixed case in string
> -
>
> Key: LANG-1304
> URL: https://issues.apache.org/jira/browse/LANG-1304
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Arshad Basha
>Priority: Minor
>
> It would be nice to have a method that check whether the string has mixed
> (lower and upper) case.
> Examples:
> StringUtils.isMixedCase("passWORD"); //true
> StringUtils.isMixedCase("PASSWORD"); //false
> StringUtils.isMixedCase("password"); //false
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang pull request #223: [LANG-1304] StringUtils method to check for ...
Github user arbasha commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/223#discussion_r114124824
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -7193,6 +7193,45 @@ public static boolean isAllUpperCase(final
CharSequence cs) {
return true;
}
+/**
+ * Checks if the CharSequence contains mixed casing of both
uppercase and lowercase characters.
+ *
+ * {@code null} will return {@code false}.
+ * An empty String (length()=0) will return {@code false}.
+ *
+ *
+ * StringUtils.isMixedCase(null)= false
+ * StringUtils.isMixedCase("") = false
+ * StringUtils.isMixedCase("aBc") = true
+ * StringUtils.isMixedCase("ABC") = false
+ * StringUtils.isMixedCase("abc") = false
+ * StringUtils.isMixedCase("A c") = false
+ * StringUtils.isMixedCase("A1c") = false
+ * StringUtils.isMixedCase("a/C") = false
+ *
+ *
+ * @param cs the CharSequence to check, may be null
+ * @return {@code true} if contains both uppercase and lowercase
characters, and is non-null
+ */
+public static boolean isMixedCase(final CharSequence cs) {
+if (cs == null || isEmpty(cs)) {
+return false;
+}
+boolean containsUppercase = false;
+boolean containsLowercase = false;
+final int sz = cs.length();
+for (int i = 0; i < sz; i++) {
--- End diff --
Hi, @PascalSchumacher I second @bindul's point, this method should return
true if the CharSequence has at least one upperCase and one lowerCase
character. As a requester of this feature I would like to see this method
behave that way.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (LANG-1164) allow ToStringStyle to omitNulls
[ https://issues.apache.org/jira/browse/LANG-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990761#comment-15990761 ] ASF GitHub Bot commented on LANG-1164: -- Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/209 Oh, TIL. I think we can't close this pull request, and wait in case a user needs this feature :+1: > allow ToStringStyle to omitNulls > > > Key: LANG-1164 > URL: https://issues.apache.org/jira/browse/LANG-1164 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* >Reporter: Shaun A Elliott > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #209: LANG-1164: allow ToStringStyle to omitNulls
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/209 Oh, TIL. I think we can't close this pull request, and wait in case a user needs this feature :+1: --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1164) allow ToStringStyle to omitNulls
[ https://issues.apache.org/jira/browse/LANG-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990718#comment-15990718 ] ASF GitHub Bot commented on LANG-1164: -- Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/209 Thanks. :smile: You won't need this to exclude `null` values when using `ReflectionToStringBuilder`, see https://github.com/apache/commons-lang/pull/259 This will only be useful for custom `ToStringBuilder` implementations. I'm not sure that is is still worth adding given ReflectionToStringBuilder#excludeNullValues`. What do you think? > allow ToStringStyle to omitNulls > > > Key: LANG-1164 > URL: https://issues.apache.org/jira/browse/LANG-1164 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* >Reporter: Shaun A Elliott > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #209: LANG-1164: allow ToStringStyle to omitNulls
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/209 Thanks. :smile: You won't need this to exclude `null` values when using `ReflectionToStringBuilder`, see https://github.com/apache/commons-lang/pull/259 This will only be useful for custom `ToStringBuilder` implementations. I'm not sure that is is still worth adding given ReflectionToStringBuilder#excludeNullValues`. What do you think? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1164) allow ToStringStyle to omitNulls
[
https://issues.apache.org/jira/browse/LANG-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990708#comment-15990708
]
ASF GitHub Bot commented on LANG-1164:
--
Github user kinow commented on the issue:
https://github.com/apache/commons-lang/pull/209
+1 lgtm
Looks useful, I've wanted that feature a couple of times when using
ReflectionToStringBuilder in the past.
Merging the code locally, the build passes, all reports look good but
Chekstyle.
```
org/apache/commons/lang3/builder/ToStringStyle.java
SeverityCategoryRuleMessage Line
Error blocks NeedBraces 'if' construct must use '{}'s. 474
Error blocks NeedBraces 'if' construct must use '{}'s. 908
Error blocks NeedBraces 'if' construct must use '{}'s. 1005
Error blocks NeedBraces 'if' construct must use '{}'s. 1067
Error blocks NeedBraces 'if' construct must use '{}'s. 1129
Error blocks NeedBraces 'if' construct must use '{}'s. 1191
Error blocks NeedBraces 'if' construct must use '{}'s. 1253
Error blocks NeedBraces 'if' construct must use '{}'s. 1315
Error blocks NeedBraces 'if' construct must use '{}'s. 1377
Error blocks NeedBraces 'if' construct must use '{}'s. 1439
```
The inlined if fails with our current checkstyle rules. Other than that,
all looks good :-)
> allow ToStringStyle to omitNulls
>
>
> Key: LANG-1164
> URL: https://issues.apache.org/jira/browse/LANG-1164
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
>Reporter: Shaun A Elliott
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #209: LANG-1164: allow ToStringStyle to omitNulls
Github user kinow commented on the issue:
https://github.com/apache/commons-lang/pull/209
+1 lgtm
Looks useful, I've wanted that feature a couple of times when using
ReflectionToStringBuilder in the past.
Merging the code locally, the build passes, all reports look good but
Chekstyle.
```
org/apache/commons/lang3/builder/ToStringStyle.java
SeverityCategoryRuleMessage Line
Error blocks NeedBraces 'if' construct must use '{}'s. 474
Error blocks NeedBraces 'if' construct must use '{}'s. 908
Error blocks NeedBraces 'if' construct must use '{}'s. 1005
Error blocks NeedBraces 'if' construct must use '{}'s. 1067
Error blocks NeedBraces 'if' construct must use '{}'s. 1129
Error blocks NeedBraces 'if' construct must use '{}'s. 1191
Error blocks NeedBraces 'if' construct must use '{}'s. 1253
Error blocks NeedBraces 'if' construct must use '{}'s. 1315
Error blocks NeedBraces 'if' construct must use '{}'s. 1377
Error blocks NeedBraces 'if' construct must use '{}'s. 1439
```
The inlined if fails with our current checkstyle rules. Other than that,
all looks good :-)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] commons-lang pull request #209: LANG-1164: allow ToStringStyle to omitNulls
Github user kinow commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/209#discussion_r114114198
--- Diff: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
---
@@ -467,6 +472,7 @@ protected void removeLastFieldSeparator(final
StringBuffer buffer) {
* for summary info, null for style decides
*/
public void append(final StringBuffer buffer, final String fieldName,
final Object value, final Boolean fullDetail) {
+if (omitNulls && value == null) return;
--- End diff --
With our current checkstyle checks, this will create an error (error in
Checkstyle, not a build error).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (LANG-1164) allow ToStringStyle to omitNulls
[
https://issues.apache.org/jira/browse/LANG-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990707#comment-15990707
]
ASF GitHub Bot commented on LANG-1164:
--
Github user kinow commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/209#discussion_r114114198
--- Diff: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
---
@@ -467,6 +472,7 @@ protected void removeLastFieldSeparator(final
StringBuffer buffer) {
* for summary info, null for style decides
*/
public void append(final StringBuffer buffer, final String fieldName,
final Object value, final Boolean fullDetail) {
+if (omitNulls && value == null) return;
--- End diff --
With our current checkstyle checks, this will create an error (error in
Checkstyle, not a build error).
> allow ToStringStyle to omitNulls
>
>
> Key: LANG-1164
> URL: https://issues.apache.org/jira/browse/LANG-1164
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
>Reporter: Shaun A Elliott
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #266: docs - fixed faulty samples of isNoneEmpty/isNoneBl...
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/266 Docs look good, reviewed code locally, examples in the JavaDocs look more homogeneous, always displaying the behaviour for arrays with no elements, and for arrays with just a blank string. Merged. Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request #266: docs - fixed faulty samples of isNoneEmpty/i...
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/266 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (LANG-1325) Increase test coverage of ToStringBuilder class to 100%
[ https://issues.apache.org/jira/browse/LANG-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved LANG-1325. -- Resolution: Fixed Pull request merged. changes.xml updated accordingly. > Increase test coverage of ToStringBuilder class to 100% > --- > > Key: LANG-1325 > URL: https://issues.apache.org/jira/browse/LANG-1325 > Project: Commons Lang > Issue Type: Test >Reporter: Arshad Basha >Assignee: Bruno P. Kinoshita >Priority: Minor > > Adding test cases to test the following methods of ToStringBuilder, with > this, the code coverage stands at 100%. > 1) append(final String fieldName, final boolean[] array) > 2) append(final String fieldName, final boolean[] array, final boolean > fullDetail) > 3) append(final String fieldName, final byte[] array) > 4) append(final String fieldName, final byte[] array, final boolean > fullDetail) > 5) append(final String fieldName, final char[] array) > 6) append(final String fieldName, final char[] array, final boolean > fullDetail) > 7) append(final String fieldName, final double[] array) > 8) append(final String fieldName, final double[] array, final boolean > fullDetail) > 9) append(final String fieldName, final float[] array) > 10) append(final String fieldName, final float[] array, final boolean > fullDetail) > 11) append(final String fieldName, final int[] array) > 12) append(final String fieldName, final int[] array, final boolean > fullDetail) > 13) append(final String fieldName, final long[] array) > 14) append(final String fieldName, final long[] array, final boolean > fullDetail) > 15) append(final String fieldName, final Object[] array) > 16) append(final String fieldName, final Object[] array, final boolean > fullDetail) > 17) append(final String fieldName, final short[] array) > 18) append(final String fieldName, final short[] array, final boolean > fullDetail) > 19) appendAsObjectToString(final Object srcObject) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1325) Increase test coverage of ToStringBuilder class to 100%
[ https://issues.apache.org/jira/browse/LANG-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990702#comment-15990702 ] ASF GitHub Bot commented on LANG-1325: -- Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/265 > Increase test coverage of ToStringBuilder class to 100% > --- > > Key: LANG-1325 > URL: https://issues.apache.org/jira/browse/LANG-1325 > Project: Commons Lang > Issue Type: Test >Reporter: Arshad Basha >Assignee: Bruno P. Kinoshita >Priority: Minor > > Adding test cases to test the following methods of ToStringBuilder, with > this, the code coverage stands at 100%. > 1) append(final String fieldName, final boolean[] array) > 2) append(final String fieldName, final boolean[] array, final boolean > fullDetail) > 3) append(final String fieldName, final byte[] array) > 4) append(final String fieldName, final byte[] array, final boolean > fullDetail) > 5) append(final String fieldName, final char[] array) > 6) append(final String fieldName, final char[] array, final boolean > fullDetail) > 7) append(final String fieldName, final double[] array) > 8) append(final String fieldName, final double[] array, final boolean > fullDetail) > 9) append(final String fieldName, final float[] array) > 10) append(final String fieldName, final float[] array, final boolean > fullDetail) > 11) append(final String fieldName, final int[] array) > 12) append(final String fieldName, final int[] array, final boolean > fullDetail) > 13) append(final String fieldName, final long[] array) > 14) append(final String fieldName, final long[] array, final boolean > fullDetail) > 15) append(final String fieldName, final Object[] array) > 16) append(final String fieldName, final Object[] array, final boolean > fullDetail) > 17) append(final String fieldName, final short[] array) > 18) append(final String fieldName, final short[] array, final boolean > fullDetail) > 19) appendAsObjectToString(final Object srcObject) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang pull request #265: LANG-1325: Increase test coverage of ToStrin...
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/265 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1325) Increase test coverage of ToStringBuilder class to 100%
[ https://issues.apache.org/jira/browse/LANG-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990701#comment-15990701 ] Bruno P. Kinoshita commented on LANG-1325: -- Checked out pull request locally, created Maven site with and without the pull request test. The current code has line coverage of 70%, and branch coverage of 91%. With the code in the pull request we get 99% line coverage (though it looks to be 100%), and branch coverage of 100%. Had a look at the test, and everything looks OK. Code well formatted, no tabs found, everything seems to have been correctly updated. Will merge the pull request now, and update changes.xml. Great work, props to [~arshad0789]. Thank you. Bruno > Increase test coverage of ToStringBuilder class to 100% > --- > > Key: LANG-1325 > URL: https://issues.apache.org/jira/browse/LANG-1325 > Project: Commons Lang > Issue Type: Test >Reporter: Arshad Basha >Assignee: Bruno P. Kinoshita >Priority: Minor > > Adding test cases to test the following methods of ToStringBuilder, with > this, the code coverage stands at 100%. > 1) append(final String fieldName, final boolean[] array) > 2) append(final String fieldName, final boolean[] array, final boolean > fullDetail) > 3) append(final String fieldName, final byte[] array) > 4) append(final String fieldName, final byte[] array, final boolean > fullDetail) > 5) append(final String fieldName, final char[] array) > 6) append(final String fieldName, final char[] array, final boolean > fullDetail) > 7) append(final String fieldName, final double[] array) > 8) append(final String fieldName, final double[] array, final boolean > fullDetail) > 9) append(final String fieldName, final float[] array) > 10) append(final String fieldName, final float[] array, final boolean > fullDetail) > 11) append(final String fieldName, final int[] array) > 12) append(final String fieldName, final int[] array, final boolean > fullDetail) > 13) append(final String fieldName, final long[] array) > 14) append(final String fieldName, final long[] array, final boolean > fullDetail) > 15) append(final String fieldName, final Object[] array) > 16) append(final String fieldName, final Object[] array, final boolean > fullDetail) > 17) append(final String fieldName, final short[] array) > 18) append(final String fieldName, final short[] array, final boolean > fullDetail) > 19) appendAsObjectToString(final Object srcObject) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (LANG-1325) Increase test coverage of ToStringBuilder class to 100%
[ https://issues.apache.org/jira/browse/LANG-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated LANG-1325: - Assignee: Bruno P. Kinoshita > Increase test coverage of ToStringBuilder class to 100% > --- > > Key: LANG-1325 > URL: https://issues.apache.org/jira/browse/LANG-1325 > Project: Commons Lang > Issue Type: Test >Reporter: Arshad Basha >Assignee: Bruno P. Kinoshita >Priority: Minor > > Adding test cases to test the following methods of ToStringBuilder, with > this, the code coverage stands at 100%. > 1) append(final String fieldName, final boolean[] array) > 2) append(final String fieldName, final boolean[] array, final boolean > fullDetail) > 3) append(final String fieldName, final byte[] array) > 4) append(final String fieldName, final byte[] array, final boolean > fullDetail) > 5) append(final String fieldName, final char[] array) > 6) append(final String fieldName, final char[] array, final boolean > fullDetail) > 7) append(final String fieldName, final double[] array) > 8) append(final String fieldName, final double[] array, final boolean > fullDetail) > 9) append(final String fieldName, final float[] array) > 10) append(final String fieldName, final float[] array, final boolean > fullDetail) > 11) append(final String fieldName, final int[] array) > 12) append(final String fieldName, final int[] array, final boolean > fullDetail) > 13) append(final String fieldName, final long[] array) > 14) append(final String fieldName, final long[] array, final boolean > fullDetail) > 15) append(final String fieldName, final Object[] array) > 16) append(final String fieldName, final Object[] array, final boolean > fullDetail) > 17) append(final String fieldName, final short[] array) > 18) append(final String fieldName, final short[] array, final boolean > fullDetail) > 19) appendAsObjectToString(final Object srcObject) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1304) Add a method in StringUtils to check for mixed case in string
[
https://issues.apache.org/jira/browse/LANG-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990694#comment-15990694
]
ASF GitHub Bot commented on LANG-1304:
--
Github user PascalSchumacher commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/223#discussion_r114111595
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -7193,6 +7193,45 @@ public static boolean isAllUpperCase(final
CharSequence cs) {
return true;
}
+/**
+ * Checks if the CharSequence contains mixed casing of both
uppercase and lowercase characters.
+ *
+ * {@code null} will return {@code false}.
+ * An empty String (length()=0) will return {@code false}.
+ *
+ *
+ * StringUtils.isMixedCase(null)= false
+ * StringUtils.isMixedCase("") = false
+ * StringUtils.isMixedCase("aBc") = true
+ * StringUtils.isMixedCase("ABC") = false
+ * StringUtils.isMixedCase("abc") = false
+ * StringUtils.isMixedCase("A c") = false
+ * StringUtils.isMixedCase("A1c") = false
+ * StringUtils.isMixedCase("a/C") = false
+ *
+ *
+ * @param cs the CharSequence to check, may be null
+ * @return {@code true} if contains both uppercase and lowercase
characters, and is non-null
+ */
+public static boolean isMixedCase(final CharSequence cs) {
+if (cs == null || isEmpty(cs)) {
+return false;
+}
+boolean containsUppercase = false;
+boolean containsLowercase = false;
+final int sz = cs.length();
+for (int i = 0; i < sz; i++) {
--- End diff --
@arbasha I believe you requested this feature, what is your opinion on this?
> Add a method in StringUtils to check for mixed case in string
> -
>
> Key: LANG-1304
> URL: https://issues.apache.org/jira/browse/LANG-1304
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Arshad Basha
>Priority: Minor
>
> It would be nice to have a method that check whether the string has mixed
> (lower and upper) case.
> Examples:
> StringUtils.isMixedCase("passWORD"); //true
> StringUtils.isMixedCase("PASSWORD"); //false
> StringUtils.isMixedCase("password"); //false
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang pull request #223: [LANG-1304] StringUtils method to check for ...
Github user PascalSchumacher commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/223#discussion_r114111595
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -7193,6 +7193,45 @@ public static boolean isAllUpperCase(final
CharSequence cs) {
return true;
}
+/**
+ * Checks if the CharSequence contains mixed casing of both
uppercase and lowercase characters.
+ *
+ * {@code null} will return {@code false}.
+ * An empty String (length()=0) will return {@code false}.
+ *
+ *
+ * StringUtils.isMixedCase(null)= false
+ * StringUtils.isMixedCase("") = false
+ * StringUtils.isMixedCase("aBc") = true
+ * StringUtils.isMixedCase("ABC") = false
+ * StringUtils.isMixedCase("abc") = false
+ * StringUtils.isMixedCase("A c") = false
+ * StringUtils.isMixedCase("A1c") = false
+ * StringUtils.isMixedCase("a/C") = false
+ *
+ *
+ * @param cs the CharSequence to check, may be null
+ * @return {@code true} if contains both uppercase and lowercase
characters, and is non-null
+ */
+public static boolean isMixedCase(final CharSequence cs) {
+if (cs == null || isEmpty(cs)) {
+return false;
+}
+boolean containsUppercase = false;
+boolean containsLowercase = false;
+final int sz = cs.length();
+for (int i = 0; i < sz; i++) {
--- End diff --
@arbasha I believe you requested this feature, what is your opinion on this?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (LANG-1307) Add a method in StringUtils to extract only digits out of input string
[
https://issues.apache.org/jira/browse/LANG-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990687#comment-15990687
]
ASF GitHub Bot commented on LANG-1307:
--
Github user PascalSchumacher commented on the issue:
https://github.com/apache/commons-lang/pull/225
Thanks!
> Add a method in StringUtils to extract only digits out of input string
> --
>
> Key: LANG-1307
> URL: https://issues.apache.org/jira/browse/LANG-1307
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Arshad Basha
>Priority: Minor
> Fix For: 3.6
>
>
> This method will check if the input String contains Unicode digits, if yes
> then concatenate all the digits and return it as a single String.
> Examples:
> StringUtils.getDigits(null) = null
> StringUtils.getDigits("")= ""
> StringUtils.getDigits("abc") = ""
> StringUtils.getDigits("1000$") = "1000"
> StringUtils.getDigits("1123~45") = "12345"
> StringUtils.getDigits("(541) 754-3010") = "5417543010"
> StringUtils.getDigits("\u0967\u0968\u0969") = "\u0967\u0968\u0969"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1307) Add a method in StringUtils to extract only digits out of input string
[
https://issues.apache.org/jira/browse/LANG-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990688#comment-15990688
]
ASF GitHub Bot commented on LANG-1307:
--
Github user asfgit closed the pull request at:
https://github.com/apache/commons-lang/pull/225
> Add a method in StringUtils to extract only digits out of input string
> --
>
> Key: LANG-1307
> URL: https://issues.apache.org/jira/browse/LANG-1307
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Arshad Basha
>Priority: Minor
> Fix For: 3.6
>
>
> This method will check if the input String contains Unicode digits, if yes
> then concatenate all the digits and return it as a single String.
> Examples:
> StringUtils.getDigits(null) = null
> StringUtils.getDigits("")= ""
> StringUtils.getDigits("abc") = ""
> StringUtils.getDigits("1000$") = "1000"
> StringUtils.getDigits("1123~45") = "12345"
> StringUtils.getDigits("(541) 754-3010") = "5417543010"
> StringUtils.getDigits("\u0967\u0968\u0969") = "\u0967\u0968\u0969"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (LANG-1307) Add a method in StringUtils to extract only digits out of input string
[
https://issues.apache.org/jira/browse/LANG-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher resolved LANG-1307.
-
Resolution: Fixed
Assignee: Pascal Schumacher
Fix Version/s: 3.6
> Add a method in StringUtils to extract only digits out of input string
> --
>
> Key: LANG-1307
> URL: https://issues.apache.org/jira/browse/LANG-1307
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Arshad Basha
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.6
>
>
> This method will check if the input String contains Unicode digits, if yes
> then concatenate all the digits and return it as a single String.
> Examples:
> StringUtils.getDigits(null) = null
> StringUtils.getDigits("")= ""
> StringUtils.getDigits("abc") = ""
> StringUtils.getDigits("1000$") = "1000"
> StringUtils.getDigits("1123~45") = "12345"
> StringUtils.getDigits("(541) 754-3010") = "5417543010"
> StringUtils.getDigits("\u0967\u0968\u0969") = "\u0967\u0968\u0969"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang pull request #225: [LANG-1307] - Add getDigits method to String...
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/225 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #225: [LANG-1307] - Add getDigits method to StringUtils
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/225 Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
