hg: jdk8/tl/jdk: 8015299: Memory leak in jdk/src/solaris/bin/java_md_solinux.c
Changeset: 6df9b071b04d Author:jzavgren Date: 2013-05-30 12:19 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6df9b071b04d 8015299: Memory leak in jdk/src/solaris/bin/java_md_solinux.c Reviewed-by: martin, dholmes, chegar, ksrini ! src/solaris/bin/java_md_solinux.c
RFR 7107883: getNetworkPrefixLength() does not return correct prefix length
The Unix native implementation that determines the network interface's broadcast address and network prefix/subnet mask, incorrectly ties the mask to the existence of a broadcast address. This should be changed so that the network prefix/subnet mask, if available, is exposed through the Java API, getNetworkPrefixLength, regardless of the broadcast address. http://cr.openjdk.java.net/~chegar/7107883/webrev.00/webrev/ Creating a reliable automatic regression test for this be problematic. Also, there is already an existing test that verify that getNetworkPrefixLength returns values within specified bounds. This issue can be easily seen with the loopback interface: >: ifconfig lo loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:722 errors:0 dropped:0 overruns:0 frame:0 TX packets:722 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:102346 (102.3 KB) TX bytes:102346 (102.3 KB) >: binaries/jdk1.7.0_07/bin/java Test lo <0:0:0:0:0:0:0:1%1> getBroadcast():null getNetworkPrefixLength():128 <127.0.0.1> getBroadcast():null getNetworkPrefixLength():0 -Chris.
Re: RFR 7107883: getNetworkPrefixLength() does not return correct prefix length
On 30/05/2013 12:53, Chris Hegarty wrote: The Unix native implementation that determines the network interface's broadcast address and network prefix/subnet mask, incorrectly ties the mask to the existence of a broadcast address. This should be changed so that the network prefix/subnet mask, if available, is exposed through the Java API, getNetworkPrefixLength, regardless of the broadcast address. http://cr.openjdk.java.net/~chegar/7107883/webrev.00/webrev/ Creating a reliable automatic regression test for this be problematic. Also, there is already an existing test that verify that getNetworkPrefixLength returns values within specified bounds. This issue can be easily seen with the loopback interface: >: ifconfig lo loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:722 errors:0 dropped:0 overruns:0 frame:0 TX packets:722 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:102346 (102.3 KB) TX bytes:102346 (102.3 KB) >: binaries/jdk1.7.0_07/bin/java Test lo <0:0:0:0:0:0:0:1%1> getBroadcast():null getNetworkPrefixLength():128 <127.0.0.1> getBroadcast():null getNetworkPrefixLength():0 -Chris. This looks fine to me. -Alan
Re: RFR 7107883: getNetworkPrefixLength() does not return correct prefix length
The change looks fine. Do you think it would be possible to make a test case by using the loopback interface, when it's available and when it doesn't have a broadcast address, which is probably a very common situation? Michael On 30/05/13 12:53, Chris Hegarty wrote: The Unix native implementation that determines the network interface's broadcast address and network prefix/subnet mask, incorrectly ties the mask to the existence of a broadcast address. This should be changed so that the network prefix/subnet mask, if available, is exposed through the Java API, getNetworkPrefixLength, regardless of the broadcast address. http://cr.openjdk.java.net/~chegar/7107883/webrev.00/webrev/ Creating a reliable automatic regression test for this be problematic. Also, there is already an existing test that verify that getNetworkPrefixLength returns values within specified bounds. This issue can be easily seen with the loopback interface: >: ifconfig lo loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:722 errors:0 dropped:0 overruns:0 frame:0 TX packets:722 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:102346 (102.3 KB) TX bytes:102346 (102.3 KB) >: binaries/jdk1.7.0_07/bin/java Test lo <0:0:0:0:0:0:0:1%1> getBroadcast():null getNetworkPrefixLength():128 <127.0.0.1> getBroadcast():null getNetworkPrefixLength():0 -Chris.
hg: jdk8/tl/jdk: 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder
Changeset: 156ee44cd456 Author:psandoz Date: 2013-05-30 16:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/156ee44cd456 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder Summary: Also fixes documentation on StreamBuilder.OfDouble Reviewed-by: alanb, chegar, mduigou ! src/share/classes/java/util/stream/StreamBuilder.java
hg: jdk8/tl/jdk: 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst()
Changeset: b4742d038100 Author:psandoz Date: 2013-05-28 15:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4742d038100 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst() Reviewed-by: alanb, chegar ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java
Re: RFR 7107883: getNetworkPrefixLength() does not return correct prefix length
On 05/30/2013 02:54 PM, Michael McMahon wrote: The change looks fine. Do you think it would be possible to make a test case by using the loopback interface, when it's available and when it doesn't have a broadcast address, which is probably a very common situation? I think the IPv4 loopback address should always have a prefix of 8. So the test would look like : http://cr.openjdk.java.net/~chegar/7107883/webrev.01/webrev/test/java/net/InterfaceAddress/NetworkPrefixLength.java.udiff.html -Chris. Michael On 30/05/13 12:53, Chris Hegarty wrote: The Unix native implementation that determines the network interface's broadcast address and network prefix/subnet mask, incorrectly ties the mask to the existence of a broadcast address. This should be changed so that the network prefix/subnet mask, if available, is exposed through the Java API, getNetworkPrefixLength, regardless of the broadcast address. http://cr.openjdk.java.net/~chegar/7107883/webrev.00/webrev/ Creating a reliable automatic regression test for this be problematic. Also, there is already an existing test that verify that getNetworkPrefixLength returns values within specified bounds. This issue can be easily seen with the loopback interface: >: ifconfig lo loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:722 errors:0 dropped:0 overruns:0 frame:0 TX packets:722 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:102346 (102.3 KB) TX bytes:102346 (102.3 KB) >: binaries/jdk1.7.0_07/bin/java Test lo <0:0:0:0:0:0:0:1%1> getBroadcast():null getNetworkPrefixLength():128 <127.0.0.1> getBroadcast():null getNetworkPrefixLength():0 -Chris.
RFR: 8014723: sun/misc/URLClassPath/ClassnameCharTest.java failing
http://cr.openjdk.java.net/~michaelm/8014723/webrev.1/ regression caused by the HttpURLPermission implemenation not using the raw URI accessor methods. Some other changes are coming to this class, but I just want to fix this problem separately. Thanks Michael
Re: RFR: 8014723: sun/misc/URLClassPath/ClassnameCharTest.java failing
This also fixes 8014720. So, I should have included the removal of the relevant test from ProblemList.txt diff -r b4742d038100 test/ProblemList.txt --- a/test/ProblemList.txtTue May 28 15:22:30 2013 +0200 +++ b/test/ProblemList.txtThu May 30 18:04:17 2013 +0100 @@ -199,12 +199,6 @@ # 7143960 java/net/DatagramSocket/SendDatagramToBadAddress.java macosx-all -# 8014720 -java/net/ResponseCache/B6181108.java generic-all - -# 8014723 -sun/misc/URLClassPath/ClassnameCharTest.java generic-all - # 8014719 sun/net/www/http/HttpClient/ProxyTest.java generic-all On 30/05/13 17:49, Michael McMahon wrote: http://cr.openjdk.java.net/~michaelm/8014723/webrev.1/ regression caused by the HttpURLPermission implemenation not using the raw URI accessor methods. Some other changes are coming to this class, but I just want to fix this problem separately. Thanks Michael
hg: jdk8/tl/jdk: 8015271: Conversion table for EUC-KR is incorrect
Changeset: b588955b7e5b Author:sherman Date: 2013-05-30 14:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b588955b7e5b 8015271: Conversion table for EUC-KR is incorrect Summary: to add the requested postal code mark character u+327e Reviewed-by: alanb ! make/tools/CharsetMapping/EUC_KR.map
hg: jdk8/tl/jdk: 8014618: Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement
Changeset: 6407106f1b1c Author:xuelei Date: 2013-05-30 22:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6407106f1b1c 8014618: Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement Reviewed-by: xuelei Contributed-by: Pasi Eronen ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/P11Util.java ! src/share/classes/sun/security/util/KeyUtil.java + test/com/sun/crypto/provider/TLS/TestLeadingZeroes.java + test/sun/security/pkcs11/tls/TestLeadingZeroesP11.java
hg: jdk8/tl/jdk: 7160837: DigestOutputStream does not turn off digest calculation when "close()" is called
Changeset: 8402ef8fabde Author:ascarpino Date: 2013-05-30 22:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8402ef8fabde 7160837: DigestOutputStream does not turn off digest calculation when "close()" is called Reviewed-by: mullan, xuelei ! src/share/classes/java/security/DigestOutputStream.java ! src/share/classes/javax/crypto/CipherInputStream.java ! src/share/classes/javax/crypto/CipherOutputStream.java + test/javax/crypto/Cipher/CipherStreamClose.java
hg: jdk8/tl/jdk: 8013069: javax.crypto tests fail with new PBE algorithm names
Changeset: 6cb09d3cd309 Author:valeriep Date: 2013-05-29 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cb09d3cd309 8013069: javax.crypto tests fail with new PBE algorithm names Summary: Shouldn't auto-generate default parameters for MAC objects. Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! test/com/sun/crypto/provider/Mac/HmacPBESHA1.java ! test/com/sun/crypto/provider/Mac/MacClone.java
hg: jdk8/tl/jdk: 6750584: Cipher.wrap/unwrap methods should define UnsupportedOperationException
Changeset: 918d9ac17740 Author:ascarpino Date: 2013-05-30 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/918d9ac17740 6750584: Cipher.wrap/unwrap methods should define UnsupportedOperationException Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/CipherSpi.java
