date:20161222

[jira] [Closed] (CSV-205) Add convenience API CSVFormat#printer() to print to System.out

2016-12-22 Thread Gary Gregory (JIRA)


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

Gary Gregory closed CSV-205.

Resolution: Fixed

In Git master.

> Add convenience API CSVFormat#printer() to print to System.out
> --
>
> Key: CSV-205
> URL: https://issues.apache.org/jira/browse/CSV-205
> Project: Commons CSV
>  Issue Type: New Feature
>  Components: Printer
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.5
>
>
> Add convenience method CSVFormat#printer()
> {code:java}
> /**
>  * Prints to the {@link System#out}.
>  *
>  * 
>  * See also {@link CSVPrinter}.
>  * 
>  *
>  * @return a printer to {@link System#out}.
>  * @throws IOException
>  * thrown if the optional header cannot be printed.
>  * @since 1.5
>  */
> public CSVPrinter printer() throws IOException {
> return new CSVPrinter(System.out, this);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CSV-205) Add convenience API CSVFormat#printer() to System.out

2016-12-22 Thread Gary Gregory (JIRA)


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

Gary Gregory updated CSV-205:
-
Summary: Add convenience API CSVFormat#printer() to System.out  (was: Add 
convenience method CSVFormat#printer() to System.out)

> Add convenience API CSVFormat#printer() to System.out
> -
>
> Key: CSV-205
> URL: https://issues.apache.org/jira/browse/CSV-205
> Project: Commons CSV
>  Issue Type: New Feature
>  Components: Printer
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.5
>
>
> Add convenience method CSVFormat#printer()
> {code:java}
> /**
>  * Prints to the {@link System#out}.
>  *
>  * 
>  * See also {@link CSVPrinter}.
>  * 
>  *
>  * @return a printer to {@link System#out}.
>  * @throws IOException
>  * thrown if the optional header cannot be printed.
>  * @since 1.5
>  */
> public CSVPrinter printer() throws IOException {
> return new CSVPrinter(System.out, this);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CSV-205) Add convenience API CSVFormat#printer() to print to System.out

2016-12-22 Thread Gary Gregory (JIRA)


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

