JDK RFR of 8054720: Modifications of I/O methods for instrumentation purposes
JDK 9 reviewers: I would like to request the review of this patch to address the indicated issue: Issue: https://bugs.openjdk.java.net/browse/JDK-8054720 Patch: http://cr.openjdk.java.net/~bpb/8054720/ This changes passes the jdk_io and jdk_net tests on all platforms. Thanks, Brian
On 11/08/2014 20:51, Brian Burkhalter wrote:
JDK 9 reviewers:
I would like to request the review of this patch to address the indicated issue:
Issue: https://bugs.openjdk.java.net/browse/JDK-8054720 Patch: http://cr.openjdk.java.net/~bpb/8054720/
This changes passes the jdk_io and jdk_net tests on all platforms.
This looks okay except SSLSocketImpl#isLayered (not clear why the override is needed). -Alan.
On Aug 11, 2014, at 1:10 PM, Alan Bateman <Alan.Bateman@oracle.com> wrote:
This looks okay except SSLSocketImpl#isLayered (not clear why the override is needed).
This is needed as it may be required to instrument sun.security.ssl.SSLSocketImpl.closeSocket() in which the knowledge of whether the socket is layered has a bearing on the behavior. Brian
I'd like to propose some sort of comment (non-javadoc) preceding the methods to explain the pattern. Without the institutional day-to-day knowledge, I don't think it is apparent to an outside reader why these methods are crafted as such. The comment can be as simple as: // wrap native call to allow instrumentation Cheers, Paul On Mon, Aug 11, 2014 at 4:29 PM, Brian Burkhalter < brian.burkhalter@oracle.com> wrote:
On Aug 11, 2014, at 1:10 PM, Alan Bateman <Alan.Bateman@oracle.com> wrote:
This looks okay except SSLSocketImpl#isLayered (not clear why the override is needed).
This is needed as it may be required to instrument sun.security.ssl.SSLSocketImpl.closeSocket() in which the knowledge of whether the socket is layered has a bearing on the behavior.
Brian
Sounds like a good idea. I’ll add something in the next version of the patch. Thanks, Brian On Aug 12, 2014, at 6:42 AM, Paul Benedict <pbenedict@apache.org> wrote:
I'd like to propose some sort of comment (non-javadoc) preceding the methods to explain the pattern. Without the institutional day-to-day knowledge, I don't think it is apparent to an outside reader why these methods are crafted as such.
The comment can be as simple as: // wrap native call to allow instrumentation
On 11/08/2014 22:29, Brian Burkhalter wrote:
On Aug 11, 2014, at 1:10 PM, Alan Bateman <Alan.Bateman@oracle.com> wrote:
This looks okay except SSLSocketImpl#isLayered (not clear why the override is needed). This is needed as it may be required to instrument sun.security.ssl.SSLSocketImpl.closeSocket() in which the knowledge of whether the socket is layered has a bearing on the behavior. So are you instrumenting isLayered in sub-class or just calling it? I ask because just calling it should work.
-Alan
participants (3)
-
Alan Bateman
-
Brian Burkhalter
-
Paul Benedict