Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2]

[Bradford Wetmore]

On Tue, 24 May 2022 16:20:10 GMT, Mark Powers  wrote:

> Mach5 tier1 and tier2 completed without any failures. I don't know what to 
> make of the pre-submit failures - lang and hotspot?

IIUC, these are due to Loom failures in some of the other platforms supported 
by OpenJDK but not by Oracle.  They are being resolved.

-

PR: https://git.openjdk.java.net/jdk/pull/8559

Re: RFR: 8284209: Replace remaining usages of 'a the' in source code

[Bradford Wetmore]

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: 
> a/the, an?/an?, the/the…
> 
> It's the last issue in the series, and it still touches different areas of 
> the code.

Looked at 

-java.security.jgss.

LGTM

-

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

Re: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base

[Bradford Wetmore]

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: 
> a/the, an?/an?, the/the…
> 
> Also, I fixed a couple of spelling mistakes.

Looked at 

- java.base/.../sun/security
- jdk.crypto.*
- test/*/com/sun/crypto/provider
- test/*/java/lang/SecurityManager
- test/*/java/security
- test/*/krb5
- test/*/jarsigner

and those look fine.

-

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults

[Bradford Wetmore]

On Thu, 5 May 2022 16:49:07 GMT, Mark Powers  wrote:

> JDK-6725221 Standardize obtaining boolean properties with defaults

Sorry for the confusion.

The original intent of this bug 14 years ago was to standardize the seclibs 
code where simple getProperty calls were needed in the context of an 
AccessController, without having to provide the doProvided calls. i.e. 
GetBooleanAction.privilegedGetProperty(). This was not intended not other parts 
of the JDK.

For example: ChannelImpl.java provides a getBooleanProperty() method, which is 
very similar to GetBooleanAction. I noticed other places in the security where 
this was being done.

Some of the classes like Debug have been rewritten (SSLLogger), so the issue 
does not appear to exist there any logger.

The certpath code is working with Security.getProperty(), so that was a red 
herring.

-

PR: https://git.openjdk.java.net/jdk/pull/8559

Re: RFR: 8285890: Fix some @param tags

[Bradford Wetmore]

On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo  wrote:

> * Syntactically improves a few cases from 8285676 
> (https://github.com/openjdk/jdk/pull/8410)
> * Fixes a few misspelled `@param` tags for elements that, although are not 
> included in the API Documentation, are visible in and processed by IDEs

LGTM also.

-

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8465

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

[Bradford Wetmore]

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy  wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please 
> review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated 
> out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the 
> doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

The two `java.security` ones LGTM.

-

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8410

Re: RFR: 8284893: Fix typos in java.base

[Bradford Wetmore]

On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie  wrote:

> I ran `codespell` on the `src/java.base` directory, and accepted those 
> changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> The majority of fixes are in comments. A handful is in strings, one in a 
> local variable name, and a couple in parameter declarations.
> 
> Annoyingly, there are several instances of "childs" (instead of "children") 
> in the source code, but they were not local and I dared not change them. 
> Someone braver than me might take a stab at it, perhaps..

I checked over:

java.base/macosx/classes/apple/security
java.base/share/classes/com/sun/crypto
java.base/share/classes/com/sun/security
java.base/share/classes/java/security
java.base/share/classes/javax/crypto
java.base/share/classes/javax/net
java.base/share/classes/sun/security

The copyright dates need updating.

src/java.base/share/classes/sun/security/provider/certpath/AdjacencyList.java 
line 128:

> 126: // Each time this method is called, we're examining a new list
> 127: // from the global list. So, we have to start by getting the list
> 128: // that contains the set of Vertices we're considering.

The class being affected is a Vertex, so either change to vertices, or leave as 
is...

-

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8250

Re: RFR: 8186958: Need method to create pre-sized HashMap [v21]

[Bradford Wetmore]

On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess  wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   add `@LastModified: Apr 2022` to DocumentCache

I learned something new about HashMap today...

I looked at java.security.cert and sun.security.* and that part LGTM.

That said, you need to check with @seanjmullan for the java.xml.crypto code.  
We try to keep the code in sync with the Apache code.  As this is a new API, we 
probably can't push this kind of change to Apache as they need to support older 
releases.

src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java
 line 110:

> 108: int length = attributes.getLength();
> 109: Map namespaceMap =
> 110: HashMap.newHashMap(length);

Please check these changes with @seanjmullan before integrating.

-

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7928

Re: RFR: 8284567: Collapse identical catch branches in java.base

[Bradford Wetmore]

On Sat, 2 Apr 2022 16:05:06 GMT, Andrey Turbanov  wrote:

> Let's take advantage of Java 7 language feature - "Catching Multiple 
> Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' 
> statement

LGTM

-

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8081

Re: RFR: 8284567: Collapse identical catch branches in java.base

[Bradford Wetmore]

On Sat, 2 Apr 2022 16:05:06 GMT, Andrey Turbanov  wrote:

> Let's take advantage of Java 7 language feature - "Catching Multiple 
> Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' 
> statement

src/java.base/share/classes/java/net/URI.java line 47:

> 45: import sun.nio.cs.UTF_8;
> 46: 
> 47: import java.lang.Character; // for javadoc

Looks like the javadoc comment no longer applies, so should be ok to remove.

-

PR: https://git.openjdk.java.net/jdk/pull/8081

Re: RFR: 8283426: Fix 'exeption' typo

[Bradford Wetmore]

On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov  wrote:

> Fix repeated typo `exeption`

Good grief!  I wouldn't have expected it to be so widespread.  

Thanks for noticing and fixing.

-

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7879

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

[Bradford Wetmore]

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan  wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

LGTM also.  

Similar suggestion for updating copyrights.

-

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

Re: Integrated: 8268146: fix for JDK-8266254 fails validate-source

[Bradford Wetmore]

On Wed, 2 Jun 2021 21:39:15 GMT, Daniel D. Daugherty  wrote:

> A trivial copyright fix.

LGTM

-

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4323

Integrated: 8263105: security-libs doclint cleanup

[Bradford Wetmore]

On Sat, 6 Mar 2021 07:31:09 GMT, Bradford Wetmore  wrote:

> Fix various things pointed out by the most recent doclint run in the 
> security-libs area.
> 
> This is docs only:  I will be checking doccheck/doclint, and will be running 
> tier1/tier2 tests.  Minor spot checks on generated files.

This pull request has now been integrated.

Changeset: 32cbd193
Author:Bradford Wetmore 
URL:   https://git.openjdk.java.net/jdk/commit/32cbd193
Stats: 302 lines in 35 files changed: 223 ins; 8 del; 71 mod

8263105: security-libs doclint cleanup

Reviewed-by: iris, darcy, dfuchs, mullan

-

PR: https://git.openjdk.java.net/jdk/pull/2856

Re: RFR: 8263105: security-libs doclint cleanup [v4]

[Bradford Wetmore]

On Mon, 8 Mar 2021 19:50:06 GMT, Bradford Wetmore  wrote:

>> src/java.base/share/classes/java/security/BasicPermission.java line 497:
>> 
>>> 495: /**
>>> 496:  * @serialData Default fields.
>>> 497:  */
>> 
>> FWIW, this doc comment will be ignored, because it will be superseded by the 
>> new comment on line 499.  At some point doen the road, you may get a warning 
>> from javac about an ignored doc comment.
>
> Ok

Removed after received similar later comments.

-

PR: https://git.openjdk.java.net/jdk/pull/2856

Re: RFR: 8263105: security-libs doclint cleanup [v4]

[Bradford Wetmore]

> Fix various things pointed out by the most recent doclint run in the 
> security-libs area.
> 
> This is docs only:  I will be checking doccheck/doclint, and will be running 
> tier1/tier2 tests.  Minor spot checks on generated files.

Bradford Wetmore has updated the pull request incrementally with one additional 
commit since the last revision:

  Final codereview comments

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2856/files
  - new: https://git.openjdk.java.net/jdk/pull/2856/files/ed0cf2ba..edac22b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2856=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2856=02-03

  Stats: 15 lines in 6 files changed: 2 ins; 8 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856

PR: https://git.openjdk.java.net/jdk/pull/2856

Re: RFR: 8263105: security-libs doclint cleanup [v3]

[Bradford Wetmore]

On Wed, 10 Mar 2021 19:02:40 GMT, Sean Mullan  wrote:

>> Bradford Wetmore has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   More Codereview Comments
>
> src/java.base/share/classes/java/security/PrivilegedActionException.java line 
> 101:
> 
>> 99:  * Serializable fields for UndeclaredThrowableException.
>> 100:  *
>> 101:  * @serialField exception Exception the undeclaredThrowable
> 
> The "undeclaredThrowable" is confusing and not defined anywhere in this class 
> specification. Suggest changing this to: 
> 
> The exception thrown by the privileged computation that resulted in this 
> {@code PrivilegedActionException}.

Sure, good idea.  Thanks.

> src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyImpl.java
>  line 183:
> 
>> 181:  * @serialData this {@code KeyImpl} is serialized by
>> 182:  * writing out the ASN1 Encoded bytes of the encryption key.
>> 183:  * The ASN1 encoding is defined in RFC4120 and as  follows:
> 
> Nit: s/ASN1/ASN.1 (also on line 182).

Corrected.

> src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyImpl.java
>  line 183:
> 
>> 181:  * @serialData this {@code KeyImpl} is serialized by
>> 182:  * writing out the ASN1 Encoded bytes of the encryption key.
>> 183:  * The ASN1 encoding is defined in RFC4120 and as  follows:
> 
> Remove "and" and extra space after "as"

Done.

-

PR: https://git.openjdk.java.net/jdk/pull/2856

Re: RFR: 8263105: security-libs doclint cleanup [v2]

[Bradford Wetmore]

On Wed, 10 Mar 2021 15:10:35 GMT, Roger Riggs  wrote:

>> Bradford Wetmore has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Codereview Comment
>
> src/java.base/share/classes/javax/crypto/SealedObject.java line 425:
> 
>> 423:  * Restores the state of the SealedObject from a stream.
>> 424:  *
>> 425:  * @param s the object input stream.
> 
> Covert to @\throws but keep this declaration.  There is no spec that 
> otherwise covers this and it is consistent with other methods.

Ok, I'll keep the NullPointerException and change to @throws, although I don't 
think it's used in many methods.

-

PR: https://git.openjdk.java.net/jdk/pull/2856

Re: RFR: 8263105: security-libs doclint cleanup [v3]

[Bradford Wetmore]

On Wed, 10 Mar 2021 14:53:53 GMT, Roger Riggs  wrote:

>> Bradford Wetmore has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   More Codereview Comments
>
> src/java.base/share/classes/java/security/AllPermission.java line 165:
> 
>> 163: 
>> 164: /**
>> 165:  * true if any AllPermissions have been added
> 
> Please capitalize to make it a  sentence, and end in ".".

Done.

> src/java.base/share/classes/java/security/BasicPermission.java line 526:
> 
>> 524: 
>> 525: /**
>> 526:  * readObject is called to restore the state of the
> 
> Ditto, capitalize.

It's the name of the method and the style is used in other packages.  Leaving 
as is.

> src/java.base/share/classes/java/security/Permissions.java line 579:
> 
>> 577: };
>> 578: 
>> 579: /*
> 
> The @ serialData comment can be removed entirely. It is unused due to the 
> "@serial exclude" above.

Ok.

> src/java.base/share/classes/java/security/UnresolvedPermissionCollection.java 
> line 158:
> 
>> 156: 
>> 157: /*
>> 158:  * @serialData Default field.
> 
> the comment block containing @\serialdata can be omitted entirely.

ok

-

PR: https://git.openjdk.java.net/jdk/pull/2856

Re: RFR: 8263105: security-libs doclint cleanup [v3]

[Bradford Wetmore]

> Fix various things pointed out by the most recent doclint run in the 
> security-libs area.
> 
> This is docs only:  I will be checking doccheck/doclint, and will be running 
> tier1/tier2 tests.  Minor spot checks on generated files.

Bradford Wetmore has updated the pull request incrementally with one additional 
commit since the last revision:

  More Codereview Comments

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2856/files
  - new: https://git.openjdk.java.net/jdk/pull/2856/files/1fa29ea6..ed0cf2ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2856=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2856=01-02

  Stats: 52 lines in 8 files changed: 0 ins; 42 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856

PR: https://git.openjdk.java.net/jdk/pull/2856

Re: RFR: 8263105: security-libs doclint cleanup [v2]

[Bradford Wetmore]

On Tue, 9 Mar 2021 16:10:11 GMT, Sean Mullan  wrote:

>> Bradford Wetmore has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Codereview Comment
>
> src/java.base/share/classes/javax/crypto/SealedObject.java line 428:
> 
>> 426:  * @throws IOException if an I/O error occurs
>> 427:  * @throws ClassNotFoundException if a serialized class cannot be 
>> loaded
>> 428:  * @throws NullPointerException if s is null.
> 
> Remove period for consistency with other throws. Actually, you probably don't 
> need to say that it throws NPE. I don't see that any other readObject method 
> declares that, even if they do throw NPE if the stream is null. Seems like 
> something that should just be assumed or does not happen under normal 
> circumstances.

It did seem really strange to me.  I'll remove.

-

PR: https://git.openjdk.java.net/jdk/pull/2856

Re: RFR: 8263105: security-libs doclint cleanup [v2]

[Bradford Wetmore]

> Fix various things pointed out by the most recent doclint run in the 
> security-libs area.
> 
> This is docs only:  I will be checking doccheck/doclint, and will be running 
> tier1/tier2 tests.  Minor spot checks on generated files.

Bradford Wetmore has updated the pull request incrementally with one additional 
commit since the last revision:

  Codereview Comment

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2856/files
  - new: https://git.openjdk.java.net/jdk/pull/2856/files/f2253d91..1fa29ea6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2856=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2856=00-01

  Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856

PR: https://git.openjdk.java.net/jdk/pull/2856

Re: RFR: 8263105: security-libs doclint cleanup

[Bradford Wetmore]

On Sat, 6 Mar 2021 19:20:39 GMT, Jonathan Gibbons  wrote:

>> Fix various things pointed out by the most recent doclint run in the 
>> security-libs area.
>> 
>> This is docs only:  I will be checking doccheck/doclint, and will be running 
>> tier1/tier2 tests.  Minor spot checks on generated files.
>
> src/java.base/share/classes/java/security/BasicPermission.java line 497:
> 
>> 495: /**
>> 496:  * @serialData Default fields.
>> 497:  */
> 
> FWIW, this doc comment will be ignored, because it will be superseded by the 
> new comment on line 499.  At some point doen the road, you may get a warning 
> from javac about an ignored doc comment.