Gary Gregory updated CSV-205:
-
Summary: Add convenience API CSVFormat#printer() to print to System.out  
(was: Add convenience API CSVFormat#printer() to System.out)

> Add convenience API CSVFormat#printer() to print to System.out
> --
>
> Key: CSV-205
> URL: https://issues.apache.org/jira/browse/CSV-205
> Project: Commons CSV
>  Issue Type: New Feature
>  Components: Printer
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.5
>
>
> Add convenience method CSVFormat#printer()
> {code:java}
> /**
>  * Prints to the {@link System#out}.
>  *
>  * 
>  * See also {@link CSVPrinter}.
>  * 
>  *
>  * @return a printer to {@link System#out}.
>  * @throws IOException
>  * thrown if the optional header cannot be printed.
>  * @since 1.5
>  */
> public CSVPrinter printer() throws IOException {
> return new CSVPrinter(System.out, this);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CSV-205) Add convenience method CSVFormat#printer() to System.out

2016-12-22 Thread Gary Gregory (JIRA)

Gary Gregory created CSV-205:


 Summary: Add convenience method CSVFormat#printer() to System.out
 Key: CSV-205
 URL: https://issues.apache.org/jira/browse/CSV-205
 Project: Commons CSV
  Issue Type: New Feature
  Components: Printer
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 1.5


Add convenience method CSVFormat#printer()

{code:java}
/**
 * Prints to the {@link System#out}.
 *
 * 
 * See also {@link CSVPrinter}.
 * 
 *
 * @return a printer to {@link System#out}.
 * @throws IOException
 * thrown if the optional header cannot be printed.
 * @since 1.5
 */
public CSVPrinter printer() throws IOException {
return new CSVPrinter(System.out, this);
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CONFIGURATION-646) autoSave and manual save behave differently

2016-12-22 Thread Oliver Heger (JIRA)


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

Oliver Heger resolved CONFIGURATION-646.

   Resolution: Fixed
Fix Version/s: 2.2

Your analysis was correct: the event listener for the auto-save mechanism was 
triggered before the layout object, so data was saved that had not yet been 
updated.

The layout is normally registered as first event listener at the configuration; 
this is done when the configuration is created. However, on a load operation 
the layout used to unregister itself temporarily; this moved the listener 
registration at the end of the list.

The fix changed this behavior: The listener is not unregistered, but 
temporarily disabled during a load operation.

Fixed in SVN in revision 1775740.

> autoSave and manual save behave differently
> ---
>
> Key: CONFIGURATION-646
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-646
> Project: Commons Configuration
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christian Rudolph
>Priority: Minor
> Fix For: 2.2
>
>
> Using {{builder.autoSave(true)}} behaves differently than {{builder.save()}} 
> to the aspect that {{builder.autoSave(true)}} doesn't write newly added 
> properties to the assigned config file.
> I've set up a minimal example using only two dependencies:
> commons-beanutils:commons-beanutils:1.9.3 (runtime)
> org.apache.commons:commons-configuration2:2.1.0 (compiletime)
> {code}
> public class Main {
> public static void main(String... args) {
> Parameters params = new Parameters();
> File propertiesFile = new File("conf.properties");
> FileBasedConfigurationBuilder builder =
> new 
> FileBasedConfigurationBuilder<>(PropertiesConfiguration.class)
> 
> .configure(params.fileBased().setFile(propertiesFile));
> builder.setAutoSave(true);
> try {
> PropertiesConfiguration config = builder.getConfiguration();
> config.setProperty("foo", "bar");
> // builder.save();
> } catch (ConfigurationException e) {
> e.printStackTrace();
> }
> }
> }
> {code}
> This is mainly like the example from the documentation for filebased 
> configurations.
> {{conf.properties}} exists and is empty. With the {{builder.save}} line 
> commented out, the file remains empty. Uncommenting this line results in the 
> expected behavior.
> I debugged a bit an saw that the property isn't added to the 
> {{PropertiesConfigurationLayout}} in the first case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TEXT-32) We want a wider variety of edit distances/similarity scores.

2016-12-22 Thread Rob Tompkins (JIRA)


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

Rob Tompkins commented on TEXT-32:
--

Pull Request: https://github.com/apache/commons-text/pull/21

> We want a wider variety of edit distances/similarity scores.
> 
>
> Key: TEXT-32
> URL: https://issues.apache.org/jira/browse/TEXT-32
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>
> Currently we have:
> {code}
> CosineDistance.java
> CosineSimilarity.java
> FuzzyScore.java
> HammingDistance.java
> JaccardDistance.java
> JaccardSimilarity.java
> JaroWinklerDistance.java
> LevenshteinDetailedDistance.java
> LevenshteinDistance.java
> LevenshteinResults.java
> {code}
> We wish to have a larger list of edit distances than this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TEXT-32) We want a wider variety of edit distances/similarity scores.

2016-12-22 Thread Rob Tompkins (JIRA)


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

Rob Tompkins edited comment on TEXT-32 at 12/22/16 8:28 PM:


Based upon: 

http://markmail.org/message/gjhgz2udjbt3o7ih?q=%5Btext%5D%5BTEXT-32%5D

we should consider:

# LongestCommonSubstring (or subword).

with the reference:

https://github.com/tdebatty/java-string-similarity


was (Author: chtompki):
Based upon: 

http://markmail.org/message/gjhgz2udjbt3o7ih?q=%5Btext%5D%5BTEXT-32%5D

we should consider:

# LongestCommonSubstring (or subword).
# Biojava
# Talend

with the reference:

https://github.com/tdebatty/java-string-similarity

> We want a wider variety of edit distances/similarity scores.
> 
>
> Key: TEXT-32
> URL: https://issues.apache.org/jira/browse/TEXT-32
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>
> Currently we have:
> {code}
> CosineDistance.java
> CosineSimilarity.java
> FuzzyScore.java
> HammingDistance.java
> JaccardDistance.java
> JaccardSimilarity.java
> JaroWinklerDistance.java
> LevenshteinDetailedDistance.java
> LevenshteinDistance.java
> LevenshteinResults.java
> {code}
> We wish to have a larger list of edit distances than this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (LANG-1302) java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap

