Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8265137

java.util.Random suddenly has new public methods nowhere documented

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P3 P3
    • 17
    • 17
    • core-libs
    • openjdk version "17-ea" 2021-09-14
      OpenJDK Runtime Environment (build 17-ea+17-1401)
      OpenJDK 64-Bit Server VM (build 17-ea+17-1401, mixed mode, sharing)

    • b17
    • 17
    • b21
    • generic
    • generic

      while investigating some issues with build 17 of openJDK in combination with the forbiddenapis Maven/Gradle plugin I noticed that starting with JDK 17 b17 java.util.Random now extends some internal class of some jdk.internal package (jdk.internal.util.random.RandomSupport.AbstractSpliteratorGenerator). This is not really great, but shows what the module system can do. Tools owners (like forbiddenapis) have to work around that until full module system support is there.

      But the extension of class jdk.internal.util.random.RandomSupport.AbstractSpliteratorGenerator brings some other problems: As the class is in another package, it implements some public methods (with some intro comment "Required by AbstractSpliteratorGenerator" - so implementor knows that's something strange): https://github.com/openjdk/jdk/blob/a0ec2cb289463969509fe508836e3faf789f46d8/src/java.base/share/classes/java/util/Random.java#L618-L626

      Those methods are marked by the Javadoc tag @hidden. So they are nowhere documented and are implementation details. But those methods are still visible as public methods and also shown by IDE tools during autocomplete!

      The following code compiles!!!:

      import java.util.Random;

      public class RandomTest {
        public static void main(String... args) {
          new Random().makeLongsSpliterator(0L, 10L, 1L, 5L);
        }
      }

      This should not be possible, as makeLongsSpliterator is nowhere documented, so code may accidentally use it.

      I have not looked at the other implementations like SecureRandom and others, but I suspect they have the same problem.

      IMHO, the code should not extend this internal abstract class and instead use a private implementation of the the abstract class and just delegate to it. It should also declare "implements RandomGenerator" directly. Reading the code is too confusing!

      The current class design with extending classes hidden in other modules and implementing partially hiden methods is not a good thing, so please fix this!

            jlaskey Jim Laskey
            uschindler Uwe Schindler
            Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: