Re: RFR: JDK-8065078 - NetworkInterface.getNetworkInterfaces() triggers intermittent test failures
On 4 Mar 2015, at 21:53, Mark Sheppard wrote: > Hi > please oblige and review the following small change > http://cr.openjdk.java.net/~msheppar/8065078/webrev/ I agree with the increased buffer size, and the strategy you have employed. I think you just need to remove a few comments, otherwise looks fine to me. -Chris. > to address the issue raised in > https://bugs.openjdk.java.net/browse/JDK-8065078 > > the getAdapters and getAdpater functions were amended in > to add additional diagnostic of the error code, in the event of a > failure, following the second invocation of GetAdpatersAddresses in the call > flows. > This has shown that the ERROR_BUFFER_OVERFLOW (i.e. 111) > can occur even though the buffer, to hold the addresses, has been realloced > to the size as per that returned in the variable len > from the initial GetAdapatersAddresses. Thus, it is possible to have a "race > condition" where > configuration changes are taking place simultaneously to > the NetworkInterface.getNetworkInterfaces() call > > The proposed change increases the initial size of the addresses buffer to > 4096, > and in the event of a failure increases the returned buffer size by this > amount again. > > Additionally, the update of the static variable bufsize, after the realloc, > was seen as potentially problematic > and has thread safe implications, so these updates have been removed. The > shared variable is not protected > by a mutex during read and write of variable. > > regards > Mark
Re: RFR: JDK-8065078 - NetworkInterface.getNetworkInterfaces() triggers intermittent test failures
thanks for the review Chris regards Mark On 05/03/2015 14:09, Chris Hegarty wrote: On 4 Mar 2015, at 21:53, Mark Sheppard wrote: Hi please oblige and review the following small change http://cr.openjdk.java.net/~msheppar/8065078/webrev/ I agree with the increased buffer size, and the strategy you have employed. I think you just need to remove a few comments, otherwise looks fine to me. -Chris. to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8065078 the getAdapters and getAdpater functions were amended in to add additional diagnostic of the error code, in the event of a failure, following the second invocation of GetAdpatersAddresses in the call flows. This has shown that the ERROR_BUFFER_OVERFLOW (i.e. 111) can occur even though the buffer, to hold the addresses, has been realloced to the size as per that returned in the variable len from the initial GetAdapatersAddresses. Thus, it is possible to have a "race condition" where configuration changes are taking place simultaneously to the NetworkInterface.getNetworkInterfaces() call The proposed change increases the initial size of the addresses buffer to 4096, and in the event of a failure increases the returned buffer size by this amount again. Additionally, the update of the static variable bufsize, after the realloc, was seen as potentially problematic and has thread safe implications, so these updates have been removed. The shared variable is not protected by a mutex during read and write of variable. regards Mark
[9] RFR: 8073430: Deprecate security APIs that have been superseded
webrev: http://cr.openjdk.java.net/~juh/8073430/00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8073430 Please review this change, which deprecates the classes in java.security.acl and javax.security.cert. These packages have been superseded by replacements for a long time. For java.security.acl, there have been replacement APIs available since JDK 1.2 in java.security.Policy and related classes. For javax.security.cert, replacements have existed in java.security.cert since JDK 1.4. These replacements have been noted in the javadocs, so applications using these old APIs have had plenty of time to migrate. Two methods HandshakeCompletedEvent.getPeerCertificateChain SSLSession.getPeerCertificateChain that return the javax.security.cert.X509Certificate type will also be deprecated. The change also includes deprecation warning suppression in a few areas, including sun.net.www.protocol.https. Thanks, Jason
RE: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id
Hi, I'm afraid you have the wrong Michael McMahon. -Original Message- From: Konstantin Shefov Sent: Monday, December 15, 2014 6:16 AM To: Ivan Gerasimov; net-dev@openjdk.java.net; core-libs-...@openjdk.java.net; Alan Bateman; Chris Hegarty; MICHAEL.MCMAHON Subject: Re: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id Gently reminder. Please review. -Konstantin On 11.12.2014 14:09, Konstantin Shefov wrote: > CC'ed core-libs-...@openjdk.java.net > > On 10.12.2014 18:21, Konstantin Shefov wrote: >> Hello, >> >> Please, review the bug fix: >> https://bugs.openjdk.java.net/browse/JDK-6933879 >> Webrev: http://cr.openjdk.java.net/~kshefov/6933879/webrev.00 >> >> It is suggested to add some more symbols allowed for scope id in IPv6 >> URI, namely "_", "." and ":", because these symbols may be included >> in network interface names. Now only alphanumeric characters are >> allowed to be in a scope id. >> >> Thanks >> -Konstantin >
Re: [9] RFR: 8073430: Deprecate security APIs that have been superseded
Looks good, Jason, just a couple of comments:
- Add an @Deprecated annotation to the package-info.java files since the
entire package is deprecated. Put {@code} around the package/class names.
- add a noreg label to the bug
--Sean
On 03/04/2015 02:02 PM, Jason Uh wrote:
webrev: http://cr.openjdk.java.net/~juh/8073430/00/
jbs: https://bugs.openjdk.java.net/browse/JDK-8073430
Please review this change, which deprecates the classes in
java.security.acl and javax.security.cert. These packages have been
superseded by replacements for a long time.
For java.security.acl, there have been replacement APIs available since
JDK 1.2 in java.security.Policy and related classes. For
javax.security.cert, replacements have existed in java.security.cert
since JDK 1.4. These replacements have been noted in the javadocs, so
applications using these old APIs have had plenty of time to migrate.
Two methods
HandshakeCompletedEvent.getPeerCertificateChain
SSLSession.getPeerCertificateChain
that return the javax.security.cert.X509Certificate type will also be
deprecated.
The change also includes deprecation warning suppression in a few areas,
including sun.net.www.protocol.https.
Thanks,
Jason
Re: [9] RFR: 8073430: Deprecate security APIs that have been superseded
Hi Max,
A couple of these, we probably won't be able to remove in JDK 9. I'm
deprecating getPeerCertificateChain() in the javax.net.ssl.SSLSession
interface in this change, so the implementation in
sun.security.ssl.SSLSessionImpl will have to be suppressed. Also,
X509V1CertImpl will probably have to be marked with @SupressWarnings in
JDK 9 and then hopefully it can be removed altogether in JDK 10 along
with javax.security.cert.
As for some of the other methods causing warnings, I think they can
actually be removed, but I'd like to track that change in a different
issue. I'm not sure yet, but there might have to be some minor test
changes to accommodate the changes, too. I filed an issue to track it:
https://bugs.openjdk.java.net/browse/JDK-8074531
For now, here are my changes again with Sean's suggested changes to the
package-info.java files.
http://cr.openjdk.java.net/~juh/8073430/01/
Thanks,
Jason
On 03/04/2015 07:14 PM, Wang Weijun wrote:
Hi Jason
I noticed several "@SuppressWarnings("deprecation")" in some sun.* or com.sun.*
classes and it makes me feel uncomfortable. The usage of this annotation, if I understand
correctly, means we know we should not use it but we have to use it because we are lazy or there
are no better alternatives. I highly doubt if any is the case here.
So, we should investigate how those methods are used. If they are strictly
internal (not jdk.exported) and not used inside JDK, remove them since they
will be inaccessible anymore in jdk9. If they are still used somewhere,
consider rewriting them (maybe in another fix). If they are jdk.exported,
rewrite if the deprecated interfaces is not shown in the API itself (type or
argument or return), otherwise, @deprecate them also.
Thanks
Max
On Mar 5, 2015, at 03:02, Jason Uh wrote:
webrev: http://cr.openjdk.java.net/~juh/8073430/00/
jbs: https://bugs.openjdk.java.net/browse/JDK-8073430
Please review this change, which deprecates the classes in java.security.acl
and javax.security.cert. These packages have been superseded by replacements
for a long time.
For java.security.acl, there have been replacement APIs available since JDK 1.2
in java.security.Policy and related classes. For javax.security.cert,
replacements have existed in java.security.cert since JDK 1.4. These
replacements have been noted in the javadocs, so applications using these old
APIs have had plenty of time to migrate.
Two methods
HandshakeCompletedEvent.getPeerCertificateChain
SSLSession.getPeerCertificateChain
that return the javax.security.cert.X509Certificate type will also be
deprecated.
The change also includes deprecation warning suppression in a few areas,
including sun.net.www.protocol.https.
Thanks,
Jason
Re: [9] RFR: 8073430: Deprecate security APIs that have been superseded
Instead of adding @SupressWarnings to a method, can we add @Deprecated to it? If I understand correctly, there should be no warning if a deprecated method calls another deprecated method. And by deprecating the caller we will get warnings if they are called by more methods and we can evaluate if they can be further deprecated or modified. This way we would reveal everything that is related with the deprecated APIs. Hopefully they are actually useless inside JDK. --Max > On Mar 6, 2015, at 12:01, Jason Uh wrote: > > Hi Max, > > A couple of these, we probably won't be able to remove in JDK 9. I'm > deprecating getPeerCertificateChain() in the javax.net.ssl.SSLSession > interface in this change, so the implementation in > sun.security.ssl.SSLSessionImpl will have to be suppressed. Also, > X509V1CertImpl will probably have to be marked with @SupressWarnings in JDK 9 > and then hopefully it can be removed altogether in JDK 10 along with > javax.security.cert. > > As for some of the other methods causing warnings, I think they can actually > be removed, but I'd like to track that change in a different issue. I'm not > sure yet, but there might have to be some minor test changes to accommodate > the changes, too. I filed an issue to track it: > https://bugs.openjdk.java.net/browse/JDK-8074531 > > For now, here are my changes again with Sean's suggested changes to the > package-info.java files. > http://cr.openjdk.java.net/~juh/8073430/01/ > > Thanks, > Jason
Re: [9] RFR: 8073430: Deprecate security APIs that have been superseded
What is the policy for deprecating a non-public-API method? > On Mar 6, 2015, at 13:30, Wang Weijun wrote: > > Instead of adding @SupressWarnings to a method, can we add @Deprecated to it?
