You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Alex Herbert (Jira)" <ji...@apache.org> on 2026/08/22 11:48:00 UTC
[jira] [Resolved] (RNG-197) JDKRandomWrapper reimplements default methods from UniformRandomProvider
[ https://issues.apache.org/jira/browse/RNG-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Herbert resolved RNG-197.
------------------------------
Assignee: Alex Herbert
Resolution: Implemented
Method not in Random removed in commit:
6c75e8bcb0cd058ee5cac37145e6286248bfad5b
> JDKRandomWrapper reimplements default methods from UniformRandomProvider
> ------------------------------------------------------------------------
>
> Key: RNG-197
> URL: https://issues.apache.org/jira/browse/RNG-197
> Project: Commons RNG
> Issue Type: Task
> Components: simple
> Affects Versions: 1.7
> Reporter: Alex Herbert
> Assignee: Alex Herbert
> Priority: Trivial
> Fix For: 1.8
>
>
> The JDKRandomWrapper implements the methods from UniformRandomProvider using an instance of java.util.Random (e.g. SecureRandom). Some methods defined in UniformRandomProvider are not present in Random. These have implementations in JDKRandomWrapper that are copied from the base implementation of UniformRandomProvider. However those methods are now default methods in the interface. The implementations are thus duplicated in JDKRandomWrapper.
> The JDKRandomWrapper methods can be removed. All methods not defined in Random now use the default implementation from UniformRandomProvider with Random.nextLong() as the source of randomness. This change simplifies the code base by removing duplication.
> Note: Removal of the methods from JDKRandomWrapper cause the binary compatibility plugin JApiCmp to fail. It does not recognise the removed method is now provided by the interface in a different package. JApiCmp must be disabled for the 1.8 release in the simple module. The build also uses revapi to check binary compatibility and this plugin detects the change as compatible. This is similar to the change to remove default implementations from o.a.c.rng.core.BaseProvider in release 1.5 (see RNG-176).
> Issue identified by a security scan that noted a lack of parameter validation in nextBytes(byte[] bytes, int start, int length) before allocation of a temporary byte[] array.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)