[
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)
