[jira] [Commented] (CONFIGURATION-715) PropertiesConfiguration should not trim whitespace from the property value
[
https://issues.apache.org/jira/browse/CONFIGURATION-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16633490#comment-16633490
]
Oliver Heger commented on CONFIGURATION-715:
Many thanks! I will have a look (probably in a few days).
> PropertiesConfiguration should not trim whitespace from the property value
> --
>
> Key: CONFIGURATION-715
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-715
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Patrick Schmidt
>Priority: Major
>
> Currently, PropertiesConfiguration will trim all trailing whitespace from
> property values. This is different from how java.util.Properties behaves. The
> Javadoc explicitly states
> {code:java}
> All remaining characters on the line become part of the associated element
> string{code}
> The responsible code is in the method _readProperty()_ of _PropertiesReader_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-715) PropertiesConfiguration should not trim whitespace from the property value
[
https://issues.apache.org/jira/browse/CONFIGURATION-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16633362#comment-16633362
]
Patrick Schmidt commented on CONFIGURATION-715:
---
I just created a [pull
request|https://github.com/apache/commons-configuration/pull/13] that also
covers CONFIGURATION-716, plus a bit more related to compatibility with
java.util.Properties. Let me know what you think.
> PropertiesConfiguration should not trim whitespace from the property value
> --
>
> Key: CONFIGURATION-715
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-715
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Patrick Schmidt
>Priority: Major
>
> Currently, PropertiesConfiguration will trim all trailing whitespace from
> property values. This is different from how java.util.Properties behaves. The
> Javadoc explicitly states
> {code:java}
> All remaining characters on the line become part of the associated element
> string{code}
> The responsible code is in the method _readProperty()_ of _PropertiesReader_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16633328#comment-16633328
]
Gilles commented on RNG-57:
---
About this:
{code}
static final class CachedLongProvider extends LongProvider implements
CachedUniformRandomProvider {
{code}
I'm not sure whether it is your intended contribution to the codebase or just
test code for benchmarking.
Unless I'm missing something, I think that the public API should not expose
classes with "Cache" in their name.
Do your benchmarks show that the cache is always useful for performance (or to
never hurt)?
If so, it will be always "on" (an implementation detail).
If not, or there is some advantage to let the choice to the user (wrap or not),
then the public factory methods should be located in {{RandomSource}}, not as a
separate factory class.
In that case, the API must convey _what_ is provided (faster "nextBoolean()"),
not _how_ (caching of "nextInt()" or "nextLong()").
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang issue #299: Add module-info for Java 9
Github user johnou commented on the issue: https://github.com/apache/commons-lang/pull/299 @jodastephen can you be more specific? ---
