archive/jdk
1
0
Fork 0
mirror of https://github.com/openjdk/jdk.git synced 2025-09-19 10:34:38 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

8220730: sun.security.provider.SecureRandom default constructor has wrong documentation

Browse source 
Reviewed-by: weijun
This commit is contained in:
Bradford Wetmore 2020-11-26 18:47:38 +00:00
parent 4e43b28858
commit 62d72dec5e
1 changed files with 16 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

27
src/java.base/share/classes/sun/security/provider/SecureRandom.java
View file

@ -1,5 +1,5 @@
/* /*
* Copyright (c) 1998, 2019, Oracle and/or its affiliates. All rights reserved. * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
* *
* This code is free software; you can redistribute it and/or modify it * This code is free software; you can redistribute it and/or modify it
@ -65,16 +65,21 @@ implements java.io.Serializable {
private int remCount; private int remCount;
/** /**
* This empty constructor automatically seeds the generator. We attempt * An empty constructor that creates an unseeded SecureRandom object.
* to provide sufficient seed bytes to completely randomize the internal * <p>
* state of the generator (20 bytes). Note, however, that our seed * Unless the user calls setSeed(), the first call to engineGetBytes()
* generation algorithm has not been thoroughly studied or widely deployed. * will have the SeedGenerator provide sufficient seed bytes to
* * completely randomize the internal state of the generator (20 bytes).
* <p>The first time this constructor is called in a given Virtual Machine, * Note that the old threaded seed generation algorithm is provided
* it may take several seconds of CPU time to seed the generator, depending * only as a fallback, and has not been thoroughly studied or widely
* on the underlying hardware. Successive calls run quickly because they * deployed.
* rely on the same (internal) pseudo-random number generator for their * <p>
* seed bits. * The SeedGenerator relies on a VM-wide entropy pool to generate
* seed bytes for these objects. The first time the SeedGenerator is
* called, it may take several seconds of CPU time to initialize,
* depending on the underlying hardware. Successive calls run
* quickly because they rely on the same (internal) pseudo-random
* number generator for their seed bits.
*/ */
public SecureRandom() { public SecureRandom() {
init(null); init(null);