2016-12-22 Thread Duncan Jones (JIRA)


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

Duncan Jones edited comment on LANG-1302 at 12/22/16 3:25 PM:
--

I can't reproduce this from the current trunk. Suspect this is a duplicate of 
LANG-1292 and is now fixed. Will be released in 3.6.

Thanks for reporting the issue.


was (Author: dmjones500):
I can't reproduce this from the current trunk. Suspect this is a duplicate of 
LANG-1292 and is now fixed. Will be released in 3.6.

> java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap
> -
>
> Key: LANG-1302
> URL: https://issues.apache.org/jira/browse/LANG-1302
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.5
> Environment: Mac, Android, Linux
>Reporter: Vadiraj Purohit
>Assignee: Duncan Jones
> Fix For: 3.6
>
>
> Commons-lang3:3.5
> Issue code:
> String appName = "Google Play Store";
> appName = WordUtils.wrap(appName, appName.length()/2);
> System.out.println(appName);
> Resulting exception:
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -3
>   at java.lang.String.substring(String.java:1967)
>   at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:328)
>   at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:176)
>   at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:100)
>   at removedups.Main2.main(Main2.java:32)
> This exception does not occur in commons-lang3:3.4 though



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (LANG-1302) java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap

2016-12-22 Thread Duncan Jones (JIRA)


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

Duncan Jones resolved LANG-1302.

   Resolution: Duplicate
 Assignee: Duncan Jones
Fix Version/s: 3.6

I can't reproduce this from the current trunk. Suspect this is a duplicate of 
LANG-1292 and is now fixed. Will be released in 3.6.

> java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap
> -
>
> Key: LANG-1302
> URL: https://issues.apache.org/jira/browse/LANG-1302
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.5
> Environment: Mac, Android, Linux
>Reporter: Vadiraj Purohit
>Assignee: Duncan Jones
> Fix For: 3.6
>
>
> Commons-lang3:3.5
> Issue code:
> String appName = "Google Play Store";
> appName = WordUtils.wrap(appName, appName.length()/2);
> System.out.println(appName);
> Resulting exception:
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -3
>   at java.lang.String.substring(String.java:1967)
>   at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:328)
>   at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:176)
>   at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:100)
>   at removedups.Main2.main(Main2.java:32)
> This exception does not occur in commons-lang3:3.4 though



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (LANG-1302) java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap

2016-12-22 Thread Vadiraj Purohit (JIRA)


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

Vadiraj Purohit updated LANG-1302:
--
Description: 
Commons-lang3:3.5

Issue code:
String appName = "Google Play Store";
appName = WordUtils.wrap(appName, appName.length()/2);
System.out.println(appName);

Resulting exception:
Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
index out of range: -3
at java.lang.String.substring(String.java:1967)
at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:328)
at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:176)
at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:100)
at removedups.Main2.main(Main2.java:32)

This exception does not occur in commons-lang3:3.4 though

  was:
Commons-lang3:3.5

Issue code:
String appName = "Google Play Store";
appName = WordUtils.wrap(appName, appName.length()/2);
System.out.println(appName);

Resulting exception:
Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
index out of range: -3
at java.lang.String.substring(String.java:1967)
at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:328)
at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:176)
at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:100)
at removedups.Main2.main(Main2.java:32)

This exception does not occur in commons-lang3:3.4


> java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap
> -
>
> Key: LANG-1302
> URL: https://issues.apache.org/jira/browse/LANG-1302
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.5
> Environment: Mac, Android, Linux
>Reporter: Vadiraj Purohit
>
> Commons-lang3:3.5
> Issue code:
> String appName = "Google Play Store";
> appName = WordUtils.wrap(appName, appName.length()/2);
> System.out.println(appName);
> Resulting exception:
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -3
>   at java.lang.String.substring(String.java:1967)
>   at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:328)
>   at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:176)
>   at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:100)
>   at removedups.Main2.main(Main2.java:32)
> This exception does not occur in commons-lang3:3.4 though



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (LANG-1302) java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap

2016-12-22 Thread Vadiraj Purohit (JIRA)

Vadiraj Purohit created LANG-1302:
-

 Summary: java.lang.StringIndexOutOfBoundsException resulting in 
WordUtils.wrap
 Key: LANG-1302
 URL: https://issues.apache.org/jira/browse/LANG-1302
 Project: Commons Lang
  Issue Type: Bug
Affects Versions: 3.5
 Environment: Mac, Android, Linux
Reporter: Vadiraj Purohit


Commons-lang3:3.5

Issue code:
String appName = "Google Play Store";
appName = WordUtils.wrap(appName, appName.length()/2);
System.out.println(appName);

Resulting exception:
Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
index out of range: -3
at java.lang.String.substring(String.java:1967)
at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:328)
at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:176)
at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:100)
at removedups.Main2.main(Main2.java:32)

This exception does not occur in commons-lang3:3.4



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TEXT-36) Dependency on "Commons RNG"

2016-12-22 Thread Gilles (JIRA)


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

Gilles edited comment on TEXT-36 at 12/22/16 1:14 PM:
--

bq. It would be good to hear why people are concerned about a link between TEXT 
and RNG.

+1

Indeed, are there technical objections?

There is nothing in favour of using the JDK's {{Random}} class in new 
applications (or libraries such as TEXT):
* no speed of generation advantage,
* no quality of randomness advantage,
* no memory consumption advantage.

Over the course of developing what has become Commons RNG, I've made a summary 
of [why not to use 
{{java.util.Random}}|http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html].

The only justification for using it is when applications are required to 
reproduce the same sequence as the particular algorithm implemented by 
{{Random}} (needless to say: It is not the most obvious case for "randomness").

bq. Is it a fear of Maven jar hell?

This would be bogus, given that we don't release code that could create it (due 
to the change of package name and coordinates).

bq. Eat our own dog food

+1

IOW tell the world to come and taste it too. :)
And grow the community...

bq. Users can bridge to java.util.Random using RNG's bridge classes

Not sure what you mean.
[JDKRandomBridge|http://commons.apache.org/proper/commons-rng/commons-rng-simple/apidocs/org/apache/commons/rng/simple/JDKRandomBridge.html]
 is a bridge *from* Commons RNG's {{RandomSource}} *to* JDK's {{Random}} (so 
not applicable to pass to a TEXT API based on Commons RNG).
A user who would want to use {{Random}} as the underlying generator would 
create the corresponding 
[{{UniformRandomProvider}}|http://commons.apache.org/proper/commons-rng/commons-rng-simple/apidocs/org/apache/commons/rng/simple/RandomSource.html#JDK].


bq. explicitly offer overloads with java.util.Random.

This is what Gary proposes.

Thus, assuming a {{TextRandomProvider}} interface:
{code}
import java.util.Random;

public class JdkRandomBridge implements TextRandomProvider {
private final Random delegate;

public JdkRandomBridge(Random rng) {
delegate = rng;
}

// TextRandomProvider methods.

/** {@inheritDoc} */
public int nextInt(int min, int max) {
// Generate an integer in range [min, max].
return delegate.nextInt(max + 1) + min;
}
}
{code}

{code}
import org.apache.commons.rng.UniformRandomProvider;

public class CommonsRngBridge implements TextRandomProvider {
private final UniformRandomProvider delegate;

public CommonsRngBridge(UniformRandomProvider rng) {
delegate = rng;
}

// TextRandomProvider methods.
// ...
}
{code}


bq. Offer only java.util.Random in the interface, but shade RNG so that our 
internal default implementations are as good as can be.

This does not look good: Users who care about the source of randomness are 
stuck with a sub-par algorithm, while users who don't care get a better one...

Moreover, as a general remark, I'm -0 on "hiding" a fundamental parameter of 
some functionality (here, the RNG for building _random_ strings).

bq. Don't use RNG at all.

Does not make any sense. ;)



was (Author: erans):
bq. It would be good to hear why people are concerned about a link between TEXT 
and RNG.

+1

Indeed, are there technical objections?

There is nothing in favour of using the JDK's {{Random}} class in new 
applications (or libraries such as TEXT):
* no speed of generation advantage,
* no quality of randomness advantage,
* no memory consumption advantage.

Over the course of developing what has become Commons RNG, I've made a summary 
of [why not to use 
{{java.util.Random}}|http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html].

The only justification for using it is when applications are required to 
reproduce the same sequence as the particular algorithm implemented by 
{{Random}} (needless to say: It is not the most obvious case for "randomness").

bq. Is it a fear of Maven jar hell?

This would be bogus, given that we don't release code that could create it (due 
to the change of package name and coordinates).