Ok

> src/java.base/share/classes/java/security/GuardedObject.java line 64:
> 
>> 62: 
>> 63: /**
>> 64:  * The guard object
> 
> add a period?

Probably worth doing as it's the first sentence.

> src/java.base/share/classes/java/security/PermissionCollection.java line 105:
> 
>> 103:  * Whether this permission collection is read-only.
>> 104:  * 
>> 105:  * If set, add() will throw an exception.
> 
> maybe use `{@code}` or `{@link}` on add?

Done.

> src/java.base/share/classes/java/security/Permissions.java line 581:
> 
>> 579: /**
>> 580:  * @serialData Default fields.
>> 581:  */
> 
> Another ignored comment. I suggest just changing these to `/*` comments.

Good idea.  Done.

-

PR: https://git.openjdk.java.net/jdk/pull/2856

RFR: 8263105: security-libs doclint cleanup

[Bradford Wetmore]

Fix various things pointed out by the most recent doclint run in the 
security-libs area.

This is docs only:  I will be checking doccheck/doclint, and will be running 
tier1/tier2 tests.  Minor spot checks on generated files.

-

Commit messages:
 - Final First Draft
 - Only 100 warnings output by default
 - 8263105: security-libs doclint cleanup

Changes: https://git.openjdk.java.net/jdk/pull/2856/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2856=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263105
  Stats: 351 lines in 39 files changed: 270 ins; 2 del; 79 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856

PR: https://git.openjdk.java.net/jdk/pull/2856

Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

[Bradford Wetmore]

On Fri, 11 Sep 2020 07:15:26 GMT, Dmitriy Dumanskiy 
 wrote:

>> 1) This is un-necessary churn.
>> 2) I can't even be sure I am finding the ones in my area because there's so 
>> much here
>> 3) The ones I can find have no need of whatever performance improvement this 
>> might bring.
>> I think this whole PR should be withdrawn, and there may an attempt at 
>> measuring the benefits of this for the various
>> cases before submitting in appropriate smaller chunks. But I'll tell you now 
>> I don't see a need for the test updates
>> you are making.
>
> Ok, sorry for the distraction.

Our local Santuario maintainer says:

In general, changes to Apache Santuario should also be made at Apache so we 
stay in sync.

-

PR: https://git.openjdk.java.net/jdk/pull/29

Re: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike

[Bradford Wetmore]

I checked the last 6 only (SSLEngine+).  Looks good.

Brad


On 10/1/2018 4:37 PM, Ivan Gerasimov wrote:

Hello!

A handful of a few similar typos across core-libs/security-libs areas.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381
WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/

Would you please help review the fix?

Review Request: JDK-8170633 backslashes in, gensrc/module-info.java comments need escaping

[Bradford Wetmore]

> The build tool generating module-info.java includes the path name of
> the source files in the comment for diagnosis where backslash
> character needs escaping.  This patch prints URI rather than file
> path.

As submitter and having tested the build patch, looks good to me.

Brad

Re: RFR(XXS): 8140514: [TESTBUG] enable sun/security/pkcs11 tests on Linux/ppc64

[Bradford Wetmore]

Most of us have been at JavaOne this week.

Looks ok to me.

Brad



On 10/27/2015 11:02 AM, Volker Simonis wrote:

Resend to core-libs-dev to attract a broader audience :)

On Mon, Oct 26, 2015 at 3:32 PM, Volker Simonis
 wrote:

Hi,

can somebody please review the following trivial fix to enable the
pkcs11 tests for linux/ppc64:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8140514/
https://bugs.openjdk.java.net/browse/JDK-8140514

The pkcs11 tests need to load the native library libnss3.so the
location of which is system dependent. Until now, the test didn't
consider Linux/ppc64 systems.

The fix is simple: just add a corresponding map entry which maps the
platform to the correct library path. All the systems I've checked
(various Fedora, OpenSUSE, SLES and RHEL distros) have libnss3.so
under /usr/lib64.

Thank you and best regards,
Volker

Re: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors

[Bradford Wetmore]

I only looked at test, looks good to me.

I'd rarely ask to remove extra prints in tests.  It adds initial 
debugging data points in case something breaks down the road.


Brad


On 1/4/2015 8:25 AM, Peter Levart wrote:

Hi Brad,

So I created another webrev (just removed the unneeded import and
left-over System.out.println from test):

http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.06/

I'll leave it here to rest for a couple of days and if no one objects,
I'll push it to jdk9-dev.

Thanks everybody for reviews and happy new year!

Regards, Peter

On 01/02/2015 11:58 PM, Bradford Wetmore wrote:


On 1/1/2015 12:22 PM, Peter Levart wrote:

Hi Brad,

Here's next webrev which tries to cover all your comments:

http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.04/



