hg: jdk8/tl/langtools: 7066788: javah again accepts -old option (ineffectively) which was removed in 1.5.
Changeset: a47e28759666 Author:vromero Date: 2013-06-27 09:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a47e28759666 7066788: javah again accepts -old option (ineffectively) which was removed in 1.5. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javah/JavahTask.java
hg: jdk8/tl/langtools: 8017609: javac, ClassFile.read(Path) should be ClassFile.read(Path, Attribute.Factory)
Changeset: 8e3d391c88c6 Author:vromero Date: 2013-06-27 09:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8e3d391c88c6 8017609: javac, ClassFile.read(Path) should be ClassFile.read(Path, Attribute.Factory) Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/ClassFile.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 370e7beff8a0 Author:wetmore Date: 2013-06-27 10:19 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/370e7beff8a0 8019227: JDK-8010325 broke the old build Reviewed-by: alanb, chegar ! make/java/java/FILES_java.gmk Changeset: 4e69a7dfbeac Author:chegar Date: 2013-06-27 10:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e69a7dfbeac Merge
hg: jdk8/tl/langtools: 8016099: Some @SuppressWarnings annotations ignored ( unchecked, rawtypes )
Changeset: e42c27026290 Author:vromero Date: 2013-06-27 16:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e42c27026290 8016099: Some @SuppressWarnings annotations ignored ( unchecked, rawtypes ) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T8016099/UncheckedWarningRegressionTest.java + test/tools/javac/T8016099/UncheckedWarningRegressionTest.out
hg: jdk8/tl/langtools: 7008643: inlined finally clauses confuse debuggers
Changeset: d137ce373c4c Author:vromero Date: 2013-06-27 16:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d137ce373c4c 7008643: inlined finally clauses confuse debuggers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T7008643/InlinedFinallyConfuseDebuggersTest.java
Re: RFR JDK8015799
All: I just posted a webrev image of the latest changes: http://cr.openjdk.java.net/~jzavgren/8015799/webrev.03/ Thanks! John On 06/26/2013 04:52 PM, Kurchi Hazra wrote: Alright, thanks for the clarification - the source code changes are good as they are then. - Kurchi On 6/26/2013 1:49 PM, Chris Hegarty wrote: To link this email thread, both in the archives, and for others. The call for review on this bug started with: http://mail.openjdk.java.net/pipermail/net-dev/2013-June/006607.html On 06/26/2013 08:22 PM, Kurchi Hazra wrote: On 6/26/2013 12:17 PM, Kurchi Hazra wrote: Hi John, Why not change lines 2810-2811 to: if (value == null || value.length() == 0) return value; I meant return null. For other cookie-headers too, is there any reason for us not returning null if the length of value is 0? In the first webrev John had made this change, but I asked him to revert it and only change the Set-Cookie(2) headers. Since all header retrieval passes through filterHeaderField, in one way or another, I'm a little concerned about changing this. Also, as the only issue we know of is with Set-Cookie(2), maybe you could add the empty string check to these headers only? ( that is to say, move the 'value.length() == 0' check into the ' if (SET_COOKIE.equalsIgnoreCase(name). ' The difference is, currently if a header value is non-null and has a length of 0 ( i.e. empty string ), then empty string is returned. With the original change then null is returned. We have been bitten by subtle changes in this area before. Returning null from such an API, URLConnection.getHeaderField(s), for cases where it did not return null before may lead to NPE's in some applications. -Chris. Also, lots of formatting issue in the test, especially in TestCookieHandler, try-catch block indentation is off in line 54. Its also best to stop the server in a finally clause at line 58. Alternatively, I also liked Andreas' use of autocloseable in his test for 6563286. See [1]. Yes, please. -Chris. - Kurchi [1] http://cr.openjdk.java.net/~arieber/6563286/webrev.00/test/sun/net/www/http/HttpURLConnection/MalformedFollowRedirect.java.html http://cr.openjdk.java.net/%7Earieber/6563286/webrev.00/test/sun/net/www/http/HttpURLConnection/MalformedFollowRedirect.java.html On 6/26/2013 10:54 AM, John Zavgren wrote: Please consider the following changes to the Java cookie code. http://cr.openjdk.java.net/~jzavgren/8015799/webrev.02/ http://cr.openjdk.java.net/%7Ejzavgren/8015799/webrev.02/ The problem I fixed occurs when a server returns an array of cookies that contains a null cookie. Thanks John -- John Zavgren john.zavg...@oracle.com 603-821-0904 US-Burlington-MA -- -Kurchi -- John Zavgren john.zavg...@oracle.com 603-821-0904 US-Burlington-MA
hg: jdk8/tl/langtools: 8015720: since tag isn't copied while generating JavaFX documentation
Changeset: 26437287529d Author:janvalenta Date: 2013-06-27 17:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/26437287529d 8015720: since tag isn't copied while generating JavaFX documentation Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! test/com/sun/javadoc/testJavaFX/C.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java
Re: RFR JDK8015799
Looks fine to me John. -Chris. On 27/06/2013 17:09, John Zavgren wrote: All: I just posted a webrev image of the latest changes: http://cr.openjdk.java.net/~jzavgren/8015799/webrev.03/ Thanks! John On 06/26/2013 04:52 PM, Kurchi Hazra wrote: Alright, thanks for the clarification - the source code changes are good as they are then. - Kurchi On 6/26/2013 1:49 PM, Chris Hegarty wrote: To link this email thread, both in the archives, and for others. The call for review on this bug started with: http://mail.openjdk.java.net/pipermail/net-dev/2013-June/006607.html On 06/26/2013 08:22 PM, Kurchi Hazra wrote: On 6/26/2013 12:17 PM, Kurchi Hazra wrote: Hi John, Why not change lines 2810-2811 to: if (value == null || value.length() == 0) return value; I meant return null. For other cookie-headers too, is there any reason for us not returning null if the length of value is 0? In the first webrev John had made this change, but I asked him to revert it and only change the Set-Cookie(2) headers. Since all header retrieval passes through filterHeaderField, in one way or another, I'm a little concerned about changing this. Also, as the only issue we know of is with Set-Cookie(2), maybe you could add the empty string check to these headers only? ( that is to say, move the 'value.length() == 0' check into the ' if (SET_COOKIE.equalsIgnoreCase(name). ' The difference is, currently if a header value is non-null and has a length of 0 ( i.e. empty string ), then empty string is returned. With the original change then null is returned. We have been bitten by subtle changes in this area before. Returning null from such an API, URLConnection.getHeaderField(s), for cases where it did not return null before may lead to NPE's in some applications. -Chris. Also, lots of formatting issue in the test, especially in TestCookieHandler, try-catch block indentation is off in line 54. Its also best to stop the server in a finally clause at line 58. Alternatively, I also liked Andreas' use of autocloseable in his test for 6563286. See [1]. Yes, please. -Chris. - Kurchi [1] http://cr.openjdk.java.net/~arieber/6563286/webrev.00/test/sun/net/www/http/HttpURLConnection/MalformedFollowRedirect.java.html http://cr.openjdk.java.net/%7Earieber/6563286/webrev.00/test/sun/net/www/http/HttpURLConnection/MalformedFollowRedirect.java.html On 6/26/2013 10:54 AM, John Zavgren wrote: Please consider the following changes to the Java cookie code. http://cr.openjdk.java.net/~jzavgren/8015799/webrev.02/ http://cr.openjdk.java.net/%7Ejzavgren/8015799/webrev.02/ The problem I fixed occurs when a server returns an array of cookies that contains a null cookie. Thanks John -- John Zavgren john.zavg...@oracle.com 603-821-0904 US-Burlington-MA -- -Kurchi
RFR JDK8017079
Greetings: Please consider the following socket constructor changes: http://cr.openjdk.java.net/~jzavgren/8017079/webrev.01/ http://cr.openjdk.java.net/%7Ejzavgren/8017079/webrev.01/ Thanks! John -- John Zavgren john.zavg...@oracle.com 603-821-0904 US-Burlington-MA
Re: RFR JDK8015799
Chris, 1. I'm not sure it's a correct to return null rather then empty value, but you understand better what is happening, so I'm leaving it up to you. 2. It might be better to move 2805 if (value == null) 2806 return null; under if(SET_COOKIE ...), i.e. to ll. 2810 it doesn't change anything in practice - the methods continue returning null for all cases where value is null - but makes code better understandable. -Dmitry On 2013-06-27 00:49, Chris Hegarty wrote: To link this email thread, both in the archives, and for others. The call for review on this bug started with: http://mail.openjdk.java.net/pipermail/net-dev/2013-June/006607.html On 06/26/2013 08:22 PM, Kurchi Hazra wrote: On 6/26/2013 12:17 PM, Kurchi Hazra wrote: Hi John, Why not change lines 2810-2811 to: if (value == null || value.length() == 0) return value; I meant return null. For other cookie-headers too, is there any reason for us not returning null if the length of value is 0? In the first webrev John had made this change, but I asked him to revert it and only change the Set-Cookie(2) headers. Since all header retrieval passes through filterHeaderField, in one way or another, I'm a little concerned about changing this. Also, as the only issue we know of is with Set-Cookie(2), maybe you could add the empty string check to these headers only? ( that is to say, move the 'value.length() == 0' check into the ' if (SET_COOKIE.equalsIgnoreCase(name). ' The difference is, currently if a header value is non-null and has a length of 0 ( i.e. empty string ), then empty string is returned. With the original change then null is returned. We have been bitten by subtle changes in this area before. Returning null from such an API, URLConnection.getHeaderField(s), for cases where it did not return null before may lead to NPE's in some applications. -Chris. Also, lots of formatting issue in the test, especially in TestCookieHandler, try-catch block indentation is off in line 54. Its also best to stop the server in a finally clause at line 58. Alternatively, I also liked Andreas' use of autocloseable in his test for 6563286. See [1]. Yes, please. -Chris. - Kurchi [1] http://cr.openjdk.java.net/~arieber/6563286/webrev.00/test/sun/net/www/http/HttpURLConnection/MalformedFollowRedirect.java.html http://cr.openjdk.java.net/%7Earieber/6563286/webrev.00/test/sun/net/www/http/HttpURLConnection/MalformedFollowRedirect.java.html On 6/26/2013 10:54 AM, John Zavgren wrote: Please consider the following changes to the Java cookie code. http://cr.openjdk.java.net/~jzavgren/8015799/webrev.02/ http://cr.openjdk.java.net/%7Ejzavgren/8015799/webrev.02/ The problem I fixed occurs when a server returns an array of cookies that contains a null cookie. Thanks John -- John Zavgren john.zavg...@oracle.com 603-821-0904 US-Burlington-MA -- -Kurchi -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
hg: jdk8/tl/jdk: 8019304: Fix doclint issues in java.util.prefs
Changeset: 1c31082f0a51 Author:darcy Date: 2013-06-27 11:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c31082f0a51 8019304: Fix doclint issues in java.util.prefs Reviewed-by: lancea ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/prefs/PreferencesFactory.java
Re: RFR JDK8017079
Looks good. - Kurchi On 6/27/2013 10:09 AM, Chris Hegarty wrote: Looks good to me John. -Chris. On 27/06/2013 18:02, John Zavgren wrote: Greetings: Please consider the following socket constructor changes: http://cr.openjdk.java.net/~jzavgren/8017079/webrev.01/ http://cr.openjdk.java.net/%7Ejzavgren/8017079/webrev.01/ Thanks! John -- John Zavgren john.zavg...@oracle.com 603-821-0904 US-Burlington-MA
hg: jdk8/tl/langtools: 8019308: Add descriptions of Java SE 7 and 8 language changes to SourceVersion
Changeset: 065f8cb7bd89 Author:darcy Date: 2013-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/065f8cb7bd89 8019308: Add descriptions of Java SE 7 and 8 language changes to SourceVersion Reviewed-by: jjg ! src/share/classes/javax/lang/model/SourceVersion.java
hg: jdk8/tl/jdk: 8017471: Fix JDBC -Xdoclint public errors
Changeset: b9ba04dc210f Author:lancea Date: 2013-06-27 15:07 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b9ba04dc210f 8017471: Fix JDBC -Xdoclint public errors Reviewed-by: darcy ! src/share/classes/java/sql/Blob.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Clob.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/Driver.java ! src/share/classes/java/sql/DriverAction.java ! src/share/classes/java/sql/NClob.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLInput.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/sql/SQLXML.java ! src/share/classes/java/sql/Wrapper.java ! src/share/classes/javax/sql/CommonDataSource.java ! src/share/classes/javax/sql/ConnectionPoolDataSource.java ! src/share/classes/javax/sql/DataSource.java ! src/share/classes/javax/sql/RowSet.java ! src/share/classes/javax/sql/XADataSource.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/FilteredRowSet.java ! src/share/classes/javax/sql/rowset/JdbcRowSet.java ! src/share/classes/javax/sql/rowset/Joinable.java ! src/share/classes/javax/sql/rowset/Predicate.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java ! src/share/classes/javax/sql/rowset/RowSetWarning.java ! src/share/classes/javax/sql/rowset/WebRowSet.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncResolver.java
hg: jdk8/tl/jdk: 8019315: Fix doclint issues in java.util.logging
Changeset: b8f16cb2d95b Author:darcy Date: 2013-06-27 12:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8f16cb2d95b 8019315: Fix doclint issues in java.util.logging Reviewed-by: lancea ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java
Re: 6563286: HttpURLConnection.followRedirect(..) follows malformed url.
Hi, i did one more update to avoid duplicate code (3 times used). The redirect status codes are checked now in one static method. I added Malformed redirect to the exception, so it is possible to trace. All tests run on ubuntu. Updated webrev: http://cr.openjdk.java.net/~arieber/6563286/webrev.02/ thanks Andreas On 26.06.13 21:50, Andreas Rieber wrote: Hi Kurchi, i removed the closed issue. Then i checked again the HttpURLConnection and moved the check so really only redirects are detected and handled properly with the IOException. The test i updated and moved to the right place. Bug: http://bugs.sun.com/view_bug.do?bug_id=6563286 Updated webrev: http://cr.openjdk.java.net/~arieber/6563286/webrev.01/ cheers Andreas PS: i also liked the autocloseable, was waiting to long for the builds and had to do something else in between ;-) On 25.06.13 22:18, Andreas Rieber wrote: Hi Kurchi, thanks for the first feedback. The problem i had was that the URL is right (according spec) but at protocol level the used URI is wrong. The ProxySelector is also right to send the IllegalArgumentException (just needed to be documented to do that). And yes, a better error message should come out when sending the IOException. So lets wait for some more input on that issue. But where do you see a API change, i tried to avoid that? cheers Andreas On 25.06.13 20:57, Kurchi Hazra wrote: Hi Andreas, Your changes look good to me. 5069130 had been closed as not a defect - since we throw an unchecked exception, and was decided to be the right course of action. Now, I don't have a problem with changing the code to throw a checked exception in this case - but we have to wait for an OpenJDK reviewer to agree as well. My only suggestion is to add a good message to the IOException being thrown, so that it is clear that the URL sent by the server is problematic and make debugging easier. In the test, the first RuntimeException message being printed in line 46 is probably misleading, but this is a minor issue. I'll wait for a JDK reviewer's input on this. I can sponsor the change for you. We may need an internal approval here for the minor API change. Thanks, - Kurchi On 6/24/2013 12:42 PM, Andreas Rieber wrote: Hi, here a small fix for 2 older issues. First i wrote the test for wrong URL at connection time and at redirect time. Bug(s): http://bugs.sun.com/view_bug.do?bug_id=6563286 http://bugs.sun.com/view_bug.do?bug_id=5069130 Webrev: http://cr.openjdk.java.net/~arieber/6563286/webrev.00/ What happens is that the java.net.ProxySelector.select(URI uri) is called, which throws the IllegalArgumentException if uri is null. But it uses sun.net.spi.DefaultProxySelector.java and also throws the exception if uri.getScheme() is null or uri.getHost() is null. I updated the javadoc in ProxySelector. To change the exception to an IOException would mean a wider refactoring and API change, not good. So i checked down to net.www.protocol.http.HttpURLConnection.java. There the IllegalArgumentException can be caught and thrown as IOException. This will handle wrong URLs in both cases (connect and redirect). I checked also all other possible cases but they are handled with correct exceptions. I run all tests on ubuntu, so a test run on all relevant platforms is required. thanks for checking this one Andreas
hg: jdk8/tl/langtools: 7080001: Need to bump version numbers in build.properties for 8
Changeset: 97e798c06804 Author:ksrini Date: 2013-06-27 12:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/97e798c06804 7080001: Need to bump version numbers in build.properties for 8 Reviewed-by: jjg ! make/build.properties
hg: jdk8/tl/jdk: 8019224: add exception chaining to RMI CGIHandler
Changeset: 6729f7ef94cd Author:smarks Date: 2013-06-27 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6729f7ef94cd 8019224: add exception chaining to RMI CGIHandler Reviewed-by: darcy ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java
hg: jdk8/tl/jdk: 8019320: Fix doclint issues in javax.script
Changeset: 1099fe14fb65 Author:darcy Date: 2013-06-27 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1099fe14fb65 8019320: Fix doclint issues in javax.script Reviewed-by: lancea ! src/share/classes/javax/script/Invocable.java ! src/share/classes/javax/script/ScriptContext.java ! src/share/classes/javax/script/ScriptEngineFactory.java ! src/share/classes/javax/script/SimpleScriptContext.java
hg: jdk8/tl/jdk: 6609431: (rb) ResourceBundle.getString() returns incorrect value
Changeset: e34e3ddb3cd8 Author:naoto Date: 2013-06-27 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e34e3ddb3cd8 6609431: (rb) ResourceBundle.getString() returns incorrect value Reviewed-by: okutsu, sherman ! src/share/classes/java/util/Properties.java + test/java/util/Properties/Bug6609431.java + test/java/util/Properties/Bug6609431.properties
RFR: 8019341: Update CookieHttpsClientTest to use the newer framework.
Chris (and Michael), As my part of the intermittently failing test cleanup, I'm looking into a test of yours that has been intermittently failing. It's bug: https://jbs.oracle.com/bugs/browse/JDK-8017333 which is failing the regression test you added for: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8a143213c65 You used a really old version of the test framework (pre-2003!) which doesn't output both the client and server exceptions. I've updated the test to use the new framework, and would like to put this back as a temporary measure so we can see what is really happening from any possible swallowed exceptions. Xuelei/I are stumped as to what might be happening, so hopefully this action will give some clarity. 8019341: Update CookieHttpsClientTest to use the newer framework. http://cr.openjdk.java.net/~wetmore/8019341/webrev.00/ It would be easiest to compare your test to the test/sun/security/ssl/templates/SSLSocketTemplate.java. They should be the same except for your test-specific code. Brad P.S. I think AlanB/JoeD/StuartM will appreciate this effort. ;)
Re: RFR: 8019341: Update CookieHttpsClientTest to use the newer framework.
On 6/27/13 4:58 PM, Brad Wetmore wrote: Chris (and Michael), As my part of the intermittently failing test cleanup, I'm looking into a test of yours that has been intermittently failing. It's bug: https://jbs.oracle.com/bugs/browse/JDK-8017333 The open URL to view this bug is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017333 which is failing the regression test you added for: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8a143213c65 You used a really old version of the test framework (pre-2003!) which doesn't output both the client and server exceptions. I've updated the test to use the new framework, and would like to put this back as a temporary measure so we can see what is really happening from any possible swallowed exceptions. Xuelei/I are stumped as to what might be happening, so hopefully this action will give some clarity. 8019341: Update CookieHttpsClientTest to use the newer framework. http://cr.openjdk.java.net/~wetmore/8019341/webrev.00/ Improving the exception handling seems mostly reasonable. It looks like startServer() and startClient() now both try to catch any exceptions and store them in variables for later processing. But they still are declared to throw Exception, and the code that calls them from the constructor throws away any exception that's caught there. Hm, it's hard to know what exception might be caught at that point, but since we don't really know what's going on, we probably shouldn't rule anything out. Most places catch Exception. One possibility to consider is whether an Error of some type might be thrown, which isn't caught by catch (Exception) clauses. In the place where you potentially have two exceptions to report, you might consider using the suppressed exception mechanism. This is bending the semantics a bit, but if the client is subordinate to the server (or vice versa) and both throw exceptions, only one can be propagated, so it could seem somewhat proper to consider one exception to have suppressed the other. It would be easiest to compare your test to the test/sun/security/ssl/templates/SSLSocketTemplate.java. They should be the same except for your test-specific code. Hm, a template-based framework? Might be worth investigating turning this into a library at some point. Brad P.S. I think AlanB/JoeD/StuartM will appreciate this effort. ;) Yes, indeed. :-) s'marks
hg: jdk8/tl/jdk: 8019359: To comment why not use no_renegotiation to reject client initiated renegotiation
Changeset: 60d1994f63f7 Author:xuelei Date: 2013-06-27 19:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60d1994f63f7 8019359: To comment why not use no_renegotiation to reject client initiated renegotiation Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/ServerHandshaker.java
