hg: jdk8/tl/jdk: 8005118: Javadoc styles are inconsistent

2013-01-02 Thread stuart . marks
Changeset: cc78ceb99284
Author:jgish
Date:  2012-12-28 16:56 -0500
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc78ceb99284

8005118: Javadoc styles are inconsistent
Summary: use a common javadoc style in the String classes
Reviewed-by: darcy

! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/String.java
! src/share/classes/java/lang/StringBuffer.java
! src/share/classes/java/lang/StringBuilder.java
! src/share/classes/java/lang/StringIndexOutOfBoundsException.java



JEP 123: SecureRandom First Draft and Implementation.

2013-01-02 Thread Brad Wetmore


Hi,

Please review the API/impl for JEP 123:

http://openjdk.java.net/jeps/123
http://cr.openjdk.java.net/~wetmore/6425477/webrev.00/

Oracle folks, there is also the internal CCC that needs review.  The bug 
id is 6425477.


There are several SecureRandom implementations in Oracle's JDK, and 
together with the configuration options in the java.security file, it 
can be very confusing for users to understand. As part of the work on 
JEP 123, I took a comprehensive look at the different SecureRandom 
implementations and how we got here.


There are these implementations:

PKCS11:
Direct calls to the native PKCS11 library.  Only enabled
by default on Solaris, but available for any OS.  No difference
between seed/random.

NativePRNG:
uses /dev/random and /dev/urandom for seeds/random numbers
respectively.  Doesn't exist on Windows.

SHA1PRNG:
Available on all platforms.  By default, uses a confusing mix of
/dev/[u]random for internal seeding and external seed
generation, along with a SHA1 MessageDigest for
generating random numbers.  The properties (below) control
seeding, but in a confusing manner.

Windows-PRNG:
Direct calls to the MSCAPI library, only available for Windows.
No difference between seed/random.

There were two main points for this JEP:

1.  Provide an API that allows applications to indicate whether they 
want the strongest-possible (possibly blocking) values, or if just 
regular values will do.


2.  See if we can clarify the configuration model, and eliminate some of 
the confusion caused by the securerandom.source/java.security.egd variables.


This second point has caused a lot of pain for 
developers/deployers/support.  The workaround of specifying 
file:/dev/./urandom or file:///dev/urandom instead of 
file:/dev/urandom has to be one of the most unintuitive ever.  [1]  ;)


The default value of the variable is changed to file:/dev/random to 
reflect the actual implementation we've been shipping since JDK 5, but 
will also install NativePRNG as more preferred over the SHA1PRNG. 
Otherwise, the part of the implementation stays the same, and is now 
better documented in the java.security file.


We'll also be updating the Oracle Provider documentation to reflect the 
implementations, but that work will be done later.


Thanks,

Brad

[1] https://forums.oracle.com/forums/thread.jspa?messageID=3793101