bq. Eat our own dog food

+1

bq. Users can bridge to java.util.Random using RNG's bridge classes

Not sure what you mean.
[JDKRandomBridge|http://commons.apache.org/proper/commons-rng/commons-rng-simple/apidocs/org/apache/commons/rng/simple/JDKRandomBridge.html]
 is a bridge *from* Commons RNG's {{RandomSource}} *to* JDK's {{Random}} (so 
not applicable to pass to a TEXT API based on Commons RNG).
A user who would want to use {{Random}} as the underlying generator would 
create the corresponding 
[{{UniformRandomProvider}}|http://commons.apache.org/proper/commons-rng/commons-rng-simple/apidocs/org/apache/commons/rng/simple/RandomSource.html#JDK].


bq. explicitly offer o

[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"

2016-12-22 Thread Gilles (JIRA)


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

Gilles commented on TEXT-36:


bq. It would be good to hear why people are concerned about a link between TEXT 
and RNG.

+1

Indeed, are there technical objections?

There is nothing in favour of using the JDK's {{Random}} class in new 
applications (or libraries such as TEXT):
* no speed of generation advantage,
* no quality of randomness advantage,
* no memory consumption advantage.

Over the course of developing what has become Commons RNG, I've made a summary 
of [why not to use 
{{java.util.Random}}|http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html].

The only justification for using it is when applications are required to 
reproduce the same sequence as the particular algorithm implemented by 
{{Random}} (needless to say: It is not the most obvious case for "randomness").

bq. Is it a fear of Maven jar hell?

This would be bogus, given that we don't release code that could create it (due 
to the change of package name and coordinates).

bq. Eat our own dog food

+1

bq. Users can bridge to java.util.Random using RNG's bridge classes

Not sure what you mean.
[JDKRandomBridge|http://commons.apache.org/proper/commons-rng/commons-rng-simple/apidocs/org/apache/commons/rng/simple/JDKRandomBridge.html]
 is a bridge *from* Commons RNG's {{RandomSource}} *to* JDK's {{Random}} (so 
not applicable to pass to a TEXT API based on Commons RNG).
A user who would want to use {{Random}} as the underlying generator would 
create the corresponding 
[{{UniformRandomProvider}}|http://commons.apache.org/proper/commons-rng/commons-rng-simple/apidocs/org/apache/commons/rng/simple/RandomSource.html#JDK].


bq. explicitly offer overloads with java.util.Random.

This what Gary proposes.

Thus, assuming a {{TextRandomProvider}} interface:
{code}
import java.util.Random;

public class JdkRandomBridge implements TextRandomProvider {
private final Random delegate;

public JdkRandomBridge(Random rng) {
delegate = rng;
}

// TextRandomProvider methods
}
{code}

{code}
import org.apache.commons.rng.UniformRandomProvider;

public class CommonsRngBridge implements TextRandomProvider {
private final UniformRandomProvide delegate;

public CommonsRngBridge(UniformRandomProvider rng) {
delegate = rng;
}

// TextRandomProvider methods
}
{code}


bq. Offer only java.util.Random in the interface, but shade RNG so that our 
internal default implementations are as good as can be.

This does not look good: users who want to control the randomness generation 
are stuck with a sub-par algorithm, while users who don't care get a better 
one...

Moreover, as a general remark, I'm -0 on "hiding" a fundamental parameter of 
some functionality (here, the RNG for building _random_ strings).

bq. Don't use RNG at all.

Does not make any sense. ;)


> Dependency on "Commons RNG"
> ---
>
> Key: TEXT-36
> URL: https://issues.apache.org/jira/browse/TEXT-36
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Gilles
>  Labels: api
> Fix For: 1.0
>
>
> This is a follow-up of a 
> [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15762623]
>  held in TEXT-34.
> IMHO, there is no harm in depending on the ["commons-rng-client-api" 
> module|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/javadocs/api-1.0/index.html]
>  of Commons RNG; the "zero dependency" mantra does not hold here, since TEXT 
> already depends on LANG.
> OTOH, I see that it is counter-productive (i.e. it harms the Commons project 
> as a whole) to not advertize or use other Commons components, despite the 
> "own dog food" phrase appearing recurrently on the "dev" ML.
> Rather than having people blindly use {{java.util.Random}}, we should allow 
> them to choose wisely, based on full information.
> IMO, that means to indeed use {{UniformRandomProvider}} in order to raise 
> awareness about alternatives to the sub-optimal algorithm used by the JDK.
> However, if some Commons developers do not trust that the 
> {{UniformRandomProvider}} interface can be stable enough for TEXT, then we 
> should follow Jochen Wiedemann's advice (cf. archive of the "dev" ML) and 
> define TEXT's own interface to random numbers, with bridges to it from 
> {{UniformRandomProvider}} and from {{java.util.Random}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TEXT-38) Fluent API in "RandomStringBuilder"

2016-12-22 Thread Duncan Jones (JIRA)


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

Duncan Jones commented on TEXT-38:
--

I'd be happy to make this change. It would make it easier to move towards a 
thread-safe implementation.

I propose we rename the class to {{RandomStringGenerator}} and create an inner 
{{Builder}} class. I would also propose we force callers to construct the 
generator using the builder (i.e. the {{RandomStringGenerator}} is private.

Sound ok? If so, I'll make that change.

> Fluent API in "RandomStringBuilder"
> ---
>
> Key: TEXT-38
> URL: https://issues.apache.org/jira/browse/TEXT-38
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Gilles
>  Labels: api
> Fix For: 1.0
>
>
> It can be construed as potentially dangerous to let user code change any of 
> the settings of the builder, as other parts of the code could be using a 
> reference to the same instance.
> In Commons Math, where the fluent API pattern was applied, a new builder 
> (immutable) instance would be created.  For example, see [this 
> class|https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math4/fitting/SimpleCurveFitter.java;h=54f6cbfe1e003cec74f2b0e71efc1b13000a5525;hb=HEAD].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TEXT-37) Global vs local source of randomness

2016-12-22 Thread Duncan Jones (JIRA)


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

Duncan Jones commented on TEXT-37:
--

I think this issue is blocked until we decide on TEXT-38.

If we alter the class (as suggested in TEXT-38), then we would likely have a 
{{RandomStringGenerator}} class with a inner {{Builder}} class. In this 
situation, the builder could accept a random generator in whatever way feels 
most elegant (I would vote for a fluent method call), since it cannot later be 
changed by the user of the generator.

> Global vs local source of randomness
> 
>
> Key: TEXT-37
> URL: https://issues.apache.org/jira/browse/TEXT-37
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Gilles
>  Labels: api, constructor
> Fix For: 1.0
>
>
> This is a follow-up of a 
> [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15761636&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15761636]
>  held in TEXT-34.
> By default, {{RandomStringBuilder}} will use a shared {{java.util.Random}} 
> object.
> I think that the decision of which generator to use lies with the code that 
> _constructs_ the {{RandomStringBuilder}} instance, not with code that _uses_ 
> it (to build a string).
> It would be safer to pass the RNG instance at construction (since, anyways, 
> the constructor must be called):
> {code}
> RandomStringBuilder sb = new RandomStringBuilder(new MyRandom());
> String s = sb.ofLength(length).build();
> {code}
> In the above, the {{MyRandom}} type is the subject of TEXT-36.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (TEXT-36) Dependency on "Commons RNG"

2016-12-22 Thread Duncan Jones (JIRA)


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

Duncan Jones updated TEXT-36:
-
Comment: was deleted

(was: I am currently not in the Office. Your mail will not be forwarded. I will 
be Back on 2017-01-16

If you need technical support with SEEBURGER products, contact 
supp...@seeburger.de or http://servicedesk.seeburger.de

General inquiries can be directed to our info team: i...@seeburger.de

Greetings Bernd Eckenfels
Chief Architect, SEEBURGER AG








SEEBURGER AGVorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:Axel Haas, Michael 
Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the 
SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 
Internet: http://www.seeburger.de   Registergericht/Commercial 
Register:
e-mail: i...@seeburger.de   HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und 
kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. 
Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und 
stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. 
Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und 
jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher 
Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der 
Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer 
Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This 
email may contain confidential material that may be protected by professional 
secrecy. Any fact or opinion contained, or expression of the material herein, 
does not necessarily reflect that of SEEBURGER AG. If you are not the addressee 
or if you have received this email in error, any use, publication or 
distribution including forwarding, copying or printing is strictly prohibited. 
Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for 
viruses; it is your responsibility to check this email and its attachments for 
viruses.

)

> Dependency on "Commons RNG"
> ---
>
> Key: TEXT-36
> URL: https://issues.apache.org/jira/browse/TEXT-36
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Gilles
>  Labels: api
> Fix For: 1.0
>
>
> This is a follow-up of a 
> [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15762623]
>  held in TEXT-34.
> IMHO, there is no harm in depending on the ["commons-rng-client-api" 
> module|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/javadocs/api-1.0/index.html]
>  of Commons RNG; the "zero dependency" mantra does not hold here, since TEXT 
> already depends on LANG.
> OTOH, I see that it is counter-productive (i.e. it harms the Commons project 
> as a whole) to not advertize or use other Commons components, despite the 
> "own dog food" phrase appearing recurrently on the "dev" ML.
> Rather than having people blindly use {{java.util.Random}}, we should allow 
> them to choose wisely, based on full information.
> IMO, that means to indeed use {{UniformRandomProvider}} in order to raise 
> awareness about alternatives to the sub-optimal algorithm used by the JDK.
> However, if some Commons developers do not trust that the 
> {{UniformRandomProvider}} interface can be stable enough for TEXT, then we 
> should follow Jochen Wiedemann's advice (cf. archive of the "dev" ML) and 
> define TEXT's own interface to random numbers, with bridges to it from 
> {{UniformRandomProvider}} and from {{java.util.Random}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"

2016-12-22 Thread Bernd Eckenfels (JIRA)


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

Bernd Eckenfels commented on TEXT-36:
-

I am currently not in the Office. Your mail will not be forwarded. I will be 
Back on 2017-01-16

If you need technical support with SEEBURGER products, contact 
supp...@seeburger.de or http://servicedesk.seeburger.de

General inquiries can be directed to our info team: i...@seeburger.de

Greetings Bernd Eckenfels
Chief Architect, SEEBURGER AG








SEEBURGER AGVorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:Axel Haas, Michael 
Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the 
SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 
Internet: http://www.seeburger.de   Registergericht/Commercial 
Register:
e-mail: i...@seeburger.de   HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und 
kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. 
Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und 
stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. 
Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und 
jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher 
Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der 
Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer 
Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This 
email may contain confidential material that may be protected by professional 
secrecy. Any fact or opinion contained, or expression of the material herein, 
does not necessarily reflect that of SEEBURGER AG. If you are not the addressee 
or if you have received this email in error, any use, publication or 
distribution including forwarding, copying or printing is strictly prohibited. 
Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for 
viruses; it is your responsibility to check this email and its attachments for 
viruses.



> Dependency on "Commons RNG"
> ---
>
> Key: TEXT-36
> URL: https://issues.apache.org/jira/browse/TEXT-36
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Gilles
>  Labels: api
> Fix For: 1.0
>
>
> This is a follow-up of a 
> [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15762623]
>  held in TEXT-34.
> IMHO, there is no harm in depending on the ["commons-rng-client-api" 
> module|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/javadocs/api-1.0/index.html]
>  of Commons RNG; the "zero dependency" mantra does not hold here, since TEXT 
> already depends on LANG.
> OTOH, I see that it is counter-productive (i.e. it harms the Commons project 
> as a whole) to not advertize or use other Commons components, despite the 
> "own dog food" phrase appearing recurrently on the "dev" ML.
> Rather than having people blindly use {{java.util.Random}}, we should allow 
> them to choose wisely, based on full information.
> IMO, that means to indeed use {{UniformRandomProvider}} in order to raise 
> awareness about alternatives to the sub-optimal algorithm used by the JDK.
> However, if some Commons developers do not trust that the 
> {{UniformRandomProvider}} interface can be stable enough for TEXT, then we 
> should follow Jochen Wiedemann's advice (cf. archive of the "dev" ML) and 
> define TEXT's own interface to random numbers, with bridges to it from 
> {{UniformRandomProvider}} and from {{java.util.Random}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"

2016-12-22 Thread Duncan Jones (JIRA)


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

Duncan Jones commented on TEXT-36:
--

It would be good to hear why people are concerned about a link between TEXT and 
RNG. Is it a fear of Maven jar hell? I.e. TEXT depends upon a specific version 
of RNG, which clashes somehow with the preferred version of the user's code?

If that's the concern, then I don't think Gregory's suggestion saves us 
anything, since we'd have to depend upon RNG to offer the interface.

IMO, the four options I can see in descending order of preference are:

# Eat our own dog food - use RNG as the only visible option. Users can bridge 
to java.util.Random using RNG's bridge classes if they must.
# As above, but explicitly offer overloads with java.util.Random.
# Offer only java.util.Random in the interface, but shade RNG so that our 
internal default implementations are as good as can be.
# Don't use RNG at all.

> Dependency on "Commons RNG"
> ---
>
> Key: TEXT-36
> URL: https://issues.apache.org/jira/browse/TEXT-36
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Gilles
>  Labels: api
> Fix For: 1.0
>
>
> This is a follow-up of a 
> [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15762623]
>  held in TEXT-34.
> IMHO, there is no harm in depending on the ["commons-rng-client-api" 
> module|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/javadocs/api-1.0/index.html]
>  of Commons RNG; the "zero dependency" mantra does not hold here, since TEXT 
> already depends on LANG.
> OTOH, I see that it is counter-productive (i.e. it harms the Commons project 
> as a whole) to not advertize or use other Commons components, despite the 
> "own dog food" phrase appearing recurrently on the "dev" ML.
> Rather than having people blindly use {{java.util.Random}}, we should allow 
> them to choose wisely, based on full information.
> IMO, that means to indeed use {{UniformRandomProvider}} in order to raise 
> awareness about alternatives to the sub-optimal algorithm used by the JDK.
> However, if some Commons developers do not trust that the 
> {{UniformRandomProvider}} interface can be stable enough for TEXT, then we 
> should follow Jochen Wiedemann's advice (cf. archive of the "dev" ML) and 
> define TEXT's own interface to random numbers, with bridges to it from 
> {{UniformRandomProvider}} and from {{java.util.Random}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CSV-205) Add convenience API CSVFormat#printer() to print to System.out

[jira] [Updated] (CSV-205) Add convenience API CSVFormat#printer() to System.out

[jira] [Updated] (CSV-205) Add convenience API CSVFormat#printer() to print to System.out

[jira] [Created] (CSV-205) Add convenience method CSVFormat#printer() to System.out

[jira] [Resolved] (CONFIGURATION-646) autoSave and manual save behave differently

[jira] [Commented] (TEXT-32) We want a wider variety of edit distances/similarity scores.

[jira] [Comment Edited] (TEXT-32) We want a wider variety of edit distances/similarity scores.

[jira] [Comment Edited] (LANG-1302) java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap

[jira] [Resolved] (LANG-1302) java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap

[jira] [Updated] (LANG-1302) java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap

[jira] [Created] (LANG-1302) java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap

[jira] [Comment Edited] (TEXT-36) Dependency on "Commons RNG"

[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"

[jira] [Commented] (TEXT-38) Fluent API in "RandomStringBuilder"

[jira] [Commented] (TEXT-37) Global vs local source of randomness

[jira] [Issue Comment Deleted] (TEXT-36) Dependency on "Commons RNG"

[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"

[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"

18 matches

Site Navigation

Mail list logo

Footer information