I downloaded the webrev.05 (Chris' later followup email) and ran it
through JPRT.  The only error was the previously seen -Dseed which is
not your problem.

Again, I only ran:

jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio,
jdk_security*, jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools.

If you need anything else run, let me know.


Looks like you have a committer status, will you be pushing this?


I can, yes. As soon as we clear-out the remaining questions, right?


Yes.  The comments below are minor and shouldn't need another review
cycle.


I'm worried about the failure of the test you observed while running
from NetBeans. Perhaps a 0.5s wait is sometimes not enough for
ReferenceHandler thread to process (enqueue) a WeakReference. Since
there is already a facility in place to help ReferenceHandler thread
instead of wait for it, I used it in new version of the test.


BTW, there's now an unnecessary import from java.lang.AssertionError
added in webrev.04.


TEST RESULT: Failed. Compilation failed: Compilation failed


I changed the test to be self-contained now so one can run it without
testlib in classpath.


Thanks.  It's compiling fine now.


Two minor nits?   SeedGenerator.java:  Lines 507/518


Done that too.


Thanks.


Maybe issue multiple reads to exercise in1 and in2?  e.g. 2 bytes of
in1, 4 bytes of in2, then 2 bytes of in1?


The 1st assert makes sure in1 == in2, so there's no point in invoking
the same instance via two aliases.


True.


IIRC, when I ran this under NetBeans last week, the second testCaching
didn't clear the WeakReference.


This should not happen any more now that the test is helping to enqueue
the WeakReferences instead of waiting for ReferenceHandler to enqueue
them.


Yes, that hit the refQueue.poll().

It's always interesting to work with core-libs folks, learn something
new everyday.  Mixing Lambdas/try-with.

I need a time-machine for your CFV/jdk8 Committer:

http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-August/002896.html

I vote yes.


The test can now fail only if System.gc() does not trigger
WeakReference processing in the VM. Can you give it a try on your
NetBeans environment?


One last comment.  It's now 2015.  ;)

Brad

Re: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors

[Bradford Wetmore]

On 1/1/2015 12:22 PM, Peter Levart wrote:

Hi Brad,

Here's next webrev which tries to cover all your comments:

http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.04/


I downloaded the webrev.05 (Chris' later followup email) and ran it 
through JPRT.  The only error was the previously seen -Dseed which is 
not your problem.


Again, I only ran:

jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio,
jdk_security*, jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools.

If you need anything else run, let me know.


Looks like you have a committer status, will you be pushing this?


I can, yes. As soon as we clear-out the remaining questions, right?


Yes.  The comments below are minor and shouldn't need another review
cycle.


I'm worried about the failure of the test you observed while running
from NetBeans. Perhaps a 0.5s wait is sometimes not enough for
ReferenceHandler thread to process (enqueue) a WeakReference. Since
there is already a facility in place to help ReferenceHandler thread
instead of wait for it, I used it in new version of the test.


BTW, there's now an unnecessary import from java.lang.AssertionError 
added in webrev.04.



TEST RESULT: Failed. Compilation failed: Compilation failed


I changed the test to be self-contained now so one can run it without
testlib in classpath.


Thanks.  It's compiling fine now.


Two minor nits?   SeedGenerator.java:  Lines 507/518


Done that too.


Thanks.


Maybe issue multiple reads to exercise in1 and in2?  e.g. 2 bytes of
in1, 4 bytes of in2, then 2 bytes of in1?


The 1st assert makes sure in1 == in2, so there's no point in invoking
the same instance via two aliases.


True.


IIRC, when I ran this under NetBeans last week, the second testCaching
didn't clear the WeakReference.


This should not happen any more now that the test is helping to enqueue
the WeakReferences instead of waiting for ReferenceHandler to enqueue
them.


Yes, that hit the refQueue.poll().

It's always interesting to work with core-libs folks, learn something 
new everyday.  Mixing Lambdas/try-with.


I need a time-machine for your CFV/jdk8 Committer:

http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-August/002896.html

I vote yes.


The test can now fail only if System.gc() does not trigger
WeakReference processing in the VM. Can you give it a try on your
NetBeans environment?


One last comment.  It's now 2015.  ;)

Brad

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

[Bradford Wetmore]

the Microsoft C Runtime Library makes use of this function in its
implementation of rand_s, so it's removal would break a lot of
programs. I think this is a relative guarantee that the function is here
to stay.


Ok.


What are the fallbacks for SystemRandomImpl if /dev/urandom or the
rtlGenRandomFN/CryptGenRandom aren't available?  Is that something
you'll bake into TLR or will you do it here?



I think it's better to leave it to consumers (TLR/SplittableRandom) as
they know what's good-enough for them. The API allows for arbitrary
number of bytes to be generated and I don't have an easy means of
generating more than 8 random bytes just from System.nanoTime() and
System.currentTimeMillis() short of using SecureRandom as a fall-back.


webrev.03 only has new code, no changes yet to TLR/SplittableRandom,
so I'm not yet quite following where TLR/SR will be changing.  Also,
what is proposed for platforms that aren't Unix/Windows?  Should there
be a generic fallback mechanism like ThreadedSeedGenerator?  (Note,
I'm not suggesting using it, it's rather...SSLLLOOO...)


Are there other non-Unix and non-Windows platforms?


I'm not an expert in non-Oracle Java offerings, but what about the 
various Java ME devices?  Some of the embedded devices are 
Linux/Windows, but are there others?  JavaCard?


I know IBM has a large number of OS's they support, for example IBM i.

http://en.wikipedia.org/wiki/IBM_i
https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/IBM%20i%20Technology%20Updates/page/Java%20on%20IBM%20i

I know IBM supports Java on z/OS, but apparently that uses a Linux-style 
filesystem via UNIX_System_Services. http://en.wikipedia.org/?title=Z/OS


Not sure about others.

I saw a couple of other non-unix/windows OSs in a wikipedia comparison 
of JVM's, but most of them seem to be discontinued.



I think the planned
fall-back for TLR/SplittableRandom is to just use
System.currentTimeMillis()  System.nanoTime() - these are the defaults
now unless SecureRandom is requested.


Ok.  Since this isn't security-critical, IMHO there just needs to be a 
reasonable fall-back option in case /dev/urandom or rtlGenRandomFN 
can't be used.


I don't always closely monitor core-libs-dev, so please cc me if further 
discussion occurs in a different thread.


Cheers, and HNY to you and everyone else here,

Brad

Re: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors

[Bradford Wetmore]

Just to followup, I've analyzed the whole PIT run.  The second one's 
call stack is identical to:


JDK-8067344: Adjust 
java/lang/invoke/LFCaching/LFGarbageCollectedTest.java for recent 
changes in java.lang.invoke


So, really the only problem is the use of Asserts in your test case.

Brad


Looks like you have a committer status, will you be pushing this?


I can, yes. As soon as we clear-out the remaining questions, right?


Yes.  The comments below are minor and shouldn't need another review
cycle.  I have started a JPRT job for you, I'll run it through core
target which will give us:

jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio, jdk_security*,
jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools.

Anything else?  I'm off tomorrow, I should have full results Wed.

Here are the preliminary results for the jobs that have finished.
jdk.testlibrary.Asserts is causing compilation errors, additional
comments below:

/opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:33:
error: package jdk.testlibrary does not exist
import static jdk.testlibrary.Asserts.*;
  ^
/opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:52:
error: cannot find symbol
 assertEquals(bytes.length, nread, short read);
 ^
   symbol:   method assertEquals(int,int,String)
   location: class FileInputStreamPoolTest
/opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:53:
error: cannot find symbol
 assertTrue(Arrays.equals(readBytes, bytes),
 ^
   symbol:   method assertTrue(boolean,String)
   location: class FileInputStreamPoolTest
3 errors

TEST RESULT: Failed. Compilation failed: Compilation failed

I'm also getting failures in the following test.  I unfortunately have
to leave now, so don't have time to look at this.  But it did mention
seed so I'm mentioning it here.

TEST: java/lang/invoke/LFCaching/LFGarbageCollectedTest.java

ACTION: main -- Failed. Execution failed: `main' threw exception:
java.lang.Error: 36 of 39 test cases FAILED! Rerun the test with the
same -Dseed= option as in the log file!
REASON: User specified action: run main/othervm LFGarbageCollectedTest
TIME:   213.406 seconds
messages:
command: main LFGarbageCollectedTest
reason: User specified action: run main/othervm LFGarbageCollectedTest
elapsed time (seconds): 213.406
STDOUT:
-Dseed=6102311124531075592
-DtestLimit=2000
Number of iterations according to -DtestLimit is 153 (1989 cases)
Code cache size is 251658240 bytes
Non-profiled code cache size is 123058253 bytes
Number of iterations limited by code cache size is 84 (1092 cases)
Number of iterations limited by non-profiled code cache size is 41 (533
cases)
Number of iterations is set to 41 (533 cases)
Not enough time to continue execution. Interrupted.
STDERR:
Iteration 0:
Tested LF caching feature with MethodHandles.foldArguments method.
java.lang.AssertionError: Error: Lambda form is not garbage collected
 at LFGarbageCollectedTest.doTest(LFGarbageCollectedTest.java:81)
 at
LambdaFormTestCase$TestRun.doIteration(LambdaFormTestCase.java:139)
 at LambdaFormTestCase$$Lambda$2/5042013.call(Unknown Source)
 at
jdk.testlibrary.TimeLimitedRunner.call(TimeLimitedRunner.java:71)
 at LambdaFormTestCase.runTests(LambdaFormTestCase.java:201)
 at LFGarbageCollectedTest.main(LFGarbageCollectedTest.java:105)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

[Bradford Wetmore]

To the actual proposal:

http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.03/

Overall, I'm ok with what's proposed.  This is more straightforward to
parse/understand than trying to adjust NativeSeedGenerator to
create/call directly (e.g. UNIX:  new
NativeSeedGenerator(/dev/urandom) or Windows:  new
NativeSeedGenerator()).  But I'd still like to understand why you
moved away from this.

One concern is that you're duplicating native libraries in java.base,
and it would be the third JDK library overall with this type of call.
There's one in libjava (for java.base/WinCAPISeedGenerator for
sun.security.provider.NativeSeedGenerator) and sunmscapi (for
jdk.crypto.mscapi/SunMSCAPI/sun.security.mscapi).  Would it work to
tweak the WinCAPISeedGenerator so you don't have to create a new dll
for java.base?


The SystemRandom JNI bindings for Windows are located in:

 java.base/windows/native/libjava/SystemRandomImpl_md.c

...so as I understand they are also part of libjava. No new DLL here.


True.  My thought should have been about having very similar code 
duplicated in libjava.


I'm ok with this, though it's not really clear if/when MS will drop 
support for ADVAPI32!RtlGenRandom.  This always makes me nervous because 
whatever is put in will likely never change until some MS change breaks it.


I'm not familiar with what Alan/Mandy/company have in mind down the 
road, but I haven't heard of libjava splitting.



What are the fallbacks for SystemRandomImpl if /dev/urandom or the
rtlGenRandomFN/CryptGenRandom aren't available?  Is that something
you'll bake into TLR or will you do it here?



I think it's better to leave it to consumers (TLR/SplittableRandom) as
they know what's good-enough for them. The API allows for arbitrary
number of bytes to be generated and I don't have an easy means of
generating more than 8 random bytes just from System.nanoTime() and
System.currentTimeMillis() short of using SecureRandom as a fall-back.


webrev.03 only has new code, no changes yet to TLR/SplittableRandom, so 
I'm not yet quite following where TLR/SR will be changing.  Also, what 
is proposed for platforms that aren't Unix/Windows?  Should there be a 
generic fallback mechanism like ThreadedSeedGenerator?  (Note, I'm not 
suggesting using it, it's rather...SSLLLOOO...)



The problem is also how to make access to this functionality for
different consumers that are located in different packages (java.util,
java.util.concurrent) and make it somehow usable also for external
access. There is a desire to use this also from stand-alone builds of
java.util.concurrent utilities. That's why my initial approach for
SystemRandom used a public API in java.util.

The approach used with sun.misc.Unsafe is probably not going to work for
user code in JDK9 with modules, as sun.misc will not be globally
exported. Are any non J2SE packages going to be globally exported? I see
jdk and jdk.net are already mentioned as such globally exported packages
in modules.xml...


That's a good question for Alan/Mandy/company.


Martin wrote:


https://bugs.openjdk.java.net/browse/JDK-8047769


If you've been following this bug, I've figured why the NativePRNG$*
classes are initing and thus opening the /dev/random,urandom.  This
definitely needs some adjustment.


Something like the following could be used in NativePRNG and
URLSeedGenerator:

http://cr.openjdk.java.net/~plevart/misc/FileInputStreamPool/FileInputStreamPool.java


(See the other active thread in core-libs-dev.)

Brad

Re: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors

[Bradford Wetmore]

I'm looking at this version of the webrev.

http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/ 



I just assigned 8047769 to you.  My username is wetmore, Alan is alanb.

On 12/24/2014 3:37 AM, Peter Levart wrote:


Looks like you have a committer status, will you be pushing this?


I can, yes. As soon as we clear-out the remaining questions, right?


Yes.  The comments below are minor and shouldn't need another review 
cycle.  I have started a JPRT job for you, I'll run it through core 
target which will give us:


jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio, jdk_security*, 
jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools.


Anything else?  I'm off tomorrow, I should have full results Wed.

Here are the preliminary results for the jobs that have finished. 
jdk.testlibrary.Asserts is causing compilation errors, additional 
comments below:


/opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:33: 
error: package jdk.testlibrary does not exist

import static jdk.testlibrary.Asserts.*;
 ^
/opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:52: 
error: cannot find symbol

assertEquals(bytes.length, nread, short read);
^
  symbol:   method assertEquals(int,int,String)
  location: class FileInputStreamPoolTest
/opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:53: 
error: cannot find symbol

assertTrue(Arrays.equals(readBytes, bytes),
^
  symbol:   method assertTrue(boolean,String)
  location: class FileInputStreamPoolTest
3 errors

TEST RESULT: Failed. Compilation failed: Compilation failed

I'm also getting failures in the following test.  I unfortunately have 
to leave now, so don't have time to look at this.  But it did mention 
seed so I'm mentioning it here.


TEST: java/lang/invoke/LFCaching/LFGarbageCollectedTest.java

ACTION: main -- Failed. Execution failed: `main' threw exception: 
java.lang.Error: 36 of 39 test cases FAILED! Rerun the test with the 
same -Dseed= option as in the log file!

REASON: User specified action: run main/othervm LFGarbageCollectedTest
TIME:   213.406 seconds
messages:
command: main LFGarbageCollectedTest
reason: User specified action: run main/othervm LFGarbageCollectedTest
elapsed time (seconds): 213.406
STDOUT:
-Dseed=6102311124531075592
-DtestLimit=2000
Number of iterations according to -DtestLimit is 153 (1989 cases)
Code cache size is 251658240 bytes
Non-profiled code cache size is 123058253 bytes
Number of iterations limited by code cache size is 84 (1092 cases)
Number of iterations limited by non-profiled code cache size is 41 (533 
cases)

Number of iterations is set to 41 (533 cases)
Not enough time to continue execution. Interrupted.
STDERR:
Iteration 0:
Tested LF caching feature with MethodHandles.foldArguments method.
java.lang.AssertionError: Error: Lambda form is not garbage collected
at LFGarbageCollectedTest.doTest(LFGarbageCollectedTest.java:81)
at 
LambdaFormTestCase$TestRun.doIteration(LambdaFormTestCase.java:139)

at LambdaFormTestCase$$Lambda$2/5042013.call(Unknown Source)
at 
jdk.testlibrary.TimeLimitedRunner.call(TimeLimitedRunner.java:71)

at LambdaFormTestCase.runTests(LambdaFormTestCase.java:201)
at LFGarbageCollectedTest.main(LFGarbageCollectedTest.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)


In a couple places, there are a few lines  80 chars.  (It's a pet
peeve of mine, this makes side-by-side reviews difficult without a
wide monitor.  I realize not everyone shares this view, but they're
probably not working on a laptop screen regularly.)


I have wrapped the lines to contain them inside the 80 column margin.


I and my scrubber/slider thank you.  :)

Two minor nits?   SeedGenerator.java:  Lines 507/518


Do you need to close the InputStream when last holder is GC'd, or do
we just let the FileInputStream's finalizer take care of that?


WeakReferenceUncloseableInputStream is enqueued when it is cleared, so
at that time we have no access to the referent (UncloseableInputStream)
any more. We could, in addition, strongly reference the underlying
FileInputStream in the WeakReference subclass itself, but that would
just prolong the life of FileInputStream (possibly forever if no further
calls to FileInputStreamPool are made that expunge the references from
the queue). So yes, we rely on FileInputStream's finalizer, but I don't
see any other way that would be better than that.


Makes sense, thanks.


NativePRNG and
URLSeedGenerator don't have a means of closing underlying resources
either, so this is not making things any worse.


Yes.


Both of these current calls are contained within a
AccessContrller.doPriviledged, the checkRead() seems redundant.


That's right, but from 

Re: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors

[Bradford Wetmore]

Hi Peter,

Looks like you have a committer status, will you be pushing this?

On 12/18/2014 5:23 AM, Peter Levart wrote:

Hi,

I propose a patch for the following issue:

 https://bugs.openjdk.java.net/browse/JDK-8047769

Here's the webrev:

http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.01/


Looks good.  A few minor comments.

In a couple places, there are a few lines  80 chars.  (It's a pet peeve 
of mine, this makes side-by-side reviews difficult without a wide 
monitor.  I realize not everyone shares this view, but they're probably 
not working on a laptop screen regularly.)


Do you need to close the InputStream when last holder is GC'd, or do we 
just let the FileInputStream's finalizer take care of that?


Both of these current calls are contained within a 
AccessContrller.doPriviledged, the checkRead() seems redundant.


In your test case, if assertions are not enabled, the tests at 46/50/51 
are noops, e.g. when run by hand.  Generally should directly throw 
Exceptions.



The patch uses a package-private FileInputStreamPool class that caches
open FileInputStream(s) so that at most one file descriptor is open for
a particular file. Reading from shared unbuffered FileInputStream in
multiple threads should be safe, right?


I would think (hope?) so, but I am not 100% sure.  I tracked it down 
into libjava native code:


io_util.c
=
fd = GET_FD(this, fid);
if (fd == -1) {
JNU_ThrowIOException(env, Stream Closed);
nread = -1;
} else {
nread = IO_Read(fd, buf, len);

which is then defined to handleRead, which calls something called 
RESTARTABLE in io_util_md.c.  Assuming I'm looking at the right code.


Core-libs folks?


sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java:
Make sure that when no system policy and user policy files exist, the
built-in default policy will be used, which - amongst other things -
grants standard extensions the AllPermission.
sun/security/provider/PolicyParser/ExtDirsChange.java: standard
extensions path is hard-coded in default system policy file
sun/security/provider/PolicyParser/PrincipalExpansionError.java: parser
incorrectly ignores a principal if the principal name expands to nothing.

...they are unrelated to this patch - seems to be caused by recent
layout changes for modular runtime images.


Hopefully you saw my previous response.  Repeating:

---begin---
They've been failing for a while:

https://bugs.openjdk.java.net/browse/JDK-8039280

These tests are all /manual so they don't show up in our regular runs 
of JPRT/jtreg, which include -a.


-a | -automatic | -automagic
Any test with /manual will not be run
---end---

Thanks,

Brad

Re: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors

[Bradford Wetmore]

Peter,

Thanks for looking into this.

I'll in the middle of reviewing your change (and TLR/SplittableRandom 
reply), but have several appointments over the next few days.


But did want to respond to:


sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java:
Make sure that when no system policy and user policy files exist, the
built-in default policy will be used, which - amongst other things -
grants standard extensions the AllPermission.
sun/security/provider/PolicyParser/ExtDirsChange.java: standard
extensions path is hard-coded in default system policy file
sun/security/provider/PolicyParser/PrincipalExpansionError.java: parser
incorrectly ignores a principal if the principal name expands to nothing.

...they are unrelated to this patch - seems to be caused by recent
layout changes for modular runtime images.


They've been failing for a while:

https://bugs.openjdk.java.net/browse/JDK-8039280

These tests are all /manual so they don't show up in our regular runs 
of JPRT/jtreg, which include -a.


-a | -automatic | -automagic
Any test with /manual will not be run

Thanks,

Brad

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

[Bradford Wetmore]

Various comments for this thread from June/July/November/December.

Some of the comments I'm responding to may already be better understood 
than when they were originally written.


Peter wrote in response to a suggestion to use /dev/random:


Although the approach would cause some more classes to load, no
arbitrary providers should be initialized.


I think this is waht you get when you set
java.util.secureRandomSeed system property to true. TLR uses
java.security.SecureRandom.getSeed(8) in this case.


For the no arbitrary provider part, that may not be quite correct. 
getSeed() creates/pulls from the default SecureRandom impl (i.e. new 
SecureRandom().generateSeed()), so it pulls in the Security Provider 
mechanism to determine the most preferred implementation, which could 
initialize additional higher-priority providers until an instance of 
SecureRandom is found.  For example, ucrypto on Solaris doesn't have a 
SecureRandom impl, so it would then fall back to PKCS11.


As has been pointed out, the various Oracle SecureRandom implementations 
and their preference order are a twisty maze of passages, somewhat but 
not exactly alike.  (With apologies to the Colossal Cave.)  The 
default preference order is:


Solaris (sparc/sparcv9/x86/x64)
PKCS11 - SunPKCS11
NativePRNG - Sun
SHA1PRNG - Sun
NativePRNGBlocking - Sun
NativePRNGNonBlocking - Sun

Linux (x86/x64)/MacOS
NativePRNG - Sun
SHA1PRNG - Sun
NativePRNGBlocking - Sun
NativePRNGNonBlocking - Sun

Windows (x86/x64)
SHA1PRNG - Sun
Windows-PRNG - SunMSCAPI

Here's a few impl details for seeding calls.

PKCS11:
---
generateSeed() routes to engineNextBytes(), which goes to the underlying 
PKCS11.


NativePRNG:  (Unix-only)
---
generateSeed() by default routes to /dev/random, unless the System 
Entropy Gathering Device (EGD) (set via a Security/System property) 
routes to something else.  (FYI: nextBytes() uses /dev/urandom.)


NativePRNG$BLOCKING:  (Unix-only)

generateSeed() always routes to /dev/random.  (FYI: nextBytes() uses 
/dev/random.)


NativePRNG$NONBLOCKING:  (Unix-only)
---
generateSeed() always routes to /dev/urandom.  (FYI: nextBytes() uses 
/dev/urandom.)



SHA1PRNG:
-
generateSeed() depends on the value of the EGD:

default EGD is:  /dev/random

Note: if string /dev/urandom is set, urandom is used instead.

Unix:  generateSeed() routes to /dev/random
   (NativeSeedGenerator: pure java)

Win:   generateSeed() routes to CryptGenRandom
   (NativeSeedGenerator + libjava native)

non-default (not /dev/random//dev/urandom):  URL is specified
UNIX/Win:  routes to URL

If both above fail:
falls back to ThreadedSeedGenerator (Pure Java)


Windows-PRNG

generateSeed() routes to mscapi.PRNG/CryptGenRandom
Note uses libmscapi, not libjava.


Peter wrote:

The most problematic one is the default on Windows platform (the
platform that does not have the /dev/urandom special file and would
be used as a fall-back by your proposal) -
sun.security.provider.SecureRandom. This one seeds itself by
constructing an instance of itself with the result returned from
SeedGenerator.getSystemEntropy() method. This method, among other
things, uses networking code to gather system entropy:


SeedGenerator.getSystemEntropy() that includes the Network interfaces is 
only called when you need to seed the SHA1PRNG internal seeder in order 
to generate nextBytes().  generateSeed() doesn't trigger that internal 
seeder initialization.


So as you can see above, SecureRandom.generateSeed(int) is really 
variable in what you might end up with, and how much cruft comes with 
it.  For sure, the provider mechanism will be dragged in which is fairly 
substantial.



Peter wrote:


So by default yes, plain NativePRNG (the default on
UNIX-es) is using /dev/urandom for nextBytes(), but this can be
changed by defining java.security.egd or securerandom.source system
property.


EGD really only affects where Seed byes are obtained from, IIRC, 
nextBytes() is not generally affected by this value.  It does tweak 
which implementation is most preferred within the Sun provider, but the 
majority of the effect is in Native/SHA1PRNG choice of generateSeed.


The original suggestion back in June:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027389.html
http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/

for directly calling into NativeSeedGenerator makes more sense if you 
want to avoid duplicating existing code and creating a new native 
libraries as in the current proposal (webrev.03).  Your data shows that 
this approach pulls in a much smaller subset of classes than using the 
full SecureRandom.getInstance().generateSeed() API.  I've gone through 
the threads a couple times now:  somehow I've missed the rationale for 
why you're moving away from this (.01) for webrev.03.


To 

Re: ThreadLocalRandom clinit troubles

[Bradford Wetmore]

On 6/26/2014 4:10 PM, Doug Lea wrote:

This seems to be the best idea yet, assuming that people are OK
with the changes to sun.security.provider.SeedGenerator and
NativeSeedGenerator.java


I've been meaning to review this thread, but have been chasing several 
urgent escalations.


Brad

Re: RFR: 8047721: @since should have JDK version

[Bradford Wetmore]

I would prefer that JCE1.2 be pulled out completely in the Cipher* 
classes.  I will be sending you a separate note about JCE logistics.


Thanks for doing this cleanup.

Brad


On 6/20/2014 11:46 AM, Henry Jen wrote:

Hi,

Please review a trivial webrev to add JDK version to @since in a format
as Mark suggested[1].

http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/

[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html

Appened is the diff as in the webrev.

Cheers,
Henry


diff --git a/src/share/classes/java/lang/Package.java
b/src/share/classes/java/lang/Package.java
--- a/src/share/classes/java/lang/Package.java
+++ b/src/share/classes/java/lang/Package.java
@@ -107,6 +107,7 @@
   * loader to be found.
   *
   * @see ClassLoader#definePackage
+ * @since 1.2
   */
  public class Package implements java.lang.reflect.AnnotatedElement {
  /**
diff --git a/src/share/classes/javax/crypto/CipherInputStream.java
b/src/share/classes/javax/crypto/CipherInputStream.java
--- a/src/share/classes/javax/crypto/CipherInputStream.java
+++ b/src/share/classes/javax/crypto/CipherInputStream.java
@@ -170,7 +170,7 @@
   * @return  the next byte of data, or code-1/code if the end
of the
   *  stream is reached.
   * @exception  IOException  if an I/O error occurs.
- * @since JCE1.2
+ * @since 1.4, JCE1.2
   */
  public int read() throws IOException {
  if (ostart = ofinish) {
@@ -196,7 +196,7 @@
   * the stream has been reached.
   * @exception  IOException  if an I/O error occurs.
   * @seejava.io.InputStream#read(byte[], int, int)
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
   */
  public int read(byte b[]) throws IOException {
  return read(b, 0, b.length);
@@ -217,7 +217,7 @@
   * the stream has been reached.
   * @exception  IOException  if an I/O error occurs.
   * @seejava.io.InputStream#read()
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
   */
  public int read(byte b[], int off, int len) throws IOException {
  if (ostart = ofinish) {
@@ -254,7 +254,7 @@
   * @param  n the number of bytes to be skipped.
   * @return the actual number of bytes skipped.
   * @exception  IOException  if an I/O error occurs.
- * @since JCE1.2
+ * @since 1.4, JCE1.2
   */
  public long skip(long n) throws IOException {
  int available = ofinish - ostart;
@@ -277,7 +277,7 @@
   * @return the number of bytes that can be read from this
input stream
   * without blocking.
   * @exception  IOException  if an I/O error occurs.
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
   */
  public int available() throws IOException {
  return (ofinish - ostart);
@@ -292,7 +292,7 @@
   * stream.
   *
   * @exception  IOException  if an I/O error occurs.
- * @since JCE1.2
+ * @since 1.4, JCE1.2
   */
  public void close() throws IOException {
  if (closed) {
@@ -321,7 +321,7 @@
   *  codemark/code and codereset/code methods.
   * @see java.io.InputStream#mark(int)
   * @see java.io.InputStream#reset()
- * @since   JCE1.2
+ * @since   1.4, JCE1.2
   */
  public boolean markSupported() {
  return false;
diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java
b/src/share/classes/javax/crypto/CipherOutputStream.java
--- a/src/share/classes/javax/crypto/CipherOutputStream.java
+++ b/src/share/classes/javax/crypto/CipherOutputStream.java
@@ -114,7 +114,7 @@
   *
   * @param  b   the codebyte/code.
   * @exception  IOException  if an I/O error occurs.
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
   */
  public void write(int b) throws IOException {
  ibuffer[0] = (byte) b;
@@ -138,7 +138,7 @@
   * @exception  NullPointerException if codeb/code is null.
   * @exception  IOException  if an I/O error occurs.
   * @seejavax.crypto.CipherOutputStream#write(byte[], int,
int)
- * @since JCE1.2
+ * @since 1.4, JCE1.2
   */
  public void write(byte b[]) throws IOException {
  write(b, 0, b.length);
@@ -152,7 +152,7 @@
   * @param  off   the start offset in the data.
   * @param  len   the number of bytes to write.
   * @exception  IOException  if an I/O error occurs.
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
   */
  public void write(byte b[], int off, int len) throws IOException {
  obuffer = cipher.update(b, off, len);
@@ -174,7 +174,7 @@
   * the cipher's block size, no bytes will be written out.
   *
   * @exception  IOException  if an I/O error occurs.
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
   */
  public void flush() throws IOException {
  if (obuffer != null) {
@@ -198,7 +198,7 @@

Re: ThreadLocalRandom clinit troubles

[Bradford Wetmore]

Martin,

Thanks for filing.  I was positive there was already a bug for this, but 
for the life of me I can't find it now.  There's some other more minor 
cleanup that needs to take place, but seems like I've been in 
escalation/firefighting mode for more than a year now and it hasn't 
bubbled to the top.


Brad


On 6/21/2014 9:05 PM, Martin Buchholz wrote:

While looking at NativePRNG, I filed

https://bugs.openjdk.java.net/browse/JDK-8047769

SecureRandom should be more frugal with file descriptors

If I run this java program on Linux

public class SecureRandoms {
 public static void main(String[] args) throws Throwable {
 new java.security.SecureRandom();
 }
}

it creates 6 file descriptors for /dev/random and /dev/urandom, as shown
by:

strace -q -ff -e open java SecureRandoms | grep /dev/
[pid 20769] open(/dev/random, O_RDONLY) = 5
[pid 20769] open(/dev/urandom, O_RDONLY) = 6
[pid 20769] open(/dev/random, O_RDONLY) = 7
[pid 20769] open(/dev/random, O_RDONLY) = 8
[pid 20769] open(/dev/urandom, O_RDONLY) = 9
[pid 20769] open(/dev/urandom, O_RDONLY) = 10

Looking at jdk/src/solaris/classes/sun/security/provider/NativePRNG.java
it looks like 2 file descriptors are created for every variant of
NativePRNG, whether or not they are ever used. Which is wasteful. In
fact, you only ever need at most two file descriptors, one for
/dev/random and one for /dev/urandom.

Further, it would be nice if the file descriptors were closed when idle
and lazily re-created. Especially /dev/random should typically be used
at startup and never thereafter.


On Fri, Jun 20, 2014 at 7:59 AM, Alan Bateman alan.bate...@oracle.com
mailto:alan.bate...@oracle.com wrote:

On 20/06/2014 15:02, Peter Levart wrote:


And, as Martin pointed out, it seems to be used for tests that
exercise particular responses from NameService API to test the
behaviour of JDK classes. It would be a shame for those tests to
go away.

We've been talking about removing it for many years because it has
been so troublesome. If we really need to having something for
testing then I don't think it needs to be general purpose, we can
get right of the lookup at least.

-Alan.

Re: RFR: 8047721: @since should have JDK version

[Bradford Wetmore]

JCE (Cipher) changes look good to me.

Let me know if there's any problem with the point I mentioned in the 
other email.


Brad



On 6/23/2014 1:50 PM, Henry Jen wrote:

OK, I'll remove all @since JCE line, as the class already has @since 1.4
as Joe pointed out earlier.

Uodated webrev at

http://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/

Cheers,
Henry


On 06/23/2014 10:04 AM, Bradford Wetmore wrote:

I would prefer that JCE1.2 be pulled out completely in the Cipher*
classes.  I will be sending you a separate note about JCE logistics.

Thanks for doing this cleanup.

Brad


On 6/20/2014 11:46 AM, Henry Jen wrote:

Hi,

Please review a trivial webrev to add JDK version to @since in a format
as Mark suggested[1].

http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/

[1]
http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html

Appened is the diff as in the webrev.

Cheers,
Henry


diff --git a/src/share/classes/java/lang/Package.java
b/src/share/classes/java/lang/Package.java
--- a/src/share/classes/java/lang/Package.java
+++ b/src/share/classes/java/lang/Package.java
@@ -107,6 +107,7 @@
   * loader to be found.
   *
   * @see ClassLoader#definePackage
+ * @since 1.2
   */
  public class Package implements java.lang.reflect.AnnotatedElement {
  /**
diff --git a/src/share/classes/javax/crypto/CipherInputStream.java
b/src/share/classes/javax/crypto/CipherInputStream.java
--- a/src/share/classes/javax/crypto/CipherInputStream.java
+++ b/src/share/classes/javax/crypto/CipherInputStream.java
@@ -170,7 +170,7 @@
   * @return  the next byte of data, or code-1/code if the end
of the
   *  stream is reached.
   * @exception  IOException  if an I/O error occurs.
- * @since JCE1.2
+ * @since 1.4, JCE1.2
   */
  public int read() throws IOException {
  if (ostart = ofinish) {
@@ -196,7 +196,7 @@
   * the stream has been reached.
   * @exception  IOException  if an I/O error occurs.
   * @seejava.io.InputStream#read(byte[], int, int)
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
   */
  public int read(byte b[]) throws IOException {
  return read(b, 0, b.length);
@@ -217,7 +217,7 @@
   * the stream has been reached.
   * @exception  IOException  if an I/O error occurs.
   * @seejava.io.InputStream#read()
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
   */
  public int read(byte b[], int off, int len) throws IOException {
  if (ostart = ofinish) {
@@ -254,7 +254,7 @@
   * @param  n the number of bytes to be skipped.
   * @return the actual number of bytes skipped.
   * @exception  IOException  if an I/O error occurs.
- * @since JCE1.2
+ * @since 1.4, JCE1.2
   */
  public long skip(long n) throws IOException {
  int available = ofinish - ostart;
@@ -277,7 +277,7 @@
   * @return the number of bytes that can be read from this
input stream
   * without blocking.
   * @exception  IOException  if an I/O error occurs.
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
   */
  public int available() throws IOException {
  return (ofinish - ostart);
@@ -292,7 +292,7 @@
   * stream.
   *
   * @exception  IOException  if an I/O error occurs.
- * @since JCE1.2
+ * @since 1.4, JCE1.2
   */
  public void close() throws IOException {
  if (closed) {
@@ -321,7 +321,7 @@
   *  codemark/code and codereset/code methods.
   * @see java.io.InputStream#mark(int)
   * @see java.io.InputStream#reset()
- * @since   JCE1.2
+ * @since   1.4, JCE1.2
   */
  public boolean markSupported() {
  return false;
diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java
b/src/share/classes/javax/crypto/CipherOutputStream.java
--- a/src/share/classes/javax/crypto/CipherOutputStream.java
+++ b/src/share/classes/javax/crypto/CipherOutputStream.java
@@ -114,7 +114,7 @@
   *
   * @param  b   the codebyte/code.
   * @exception  IOException  if an I/O error occurs.
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
   */
  public void write(int b) throws IOException {
  ibuffer[0] = (byte) b;
@@ -138,7 +138,7 @@
   * @exception  NullPointerException if codeb/code is null.
   * @exception  IOException  if an I/O error occurs.
   * @seejavax.crypto.CipherOutputStream#write(byte[], int,
int)
- * @since JCE1.2
+ * @since 1.4, JCE1.2
   */
  public void write(byte b[]) throws IOException {
  write(b, 0, b.length);
@@ -152,7 +152,7 @@
   * @param  off   the start offset in the data.
   * @param  len   the number of bytes to write.
   * @exception  IOException  if an I/O error occurs.
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
   */
  public void

Re: RFR: 8047721: @since should have JDK version

[Bradford Wetmore]

Except for these two classes, none of the JCE APIs ever contained @since 
until the JCE was put into JDK 1.4 back in 2002.  The unbundled JCE 
hasn't been shipped in probably almost a decade.  None of the unbundled 
JSSE/JGSS should have them either.


Carrying around this old information is just cruft, IMO.

Brad





On 6/23/2014 2:28 PM, Paul Benedict wrote:

What's the rationale for removing the secondary version? Or I guess the
question should really be: when are secondary versions useful? At least
in the EE specs, the EE version plus the spec version are listed in many
places like this.


Cheers,
Paul


On Mon, Jun 23, 2014 at 3:50 PM, Henry Jen henry@oracle.com
mailto:henry@oracle.com wrote:

OK, I'll remove all @since JCE line, as the class already has @since
1.4 as Joe pointed out earlier.

Uodated webrev at

http://cr.openjdk.java.net/~__henryjen/jdk9/8047721/2/__webrev/
http://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/

Cheers,
Henry



On 06/23/2014 10:04 AM, Bradford Wetmore wrote:

I would prefer that JCE1.2 be pulled out completely in the Cipher*
classes.  I will be sending you a separate note about JCE logistics.

Thanks for doing this cleanup.

Brad


On 6/20/2014 11:46 AM, Henry Jen wrote:

Hi,

Please review a trivial webrev to add JDK version to @since
in a format
as Mark suggested[1].

http://cr.openjdk.java.net/~__henryjen/jdk9/8047721/0/__webrev/
http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/

[1]

http://mail.openjdk.java.net/__pipermail/jdk9-dev/2014-June/__000806.html

http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html

Appened is the diff as in the webrev.

Cheers,
Henry


diff --git a/src/share/classes/java/lang/__Package.java
b/src/share/classes/java/lang/__Package.java
--- a/src/share/classes/java/lang/__Package.java
+++ b/src/share/classes/java/lang/__Package.java
@@ -107,6 +107,7 @@
* loader to be found.
*
* @see ClassLoader#definePackage
+ * @since 1.2
*/
   public class Package implements
java.lang.reflect.__AnnotatedElement {
   /**
diff --git
a/src/share/classes/javax/__crypto/CipherInputStream.java
b/src/share/classes/javax/__crypto/CipherInputStream.java
--- a/src/share/classes/javax/__crypto/CipherInputStream.java
+++ b/src/share/classes/javax/__crypto/CipherInputStream.java
@@ -170,7 +170,7 @@
* @return  the next byte of data, or code-1/code
if the end
of the
*  stream is reached.
* @exception  IOException  if an I/O error occurs.
- * @since JCE1.2
+ * @since 1.4, JCE1.2
*/
   public int read() throws IOException {
   if (ostart = ofinish) {
@@ -196,7 +196,7 @@
* the stream has been reached.
* @exception  IOException  if an I/O error occurs.
* @seejava.io.InputStream#read(byte[__],
int, int)
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
*/
   public int read(byte b[]) throws IOException {
   return read(b, 0, b.length);
@@ -217,7 +217,7 @@
* the stream has been reached.
* @exception  IOException  if an I/O error occurs.
* @seejava.io.InputStream#read()
- * @since  JCE1.2
+ * @since  1.4, JCE1.2
*/
   public int read(byte b[], int off, int len) throws
IOException {
   if (ostart = ofinish) {
@@ -254,7 +254,7 @@
* @param  n the number of bytes to be skipped.
* @return the actual number of bytes skipped.
* @exception  IOException  if an I/O error occurs.
- * @since JCE1.2
+ * @since 1.4, JCE1.2
*/
   public long skip(long n) throws IOException {
   int available = ofinish - ostart;
@@ -277,7 +277,7 @@
* @return the number of bytes that can be read
from this
input stream
* without blocking.
* @exception  IOException  if an I/O error occurs.
- * @since  JCE1.2
+ * @since  1.4, JCE1.2

Webrev for 8043342: StringBuffer/StringBuilder crypto changes.

[Bradford Wetmore]

No additional code review necessary, this is just an FYI.

For internal reasons (i.e. we have to sign our JCE jar files), we have 
separated the JCE portion for:


8041679: Replace uses of StringBuffer with StringBuilder within the JDK

into:

8043342: Replace uses of StringBuffer with StringBuilder within crypto code

It's the exact same code, but only the four JCE files are included here.

http://cr.openjdk.java.net/~wetmore/8043342/webrev.00/

I am sponsoring this for Jamil, from an original fix [1] sponsored by 
Paul Sandoz from:


Otávio Gonçalves de Santana

Thanks,

Brad

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/026820.html

hg: jdk8/tl/jdk: 8027526: CheckTipsAndVersions.java failing occasionally

[bradford . wetmore]

Changeset: f731d096530f
Author:wetmore
Date:  2013-10-30 16:49 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f731d096530f

8027526: CheckTipsAndVersions.java failing occasionally
Reviewed-by: mullan, mchung

! test/java/security/Signature/SignatureGetAlgorithm.java

hg: jdk8/tl/jdk: 8026762: jdk8-tl builds windows builds failing in corba - javac: no source files

[bradford . wetmore]

Changeset: a45acc8de0f3
Author:wetmore
Date:  2013-10-16 23:32 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a45acc8de0f3

8026762: jdk8-tl builds windows builds failing in corba - javac: no source files
Reviewed-by: katleman, dholmes

! makefiles/GenerateClasses.gmk

hg: jdk8/tl/corba: 8026762: jdk8-tl builds windows builds failing in corba - javac: no source files

[bradford . wetmore]

Changeset: 1a71d800b032
Author:wetmore
Date:  2013-10-16 23:31 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/1a71d800b032

8026762: jdk8-tl builds windows builds failing in corba - javac: no source files
Reviewed-by: katleman, dholmes

! makefiles/BuildCorba.gmk

hg: jdk8/tl/jdk: 8025694: Rename getStrongSecureRandom based on feedback; ...

[bradford . wetmore]

Changeset: a6ac824b463d
Author:wetmore
Date:  2013-10-02 09:38 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6ac824b463d

8025694: Rename getStrongSecureRandom based on feedback
8014838: getStrongSecureRandom() should require at least one implementation
Reviewed-by: mullan, darcy

! src/share/classes/java/security/SecureRandom.java
! src/share/lib/security/java.security-windows
! test/sun/security/provider/SecureRandom/StrongSecureRandom.java

Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks)

[Bradford Wetmore]

Sorry, I haven't been following the Random discussions until now, I 
haven't been subscribed to core-lib-dev in a while.


I was specifically asked to comment on Brian's proposed change.

Paul pointed out something Bill Pugh wrote:

 Right, see here:

 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/009176.html


 I spent some time looking at the implementation of SecureRandom and
 of sun.security.provider.NativePRNG. The implementation of NativePRNG
 uses a static singleton to perform all of the work, so that looked
 like the concurrency bottleneck. But when I rewrote that class, it
 turns out that even removing all of the Java level concurrency
 bottlenecks, we still can't generate concurrent secure random
 numbers, because the NativePRNG reads /dev/urandom for each byte, and
 that is inherently sequential and is the bottleneck to the entire
 process of generating secure random numbers.

What Bill Pugh wrote is correct for NativePRNG.

new SecureRandom() chooses its implementation based on the most 
preferred provider.  Different OS's have different preferred 
implementations:


Solaris (x86/sparc):  PKCS11 (from the SunPKCS11 provider)
Linux:NativePRNG
MacOS:NativePRNG
Windows:  SHA1PRNG

PKCS11 probably has a similar OS bottleneck.  SHA1PRNG doesn't go to 
native MSCAPI after the initial seeding of the class, so on windows you 
would just have Java level contention.


A bit of background:  SHA1PRNG is the only implementation that is 
available on all platforms.  How the class is initially seeded depends 
on some additional steps not mentioned in the threads I've seen to date 
(getSystemEntropy), and NativeSeedGenerators from the underlying OS:


src/share/classes/sun/security/provider/SecureRandom.java
src/share/classes/sun/security/provider/SeedGenerator.java
src/*/classes/sun/security/provder/NativeSeedGenerator.java

Bill also wrote in that email:

 add the following method to BigInteger
 public boolean isProbablePrime(int certainty, Random end) ,
 which allows primality testing with arbitrary Random objects.
 In many cases, using a well seeded normal Random object will work
 just fine, and this will give users the ability to provide their own
 Random objects

This sounds like a very good solution to me.  That way someone can 
decide whether they want to take the hit with SecureRandom, or if Random 
is good enough.


Paul Sandoz wrote:

 I don't know about the PRNG requirements for Miller-Rabin but the
 changes to TLR in review might be a possible substitute for SR in
 this case, since TLR will be updated to use the same PRNG algorithm
 as SplittableRandom, which passes DieHarder tests.  Otherwise, i
 think we may just be stuck with SR.

In my brief read of the Miller-Rabin tests, it just selects several 
random values to use for guessing whether another number selected by a 
different random number generator is prime or not.  Given initial seed 
values (i.e. one not set via new Random(seed) constructor), manipulating 
the Random implementation to ensure a steady stream of strong liars 
seems rather difficult.


In addition we run a secondary test which reduces that attack surface 
(LucasLehmer).


So offhand, I wouldn't commit to saying if SecureRandom is necessary or 
not, but it wouldn't surprise me.


But I think Bill's suggestion is worth pursuing.

Various comments:

Paul Sandoz wrote:

 Perhaps it would also allow us to deprecate Random in a future JDK?

SecureRandom is a subclass of Random, so I'm wondering how it will be 
perceived to have the secure version based on a deprecated base class. 
 I know the underlying implementations are *COMPLETELY* different, but 
I've been working with this code for a while now.


 Perhaps there could be factory methods to obtain a PRNG based on
 generator properties rather than picking a specific class.

There is an RFE for something like that (similar to 
SecureRandom.getInstance()), but I can't find it at the moment.


Martin Buchholz wrote:

 full support for a variety of generators and distributions is a
 career path)

Yes, I'm hoping to add some more crypto PRNGs, ala NIST Special 
Publication 800-90A in JDK 9.


Brad

hg: jdk8/tl/jdk: 8023075: JDK-5049299 has broken old make in jdk8

[bradford . wetmore]

Changeset: f8af3499c1fb
Author:wetmore
Date:  2013-08-14 19:19 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8af3499c1fb

8023075: JDK-5049299 has broken old make in jdk8
Reviewed-by: katleman

! make/java/java/Makefile

hg: jdk8/tl/jdk: 8014620: Signature.getAlgorithm return null in special case

[bradford . wetmore]

Changeset: 116050227ee9
Author:youdwei
Date:  2013-06-17 17:36 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/116050227ee9

8014620: Signature.getAlgorithm return null in special case
Reviewed-by: wetmore

! src/share/classes/java/security/Signature.java
+ test/java/security/Signature/SignatureGetAlgorithm.java

hg: jdk8/tl/jdk: 8012530: test/sun/security/provider/SecureRandom/StrongSeedReader.java failing

[bradford . wetmore]

Changeset: b600d637ef77
Author:wetmore
Date:  2013-04-25 17:10 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b600d637ef77

8012530: test/sun/security/provider/SecureRandom/StrongSeedReader.java failing
Reviewed-by: wetmore
Contributed-by: alan.bate...@oracle.com

! test/sun/security/provider/SecureRandom/StrongSeedReader.java

hg: jdk8/tl/jdk: 8009925: Back out AEAD CipherSuites temporarily

[bradford . wetmore]

Changeset: 6379415d8fca
Author:wetmore
Date:  2013-03-12 15:31 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6379415d8fca

8009925: Back out AEAD CipherSuites temporarily
Reviewed-by: valeriep

! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java
! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java
- src/share/classes/sun/security/ssl/Authenticator.java
! src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/EngineInputRecord.java
! src/share/classes/sun/security/ssl/EngineOutputRecord.java
! src/share/classes/sun/security/ssl/EngineWriter.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/InputRecord.java
! src/share/classes/sun/security/ssl/JsseJce.java
! src/share/classes/sun/security/ssl/MAC.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/Record.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! test/sun/security/ec/TestEC.java
! test/sun/security/pkcs11/fips/CipherTest.java
! test/sun/security/pkcs11/sslecc/CipherTest.java
! 
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
- test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
! test/sun/security/ssl/sanity/interop/CipherTest.java
! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java

hg: jdk8/tl/jdk: 7197071: Makefiles for various security providers aren't including the default manifest

[bradford . wetmore]

Changeset: 940c8cc5a5c4
Author:wetmore
Date:  2012-10-23 12:36 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/940c8cc5a5c4

7197071: Makefiles for various security providers aren't including the default 
manifest
Reviewed-by: valeriep, mullan, katleman

! make/com/oracle/security/ucrypto/Makefile
! make/javax/crypto/Defs-jce.gmk
! make/sun/security/ec/Makefile
! make/sun/security/mscapi/Makefile
! make/sun/security/pkcs11/Makefile
+ test/javax/crypto/sanity/CheckManifestForRelease.java

hg: jdk8/tl/jdk: 8001419: Build the JCE portion of JDK-8000970

[bradford . wetmore]

Changeset: 13b46e8eda33
Author:ohrstrom
Date:  2012-10-23 15:51 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13b46e8eda33

8001419: Build the JCE portion of JDK-8000970
Summary: Original code done by Fredrik Ohrstrom, separated/pushed by wetmore
Reviewed-by: wetmore

! src/share/classes/com/sun/crypto/provider/KeyProtector.java
+ src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java

hg: jdk8/tl/jdk: 7177556: Put TestProviderLeak.java on the ProblemList until test can be reworked

[bradford . wetmore]

Changeset: 8e5635ded425
Author:wetmore
Date:  2012-06-15 17:42 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e5635ded425

7177556: Put TestProviderLeak.java on the ProblemList until test can be reworked
Reviewed-by: khazra

! test/ProblemList.txt

hg: jdk8/tl/jdk: 7167362: SecureRandom.init should be converted, amendment to 7084245

[bradford . wetmore]

Changeset: 6438f1277df6
Author:wetmore
Date:  2012-05-09 16:33 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6438f1277df6

7167362: SecureRandom.init should be converted, amendment to 7084245
Reviewed-by: sherman

! src/share/classes/sun/security/provider/SecureRandom.java

hg: jdk8/tl/jdk: 7157903: JSSE client sockets are very slow

[bradford . wetmore]

Changeset: 10480cf00dcd
Author:wetmore
Date:  2012-04-11 17:12 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10480cf00dcd

7157903: JSSE client sockets are very slow
Reviewed-by: xuelei

! src/share/classes/sun/security/ssl/AppOutputStream.java
! src/share/classes/sun/security/ssl/EngineOutputRecord.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java

hg: jdk8/tl/jdk: 7142172: Custom TrustManagers that return null for getAcceptedIssuers will NPE

[bradford . wetmore]

Changeset: 7a7dcbbd610f
Author:wetmore
Date:  2012-03-30 15:43 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a7dcbbd610f

7142172: Custom TrustManagers that return null for getAcceptedIssuers will NPE
Reviewed-by: xuelei

! src/share/classes/sun/security/ssl/SSLContextImpl.java
+ 
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NullGetAcceptedIssuers.java

hg: jdk8/tl/jdk: 7142509: Cipher.doFinal(ByteBuffer, ByteBuffer) fails to process when in.remaining() == 0

[bradford . wetmore]

Changeset: b16cbeb0d213
Author:wetmore
Date:  2012-02-10 19:07 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b16cbeb0d213

7142509: Cipher.doFinal(ByteBuffer,ByteBuffer) fails to process when 
in.remaining() == 0
Reviewed-by: valeriep

! src/share/classes/javax/crypto/CipherSpi.java
+ test/javax/crypto/CipherSpi/DirectBBRemaining.java

hg: jdk8/tl/jdk: 7141910: Incorrect copyright dates on new test cases.

[bradford . wetmore]

Changeset: 55a82eba1986
Author:wetmore
Date:  2012-02-01 16:00 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55a82eba1986

7141910: Incorrect copyright dates on new test cases.
Reviewed-by: mullan

! 
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java
! 
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh

hg: jdk8/tl/jdk: 7126889: Incorrect SSLEngine debug output

[bradford . wetmore]

Changeset: 5ee30ab905db
Author:wetmore
Date:  2012-01-26 17:16 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ee30ab905db

7126889: Incorrect SSLEngine debug output
Reviewed-by: xuelei

! src/share/classes/sun/security/ssl/EngineArgs.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
+ 
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java
+ 
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh

hg: jdk8/tl/jdk: 7105780: Add SSLSocket client/SSLEngine server to templates directory

[bradford . wetmore]

Changeset: 8681362a2f04
Author:wetmore
Date:  2011-10-31 11:54 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8681362a2f04

7105780: Add SSLSocket client/SSLEngine server to templates directory
Reviewed-by: xuelei

+ test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java

hg: jdk8/tl/jdk: 7053252: New regression test does not compile on windows-amd64

[bradford . wetmore]

Changeset: b60e88ef5d8d
Author:wetmore
Date:  2011-10-31 16:23 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b60e88ef5d8d

7053252: New regression test does not compile on windows-amd64
Reviewed-by: valeriep

! test/ProblemList.txt
! test/sun/security/pkcs11/Provider/Absolute.java

hg: jdk8/tl/jdk: 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine

[bradford . wetmore]

Changeset: 8640b7185be1
Author:wetmore
Date:  2011-10-18 11:58 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8640b7185be1

7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine
Reviewed-by: xuelei, weijun, asaha

! src/share/classes/sun/security/ssl/CipherBox.java
+ 
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java

hg: jdk7/tl/jdk: 6914617: JCE framework code signing certificate is expiring at the end of 2010.

[bradford . wetmore]

Changeset: 29e88b0c0894
Author:wetmore
Date:  2011-04-13 11:36 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29e88b0c0894

6914617: JCE framework code signing certificate is expiring at the end of 2010.
Reviewed-by: valeriep, weijun, mullan

! make/javax/crypto/Defs-jce.gmk

hg: jdk7/tl/jdk: 6626257: Update SWAN-specific webcaching to Oracle environment in the regression tests.

[bradford . wetmore]

Changeset: 65b6fe866a6f
Author:wetmore
Date:  2011-04-13 16:12 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/65b6fe866a6f

6626257: Update SWAN-specific webcaching to Oracle environment in the 
regression tests.
Reviewed-by: valeriep

! test/sun/net/InetAddress/nameservice/dns/cname.sh

hg: jdk7/tl/jdk: 6844879: Source distribution should be more robustly built without the security source distribution

[bradford . wetmore]

Changeset: 0f0d6b8f98cc
Author:wetmore
Date:  2011-02-23 22:54 -0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0f0d6b8f98cc

6844879: Source distribution should be more robustly built without the security 
source distribution
Reviewed-by: ohair

! make/common/shared/Defs-java.gmk

hg: jdk7/tl/jdk: 6945604: wrong error message in CardImpl.java

[bradford . wetmore]

Changeset: d8ad2da3ecf3
Author:wetmore
Date:  2010-04-20 14:24 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d8ad2da3ecf3

6945604: wrong error message in CardImpl.java
Reviewed-by: mullan

! src/share/classes/sun/security/smartcardio/CardImpl.java

hg: jdk7/tl/jdk: 6923976: TestProviderLeak.java is using too small of an initial heap under newer Hotspot (b79+)

[bradford . wetmore]

Changeset: 7136683a33d2
Author:wetmore
Date:  2010-02-05 17:05 -0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7136683a33d2

6923976: TestProviderLeak.java is using too small of an initial heap under 
newer Hotspot (b79+)
Reviewed-by: ohair

! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java

hg: jdk7/tl/jdk: 6867657: Many JSN tests do not run under cygwin

[bradford . wetmore]

Changeset: 2aa570c01c69
Author:wetmore
Date:  2009-08-06 17:56 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2aa570c01c69

6867657: Many JSN tests do not run under cygwin
Reviewed-by: ohair

! test/java/net/Authenticator/B4933582.sh
! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh
! test/java/net/Socket/OldSocketImpl.sh
! test/java/net/URL/B5086147.sh
! test/java/net/URL/runconstructor.sh
! test/java/net/URLClassLoader/B503.sh
! test/java/net/URLClassLoader/sealing/checksealed.sh
! test/java/net/URLConnection/6212146/test.sh
! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh
! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh
! test/java/security/Security/signedfirst/Dyn.sh
! test/java/security/Security/signedfirst/Static.sh
! test/javax/crypto/SecretKeyFactory/FailOverTest.sh
! test/javax/security/auth/Subject/doAs/Test.sh
! test/lib/security/java.policy/Ext_AllPolicy.sh
! test/sun/net/www/MarkResetTest.sh
! test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh
! test/sun/net/www/http/HttpClient/RetryPost.sh
! test/sun/net/www/protocol/jar/B5105410.sh
! test/sun/net/www/protocol/jar/jarbug/run.sh
! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh
! test/sun/security/pkcs11/Provider/Login.sh
! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh
! 
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh
! 
test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh
! 
test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh
! test/sun/security/tools/jarsigner/AlgOptions.sh
! test/sun/security/tools/jarsigner/PercentSign.sh
! test/sun/security/tools/jarsigner/oldsig.sh
! test/sun/security/tools/keytool/AltProviderPath.sh
! test/sun/security/tools/keytool/CloneKeyAskPassword.sh
! test/sun/security/tools/keytool/NoExtNPE.sh
! test/sun/security/tools/keytool/SecretKeyKS.sh
! test/sun/security/tools/keytool/StandardAlgName.sh
! test/sun/security/tools/keytool/i18n.sh
! test/sun/security/tools/keytool/printssl.sh
! test/sun/security/tools/keytool/resource.sh
! test/sun/security/tools/keytool/standard.sh

hg: jdk7/tl/jdk: 6778613: Update javax.crypto.Cipher.getMaxAllowedKeyLength to point to proper Appendix after doc reorg

[bradford . wetmore]

Changeset: 4e0e690373fc
Author:wetmore
Date:  2008-12-02 14:53 -0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4e0e690373fc

6778613: Update javax.crypto.Cipher.getMaxAllowedKeyLength to point to proper 
Appendix after doc reorg
Reviewed-by: mullan

! src/share/classes/javax/crypto/Cipher.java

hg: jdk7/tl/jdk: 10 new changesets

[bradford . wetmore]

Changeset: c7fae5013939
Author:michaelm
Date:  2008-09-19 13:32 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c7fae5013939

6750364: Error in test for 6744329
Reviewed-by: chegar

! test/com/sun/net/httpserver/bugs/B6744329.java

Changeset: e57447118235
Author:michaelm
Date:  2008-09-19 14:03 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e57447118235

Merge


Changeset: c54ce70a3668
Author:chegar
Date:  2008-09-19 15:14 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c54ce70a3668

6746836: java.net exception classes don't specify serialVersionUID
Reviewed-by: alanb, jccollet

! make/sun/net/spi/Makefile
! make/sun/net/spi/nameservice/Makefile
! make/sun/net/spi/nameservice/dns/Makefile
! src/share/classes/java/net/BindException.java
! src/share/classes/java/net/ConnectException.java
! src/share/classes/java/net/HttpRetryException.java
! src/share/classes/java/net/MalformedURLException.java
! src/share/classes/java/net/NoRouteToHostException.java
! src/share/classes/java/net/PortUnreachableException.java
! src/share/classes/java/net/ProtocolException.java
! src/share/classes/java/net/SocketException.java
! src/share/classes/java/net/SocketTimeoutException.java
! src/share/classes/java/net/URISyntaxException.java
! src/share/classes/java/net/UnknownHostException.java
! src/share/classes/java/net/UnknownServiceException.java
! src/share/classes/sun/net/ConnectionResetException.java
! src/share/classes/sun/net/ProgressEvent.java
! src/share/classes/sun/net/TelnetProtocolException.java
! src/share/classes/sun/net/ftp/FtpLoginException.java
! src/share/classes/sun/net/ftp/FtpProtocolException.java
! src/share/classes/sun/net/httpserver/HttpError.java
! src/share/classes/sun/net/httpserver/StreamClosedException.java
! src/share/classes/sun/net/smtp/SmtpProtocolException.java
! src/share/classes/sun/net/www/ApplicationLaunchException.java
! src/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java
! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java

Changeset: abf3e1aa8031
Author:michaelm
Date:  2008-09-22 15:53 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abf3e1aa8031

6739920: java 6u4~ use larger C heap if there are many threads
Reviewed-by: chegar

! src/share/classes/java/net/AbstractPlainSocketImpl.java
! src/solaris/native/java/net/PlainSocketImpl.c

Changeset: 976c7eb88476
Author:michaelm
Date:  2008-09-22 16:05 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/976c7eb88476

Merge


Changeset: 74fc78477907
Author:mullan
Date:  2008-09-22 10:43 -0400
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74fc78477907

6469266: Integrate Apache XMLSec 1.4.2 into JDK 7
Reviewed-by: valeriep

! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/Algorithm.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/JCEMapper.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/MessageDigestAlgorithm.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithmSpi.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java
+ 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizationException.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/InvalidCanonicalizerException.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/AttrCompare.java
+ 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java
+ 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_OmitComments.java
+ 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_WithComments.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclWithComments.java
! 

hg: jdk7/tl/jdk: 9 new changesets

[bradford . wetmore]

Changeset: eb342082e2b6
Author:jccollet
Date:  2008-09-04 15:26 +0200
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eb342082e2b6

6692802: HttpCookie needs to support HttpOnly attribute
Summary: Added HttpOnly tag support to HttpCookie class.
Reviewed-by: chegar, michaelm

! src/share/classes/java/net/HttpCookie.java
! test/java/net/CookieHandler/TestHttpCookie.java

Changeset: d276b0716d13
Author:wetmore
Date:  2008-09-05 00:43 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d276b0716d13

Merge


Changeset: bcb61dfc8514
Author:weijun
Date:  2008-09-08 14:17 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bcb61dfc8514

6740833: krb5.conf does not accept kdc=hostname (no spaces around =)
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/Config.java

Changeset: b0378bb50d83
Author:michaelm
Date:  2008-09-11 17:46 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b0378bb50d83

6744329: Exception in light weight http server code
Reviewed-by: chegar

! src/share/classes/sun/net/httpserver/ChunkedOutputStream.java
+ test/com/sun/net/httpserver/bugs/B6744329.java

Changeset: 80fe10573687
Author:mullan
Date:  2008-09-11 14:05 -0400
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/80fe10573687

6465942: Add problem identification facility to the CertPathValidator framework
Summary: Add support to the java.security.cert APIs for determining the reason 
that a certification path is invalid.
Reviewed-by: vinnie

! src/share/classes/java/security/cert/CertPathValidatorException.java
+ src/share/classes/java/security/cert/PKIXReason.java
! src/share/classes/sun/security/provider/certpath/BasicChecker.java
! src/share/classes/sun/security/provider/certpath/ConstraintsChecker.java
! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java
! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java
! src/share/classes/sun/security/provider/certpath/KeyChecker.java
! src/share/classes/sun/security/provider/certpath/OCSPChecker.java
! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java
! 
src/share/classes/sun/security/provider/certpath/PKIXMasterCertPathValidator.java
! src/share/classes/sun/security/provider/certpath/PolicyChecker.java
! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java
! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java
! 
test/java/security/cert/CertPathValidator/nameConstraintsRFC822/ValidateCertPath.java
+ test/java/security/cert/CertPathValidatorException/ReasonTest.java
+ test/java/security/cert/CertPathValidatorException/Serial.java
+ test/java/security/cert/CertPathValidatorException/cert_file
+ test/java/security/cert/CertPathValidatorException/jdk6.serial
! test/java/security/cert/PolicyNode/GetPolicyQualifiers.java

Changeset: 482a1857b598
Author:mullan
Date:  2008-09-11 18:13 -0400
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/482a1857b598

Merge


Changeset: 80fd09f239f4
Author:wetmore
Date:  2008-09-15 00:41 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/80fd09f239f4

Merge


Changeset: 0100b3e66894
Author:wetmore
Date:  2008-09-16 00:34 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0100b3e66894

Merge


Changeset: e81a1ebde376
Author:wetmore
Date:  2008-09-18 00:39 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e81a1ebde376

Merge

hg: jdk7/tl/jdk: 6 new changesets

[bradford . wetmore]

Changeset: a4ff2fe5b5d9
Author:weijun
Date:  2008-08-06 08:11 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a4ff2fe5b5d9

6731685: CertificateFactory.generateCertificates throws IOException on PKCS7 
cert chain
Reviewed-by: mullan

! src/share/classes/sun/security/util/DerIndefLenConverter.java
+ test/sun/security/util/DerValue/Indefinite.java

Changeset: 97d08b2b4539
Author:chegar
Date:  2008-08-06 07:14 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/97d08b2b4539

6734171: java.net.NetworkInterface reports XCheck:jni warnings
Summary: Removed leading L or trailing ; from FindClass classname param
Reviewed-by: alanb

! src/windows/native/java/net/NetworkInterface.c

Changeset: 874f4db252e3
Author:wetmore
Date:  2008-08-20 00:41 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/874f4db252e3

Merge


Changeset: afcf04c535da
Author:michaelm
Date:  2008-08-21 10:04 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/afcf04c535da

6258215: Num of backlog in ServerSocket(int, int) should be mentioned more 
explicitly
Summary: updated javadoc
Reviewed-by: chegar

! src/share/classes/java/net/ServerSocket.java
! src/share/classes/javax/net/ssl/SSLServerSocket.java

Changeset: f4289d75cd29
Author:jccollet
Date:  2008-08-25 14:38 +0200
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f4289d75cd29

6717876: Make java.net.NetworkInterface.getIndex() public
Summary: Make getIndex() and getByIndex() public. Required a name change in 
native code
Reviewed-by: alanb, chegar, michaelm

! make/java/net/mapfile-vers
! src/share/classes/java/net/NetworkInterface.java
! src/solaris/native/java/net/NetworkInterface.c
! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/NetworkInterface_winXP.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c
! src/windows/native/java/net/net_util_md.h
+ test/java/net/NetworkInterface/IndexTest.java

Changeset: 872241636752
Author:wetmore
Date:  2008-08-25 08:11 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/872241636752

Merge

hg: jdk7/tl/jdk: 6 new changesets

[bradford . wetmore]

Changeset: 2f21c9f8136a
Author:mullan
Date:  2008-06-17 10:34 -0400
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2f21c9f8136a

6673277: Thread unsafe lazy initialization code in 
sun.security.provider.certpath.*Checker classes
Summary: make supportedExts variable non-static
Reviewed-by: vinnie

! src/share/classes/sun/security/provider/certpath/ConstraintsChecker.java
! src/share/classes/sun/security/provider/certpath/KeyChecker.java
! src/share/classes/sun/security/provider/certpath/PolicyChecker.java

Changeset: bc5159dc2a81
Author:mullan
Date:  2008-06-17 10:53 -0400
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc5159dc2a81

Merge


Changeset: 4be8dfa19e27
Author:mullan
Date:  2008-06-19 14:20 -0400
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4be8dfa19e27

6714842: CertPathBuilder returns incorrect CertPath for BasicConstraints in 
builderParams
Summary: Do not consider CA target certificates if 
selector.getBasicConstraints() == -2
Reviewed-by: vinnie

! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java
+ 
test/java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java
+ test/java/security/cert/CertPathBuilder/targetConstraints/anchor.cer
+ test/java/security/cert/CertPathBuilder/targetConstraints/ca.cer
+ test/java/security/cert/CertPathBuilder/targetConstraints/ee.cer

Changeset: 3a7345910333
Author:weijun
Date:  2008-06-20 12:05 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3a7345910333

6716534: Krb5LoginModule has not cleaned temp info between authentication 
attempts
Reviewed-by: valeriep

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java

Changeset: 9cf5011bfe38
Author:wetmore
Date:  2008-06-26 00:26 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9cf5011bfe38

Merge


Changeset: 47c4a285e238
Author:wetmore
Date:  2008-06-29 00:25 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/47c4a285e238

Merge

hg: jdk7/tl/jdk: 9 new changesets

[bradford . wetmore]

Changeset: e8201036fc65
Author:xuelei
Date:  2008-06-04 09:56 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e8201036fc65

6690018: RSAClientKeyExchange NullPointerException
Summary: checking certificate key length for RSA_EXPORT key exchange
Reviewed-by: wetmore, mullan

! src/share/classes/sun/security/ssl/ClientHandshaker.java
+ 
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java

Changeset: da1eb844871c
Author:wetmore
Date:  2008-06-09 00:29 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/da1eb844871c

Merge


Changeset: e3de7e7bafcf
Author:weijun
Date:  2008-06-10 10:51 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e3de7e7bafcf

6711509: PolicyTool is misspelling Runtime permission - 'setSecurityManager' 
entry in the policy file
Reviewed-by: wetmore, mullan

! src/share/classes/sun/security/tools/PolicyTool.java

Changeset: 2058f3daec43
Author:weijun
Date:  2008-06-10 11:03 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2058f3daec43

6711435: console.sh uses incompatible ==
Reviewed-by: xuelei

! test/sun/security/tools/keytool/console.sh

Changeset: 93dce0e374de
Author:chegar
Date:  2008-06-12 17:25 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/93dce0e374de

6698625: InetAddress.getLocalHost() failed in returning chinese local host name
Summary: Remove unnecessary and incorrect NewStringUTF
Reviewed-by: michaelm

! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/windows/native/java/net/Inet4AddressImpl.c
! src/windows/native/java/net/Inet6AddressImpl.c

Changeset: 4d1d84792fd0
Author:chegar
Date:  2008-06-12 17:26 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4d1d84792fd0

6630348: Invalid html tags (extra double quote)
Summary: Remove extra quote
Reviewed-by: michaelm

! src/share/classes/java/net/CookieHandler.java
! src/share/classes/java/net/ResponseCache.java
! src/share/classes/java/net/URI.java
! src/share/classes/java/net/URL.java

Changeset: 56993d795f7a
Author:chegar
Date:  2008-06-12 17:28 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/56993d795f7a

6628569: api/java_net/MulticastSocket/descriptions.html#setTTL fails is ipv6 
configured
Summary: failover to IPv6 socket if IPv4 fails
Reviewed-by: michaelm

! src/solaris/native/java/net/NetworkInterface.c

Changeset: 7c9d632e7323
Author:jccollet
Date:  2008-06-13 17:43 +0200
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7c9d632e7323

6483406: new ServerSocket() sometimes takes more than 3 minutes on Suse Linux
Summary: Switch to socketpair() call to create marker fd
Reviewed-by: alanb

! src/solaris/native/java/net/PlainSocketImpl.c

Changeset: 6471947b1ffc
Author:wetmore
Date:  2008-06-16 10:46 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6471947b1ffc

Merge

hg: jdk7/tl/jdk: 7 new changesets

[bradford . wetmore]

Changeset: ca48d7cc3579
Author:chegar
Date:  2008-05-15 10:26 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ca48d7cc3579

6670408: testcase panics 1.5.0_12_14 JVM when java.net.PlainSocketImpl trying 
to throw an exception
Summary: Replace select with poll
Reviewed-by: alanb, jccollet

! src/solaris/native/java/net/PlainSocketImpl.c

Changeset: 2ebefcea77a5
Author:vinnie
Date:  2008-05-14 18:59 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2ebefcea77a5

6383078: OCSP checking does not work on end-entity certificate
Reviewed-by: mullan

! src/share/classes/sun/security/provider/certpath/OCSPChecker.java

Changeset: 49f02cbe27b1
Author:vinnie
Date:  2008-05-15 10:55 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/49f02cbe27b1

Merge


Changeset: d3dfeb4295b3
Author:wetmore
Date:  2008-05-17 00:27 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d3dfeb4295b3

Merge


Changeset: f8049c6ff629
Author:wetmore
Date:  2008-05-22 14:20 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f8049c6ff629

6706358: jdk/test/sun/security/pkcs11/Cipher/TestSymmCiphers.java has the wrong 
copyright notice.
Reviewed-by: valeriep

! test/sun/security/pkcs11/Cipher/TestSymmCiphers.java

Changeset: ead7a5f601d5
Author:weijun
Date:  2008-05-27 14:29 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ead7a5f601d5

6705313: Incorrect exit $? in keytool's autotest.sh
Reviewed-by: valeriep

! test/sun/security/tools/keytool/autotest.sh

Changeset: 827f9f3d1031
Author:wetmore
Date:  2008-06-02 10:16 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/827f9f3d1031

Merge

hg: jdk7/tl/jdk: 2 new changesets

[bradford . wetmore]

Changeset: d95a6a4ea502
Author:chegar
Date:  2008-05-02 21:33 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d95a6a4ea502

6687919: REGRESSION : Classloader can handle any resource which is not included 
in classpath
Reviewed-by: jccollet, alanb

! src/share/classes/sun/misc/URLClassPath.java

Changeset: 61a7e1919ba3
Author:wetmore
Date:  2008-05-11 00:26 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/61a7e1919ba3

Merge

hg: jdk7/tl/jdk: 19 new changesets

[bradford . wetmore]

Changeset: ad75c4b21d63
Author:weijun
Date:  2008-04-10 19:58 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ad75c4b21d63

6675606: javax.security.auth.login.Configuration does not recognize path with 
spaces
Reviewed-by: chegar, xuelei

! src/share/classes/com/sun/security/auth/login/ConfigFile.java
+ test/javax/security/auth/login/Configuration/ConfigFileWithBlank.java

Changeset: c0eb84957bea
Author:xuelei
Date:  2008-04-11 03:33 -0400
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c0eb84957bea

6546639: (spec)javax.net.ssl.SSLContext.getInstance(null) throws undocumented 
NPE
Summary: add NullPointerException description to those methods.
Reviewed-by: weijun

! src/share/classes/javax/net/ssl/SSLContext.java

Changeset: da9fa1fa9b95
Author:xuelei
Date:  2008-04-11 03:43 -0400
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/da9fa1fa9b95

6546671: (spec)javax.net.ssl.TrustManagerFactory.getInstance() throws 
undocumented NP
5053895: (spec) Unspecified IllegalStateException in TrustManagerFactory
Summary: add NullPointerException/IllegalStateException description
Reviewed-by: weijun

! src/share/classes/javax/net/ssl/TrustManagerFactory.java
! src/share/classes/javax/net/ssl/TrustManagerFactorySpi.java

Changeset: 143e1a9b51a9
Author:xuelei
Date:  2008-04-11 03:50 -0400
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/143e1a9b51a9

6571950: SSLSocket(raddr, rport, laddr, lport) allows null as laddr that spec 
doesn't reflect
Summary: add the description that while the local address parameter is null, 
anyLocalAddress will be used instead.
Reviewed-by: weijun

! src/share/classes/java/net/Socket.java
! src/share/classes/javax/net/ssl/SSLSocket.java

Changeset: aabdc646cb31
Author:mullan
Date:  2008-04-14 10:25 -0400
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aabdc646cb31

6631361: Spec of AccessControlContext constructor is not complete
Summary: Add NullPointerException to @throws clause and treat empty array and 
array of nulls as equivalent
Reviewed-by: valeriep

! src/share/classes/java/security/AccessControlContext.java
+ test/java/security/AccessControlContext/CheckCtor.java

Changeset: b627c3efd97c
Author:mullan
Date:  2008-04-14 10:41 -0400
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b627c3efd97c

Merge


Changeset: 459d23a95dfb
Author:chegar
Date:  2008-04-15 14:22 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/459d23a95dfb

6659779: HttpURLConnections logger should log tunnel requests
Summary: Invoke Logger for CONNECT request/responses.
Reviewed-by: jccollet

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java

Changeset: a954a6f3be6f
Author:chegar
Date:  2008-04-16 14:17 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a954a6f3be6f

6687282: URLConnection for HTTPS connection through Proxy w/ Digest 
Authentication gives 400 Bad Request
Summary: Change http/digest implementation to use host:port from CONNECT request
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java

Changeset: d44e3bf49ffb
Author:jccollet
Date:  2008-04-17 11:05 +0200
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d44e3bf49ffb

6644726: Cookie management issues
Summary: Many changes to accomodate RFC 2965 and old Netscape specs
Reviewed-by: chegar

! src/share/classes/java/net/CookieManager.java
! src/share/classes/java/net/HttpCookie.java
! src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java
+ test/java/net/CookieHandler/B6644726.java

Changeset: 493af4f4be79
Author:wetmore
Date:  2008-04-17 16:56 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/493af4f4be79

Merge


Changeset: a71ab67d3ece
Author:jccollet
Date:  2008-04-18 15:23 +0200
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a71ab67d3ece

6558853: getHostAddress() on connections using IPv6 link-local addrs should 
have zone id
Summary: Set the scope_id_set flag when necessary
Reviewed-by: chegar

! src/share/native/java/net/net_util.c
+ test/java/net/Inet6Address/B6558853.java

Changeset: 4e7ad09de58b
Author:weijun
Date:  2008-04-23 08:10 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4e7ad09de58b

6689000: Changes in 6675606 causing regression test failures on windows-i586
Summary: Accept illegal URLs like file:c:/root/x.conf and file:this/that/x.conf
Reviewed-by: alanb, chegar

! src/share/classes/com/sun/security/auth/login/ConfigFile.java
+ test/com/sun/security/auth/login/ConfigFile/IllegalURL.java

Changeset: d3af7105cc15
Author:wetmore
Date:  2008-04-23 10:20 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d3af7105cc15

Merge


Changeset: 072695f32409
Author:mullan
Date:  2008-04-25 08:58 -0400
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/072695f32409

6690169: Specification 

hg: jdk7/tl/jdk: 32 new changesets

[bradford . wetmore]

Changeset: e1b99dfabb04
Author:chegar
Date:  2008-03-04 17:09 +
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e1b99dfabb04

6638560: APPCRASH in SPNEGO_HTTP_AUTH/PROXY_FALLBACK test case with 64 bit 
JDK on Win2008 x64, VinVista x64
Summary: Remove incorrect free from native code
Reviewed-by: jccollet

! src/windows/native/sun/net/www/protocol/http/NTLMAuthSequence.c

Changeset: 02e18782ebe1
Author:weijun
Date:  2008-03-05 09:52 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/02e18782ebe1

6641312: Fix krb5 codes indentation problems
Reviewed-by: xuelei, valeriep, wetmore

! src/share/classes/sun/security/krb5/KrbTgsReq.java
! src/share/classes/sun/security/krb5/internal/APRep.java
! src/share/classes/sun/security/krb5/internal/APReq.java
! src/share/classes/sun/security/krb5/internal/ASRep.java
! src/share/classes/sun/security/krb5/internal/ASReq.java
! src/share/classes/sun/security/krb5/internal/Authenticator.java
! src/share/classes/sun/security/krb5/internal/AuthorizationData.java
! src/share/classes/sun/security/krb5/internal/AuthorizationDataEntry.java
! src/share/classes/sun/security/krb5/internal/EncAPRepPart.java
! src/share/classes/sun/security/krb5/internal/EncASRepPart.java
! src/share/classes/sun/security/krb5/internal/EncKDCRepPart.java
! src/share/classes/sun/security/krb5/internal/EncKrbCredPart.java
! src/share/classes/sun/security/krb5/internal/EncKrbPrivPart.java
! src/share/classes/sun/security/krb5/internal/EncTGSRepPart.java
! src/share/classes/sun/security/krb5/internal/EncTicketPart.java
! src/share/classes/sun/security/krb5/internal/KDCRep.java
! src/share/classes/sun/security/krb5/internal/KDCReq.java
! src/share/classes/sun/security/krb5/internal/KRBCred.java
! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java
! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java
! src/windows/native/sun/security/krb5/NativeCreds.c

Changeset: 6baf10020bb3
Author:jccollet
Date:  2008-03-05 11:40 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6baf10020bb3

6641309: Wrong Cookie separator used in HttpURLConnection
Summary: Added a space to cookie separator. Generified the code and added tags.
Reviewed-by: chegar

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! test/java/net/CookieHandler/CookieManagerTest.java
+ test/sun/net/www/protocol/http/B6641309.java

Changeset: 7360321c37e3
Author:weijun
Date:  2008-03-05 21:55 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7360321c37e3

6648972: KDCReq.init always read padata
Summary: PA-DATA is optional, only read it when it exists
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/internal/ETypeInfo2.java
! src/share/classes/sun/security/krb5/internal/KDCReq.java
+ test/sun/security/krb5/OptionPADataInKDCReq.java

Changeset: d842462572a9
Author:weijun
Date:  2008-03-05 22:15 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d842462572a9

6590930: reed/write does not match for ccache
Summary: Add null-awareness to ccache read
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java
! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java
+ test/sun/security/krb5/TimeInCCache.java

Changeset: 66d2a8a11d59
Author:weijun
Date:  2008-03-05 22:16 +0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/66d2a8a11d59

6664612: debug output leaked
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java
! src/share/classes/sun/security/krb5/internal/crypto/dk/AesDkCrypto.java
! src/share/classes/sun/security/krb5/internal/crypto/dk/ArcFourCrypto.java

Changeset: b6f7db7d8648
Author:jccollet
Date:  2008-03-05 17:16 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b6f7db7d8648

6660405: HttpURLConnection returns the wrong InputStream
Summary: Set inputStream back to null in disconnectInternal().
Reviewed-by: chegar

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/sun/net/www/protocol/http/B6660405.java

Changeset: 7ce5e8238b53
Author:jccollet
Date:  2008-03-05 18:11 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7ce5e8238b53

6651717: Debug output statement left in MailToURLConnection
Summary: Removed output statement, removed unused imports, added override tags.
Reviewed-by: chegar

! src/share/classes/sun/net/www/protocol/mailto/MailToURLConnection.java

Changeset: fa6948bdc4b0
Author:wetmore
Date:  2008-03-06 10:35 -0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fa6948bdc4b0

6623830: SCCS cleanup has broken two regression tests.
Reviewed-by: chegar

! test/java/net/ResponseCache/file2.1

Changeset: a100f699c155
Author:chegar
Date:  2008-03-07 09:57 +
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a100f699c155

6667108: typo in javadoc for java.net.Socket.getRemoteSocketAddress()
Summary: