RFR 8072996: Deprecate stream-based GSSContext methods

RFC 8353 has removed stream-based GSSContext methods [1]. Therefore we deprecate them in JDK. Please take a review at webrev: http://cr.openjdk.java.net/~weijun/8072996/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8202953 Thanks Max [1] https://tools.ietf.org/html/rfc8353#s

RFR 8177334: Update xmldsig implementation to Apache Santuario 2.1.1

Please review the change at webrev: http://cr.openjdk.java.net/~weijun/8177334/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8203460 New features include the support of SHA-224 and SHA-3 MessageMethod, and RSASSA-PSS SignatureMethods. The change is done in 2 steps: 1. Copying

Re: RFR 8201815: Use Mozilla Public Suffix List

Good. It's now simply $(GENDATA_PUBLICSUFFIXLIST): $(GENDATA_PUBLICSUFFIXLIST_SRC) $(BUILD_TOOLS) $(call LogInfo, Generating public suffix list) $(call MakeDir, $(@D)) $(RM) $@ $(TOOL_PUBLICSUFFIXLIST) $< $@ $(CHMOD) 444 $@ Thanks Max > On May 24, 2018, at 12:30 AM, Erik Joelsson

Re: RFR CSR 8203460: Update xmldsig implementation to latest version of Apache Santuario

Updated. I'm now using uri.substr(uri.indexOf("#") + 1).toUpperCase() as the names. Thanks Max > On May 24, 2018, at 4:47 AM, Sean Mullan wrote: > > I don't think you should change the names of the algorithms to the JCE style > (eg: SHA1withDSA). You should keep the names as defined by the W3

Re: RFR CSR 8203460: Update xmldsig implementation to latest version of Apache Santuario

I don't think you should change the names of the algorithms to the JCE style (eg: SHA1withDSA). You should keep the names as defined by the W3C Recommendation and related RFCs. Even if the naming convention is different than JCE, these are the names that were chosen by the standards bodies and

Re: RFR 8201815: Use Mozilla Public Suffix List

On 2018-05-23 03:54, Magnus Ihse Bursie wrote: mv should not modify attributes. cp will, but mv should not. Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anythin

Re: Signature from User-specified URIDereferencers NodeSetData objects is wrong

Hi Sean, Thanks for your reply. I tried with the input that were given by you to use XPathFilter2Transform with an XPathFilter2ParameterSpec. But the thing is in output XML, Under signature tag I am getting the following output:: ---Source-start

Re: RFR[11] JDK-8203686: Add JDK 11 major version to javax/net/ssl/compatibility/JdkRelease.java

Looks fine to me. Thanks! Xuelei On 5/23/2018 12:03 AM, sha.ji...@oracle.com wrote: Hi, javax/net/ssl/compatibility/JdkRelease.java has to include the latest JDK major release, namely JDK 11; otherwise, manual test javax/net/ssl/compatibility/Compatibility.java cannot run on JDK 11 builds.

Re: RFR 8201815: Use Mozilla Public Suffix List

mv should not modify attributes. cp will, but mv should not. Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anything is missing. I believe the other cases that y

RFR[11] JDK-8203686: Add JDK 11 major version to javax/net/ssl/compatibility/JdkRelease.java

Hi, javax/net/ssl/compatibility/JdkRelease.java has to include the latest JDK major release, namely JDK 11; otherwise, manual test javax/net/ssl/compatibility/Compatibility.java cannot run on JDK 11 builds. Webrev: http://cr.openjdk.java.net/~jjiang/8203686/webrev.00/ Issue: https://bugs.openj