On 01/10/13 19:59, Brian Burkhalter wrote:
On Oct 1, 2013, at 11:50 AM, Alan Bateman wrote:
On 01/10/2013 11:31, Brian Burkhalter wrote:
Hello net-dev members,
Please review this proposed fix at your convenience.
Summary
When looking up a host and an EAGAIN error is encountered, throw an ins
On 02/10/13 15:40, Chris Hegarty wrote:
On 02/10/2013 04:44, Alan Bateman wrote:
On 01/10/2013 12:46, Brian Burkhalter wrote:
:
I updated the webrev
http://cr.openjdk.java.net/~bpb/8010371/
with changes in the test of the return value of getaddrinfo for Unix
Inet 4 and 6 and Windows Inet 6.
Hi,
This is primarily a spec. change to the new HttpURLPermission class.
The main changes are:
1. Rename java.net.HttpURLPermission to java.net.URLPermission.
Even though the class is clearly intended for use with Http/s URLs it
isn't restricted
to those URL schemes.
2. Add some of the capa
waiting for that change.
Right Andreas. I made the first change just before sending the webrev.
Thanks for pointing it out.
Michael.
- Andreas
On 02.10.2013 18:12, Michael McMahon wrote:
Hi,
This is primarily a spec. change to the new HttpURLPermission class.
The main changes are:
1. Rename
Hi,
This change updates HttpURLPermission to grant a SocketPermission with a
literal IP address
rather than the String hostname when the IP address is available (this
gets looked up anyway.
So, we're not adding any additional name service lookups). By granting a
permission with
a literal IP ad
Can I get the following change for jdk 8 reviewed please?
It's a simple build change to enable compilation of the dummy
SCTP API layer on macosx, plus the dummy implementation
used on windows.
The existing jdk_sctp tests cover this.
http://cr.openjdk.java.net/~michaelm/7076487/webrev.1/
Thanks
On 10/10/13 12:01, Alan Bateman wrote:
On 10/10/2013 11:10, Michael McMahon wrote:
Can I get the following change for jdk 8 reviewed please?
It's a simple build change to enable compilation of the dummy
SCTP API layer on macosx, plus the dummy implementation
used on windows.
The exi
I agree. The change looks fine to me.
Thanks
Michael
On 23/10/13 12:09, Chris Hegarty wrote:
Mark, Michael,
java.net.HttpCookie, rightly or wrongly, supports three different
Cookie specifications. Some of these are conflicting, and there have
been many many bugs reported against various "spe
Interesting little bug this one. The precedence rules
were overlooked and the expected result of an expression evaluation
wasn't what was expected. The webrev is below, but the diff is
diff -r 9a5048dc7c0d src/share/classes/java/net/URLPermission.java
--- a/src/share/classes/java/net/URLPermissio
Thanks Chris. I'll add the bug number
Michael
On 30/10/13 17:52, Chris Hegarty wrote:
Looks good to me Michael.
Trivially, the test could include this bug number in its @bug tag.
-Chris
On 30 Oct 2013, at 16:51, Michael McMahon wrote:
Interesting little bug this one. The precedence
Simple bug fix to new URLPermission class, caused by insufficient
parameter checking
of the constructor.
webrev: http://cr.openjdk.java.net/~michaelm/8027687/webrev.1/
Thanks,
Michael
ded IDNs in the test okay.
Thanks!
Michael
Mike
On Nov 1 2013, at 07:46 , Michael McMahon wrote:
Simple bug fix to new URLPermission class, caused by insufficient parameter
checking
of the constructor.
webrev: http://cr.openjdk.java.net/~michaelm/8027687/webrev.1/
Thanks,
Michael
g the stringbuilder) but is that a common case? If this isn't
perf sensitive then disregard.
Thanks
Sent from my phone
On Nov 1, 2013 4:28 PM, "Michael McMahon"
mailto:michael.x.mcma...@oracle.com>>
wrote:
On 01/11/13 18:06, Mike Duigou wrote:
A couple minor qui
On 04/11/13 18:05, mark.reinh...@oracle.com wrote:
2013/11/4 1:49 -0800, michael.x.mcma...@oracle.com:
Changeset: 48449b5390fa
Author:michaelm
Date: 2013-11-04 17:47 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48449b5390fa
8027687: The constructors of URLPermission clas
On 05/11/13 19:38, Chris Hegarty wrote:
Another installment of checks for return values from
GetFieldID, and friends, to follow up on last weeks work [1].
http://cr.openjdk.java.net/~chegar/netNullChecks/webrev/
There are more cleanups to come along the same lines, but I'd like to
keep these c
On 05/11/13 20:49, Chris Hegarty wrote:
On 5 Nov 2013, at 20:39, Michael McMahon wrote:
On 05/11/13 19:38, Chris Hegarty wrote:
Another installment of checks for return values from
GetFieldID, and friends, to follow up on last weeks work [1].
http://cr.openjdk.java.net/~chegar/netNullChecks
This is a test fix. The test currently uses a fixed port number
(in the policy file and Java test)
We need to change to use a shell script so that a port can be
chosen dynamically and the appropriate policy file created.
The change also adds the correct bug number to a different test
change I pu
Chris,
Would it be useful to add some instrumentation/logging (to System.err)
if it's taking
more than one iteration to delete a file? We could end up with degraded
test performance if there is a general problem deleting files, and
otherwise would have
no way of understanding what the problem
On 07/11/13 11:34, Chris Hegarty wrote:
On 11/07/2013 11:19 AM, Michael McMahon wrote:
Chris,
Would it be useful to add some instrumentation/logging (to System.err)
if it's taking
more than one iteration to delete a file? We could end up with degraded
test performance if there is a ge
Ah, I noticed this today. Thanks for fixing it so quickly.
Michael
On 08/11/13 20:43, Chris Hegarty wrote:
The change looks good to me.
Thanks for spotting this and jumping on it so quickly.
-Chris.
On 08/11/2013 20:39, Alan Bateman wrote:
There's a small problem with the fix for JDK- 8019
This is a fix to a test case that is failing on Windows.
A couple of problems:
1) cygwin doesn't like the newline at the end of the port number that
gets printed to System.out
2) the calling script was not setting the classpath separator correctly
(';' for windows)
http://cr.openjdk.java.ne
This is a test that just failed recently on Windows, probably due to a
timing issue.
The critical time delay in the test is increased from 5 seconds to 10
seconds
and some extra printlns are added to show the exact sequence in case it
fails again.
http://cr.openjdk.java.net/~michaelm/8028581/w
Hi,
java.net.URLPermission does not currently take account of the "userinfo"
component
in the authority of a URL. So, it does not accept URLs of the form
"http://username@host/blah";
http://cr.openjdk.java.net/~michaelm/8029354/webrev.1/
which includes a small spec change to account for this
This is another regression in JDK 8. A new "connecting" flag is getting
confused
when a redirect occurs and a POST gets converted to a GET.
http://cr.openjdk.java.net/~michaelm/8029127/webrev.1/
Thanks
Michael.
ichael
Thanks
Max
On 11/30/13, 1:06, Michael McMahon wrote:
Hi,
java.net.URLPermission does not currently take account of the "userinfo"
component
in the authority of a URL. So, it does not accept URLs of the form
"http://username@host/blah";
http://cr.openjdk.java.net/
On 29/11/13 20:38, Alan Bateman wrote:
On 29/11/2013 18:03, Michael McMahon wrote:
This is another regression in JDK 8. A new "connecting" flag is
getting confused
when a redirect occurs and a POST gets converted to a GET.
http://cr.openjdk.java.net/~michaelm/8029127/webrev.1/
, to see how this situation arose in the
first place.
Michael
On 02/12/13 10:41, Weijun Wang wrote:
Is it possible to just ignore the userinfo part? I wonder if people
will complain why "user:pass" is not the same as "user".
--Max
On 12/2/13, 18:00, Michael McMahon wro
itself. That doesn't
prevent higher level software from
using it, as in the case here that provoked the bug report (the Java GIT
client used in netbeans and eclipse)
Michael
On 02/12/13 11:00, Michael McMahon wrote:
It looks like userinfo is not permitted in http URLs anyway (in rfc
2616)
On 02/12/13 12:17, Weijun Wang wrote:
On 12/2/13, 19:00, Michael McMahon wrote:
It looks like userinfo is not permitted in http URLs anyway (in rfc
2616). And even if clients
are permissive about allowing it, any userinfo would most likely not be
seen by a server
since the request URI only
On 02/12/13 12:40, Alan Bateman wrote:
On 02/12/2013 12:22, Michael McMahon wrote:
Okay. I think the best approach is to recognise the userinfo but just
remove it when constructing
URLPermissions thereby effectively ignoring it.
This is what the http protocol handler (and other support
On 02/12/13 15:21, Alan Bateman wrote:
On 02/12/2013 14:33, Michael McMahon wrote:
The second webrev is at link below. This is somewhat simpler now.
I think it still needs a spec change though. So, I would like to propose
that to the CCC asap.
http://cr.openjdk.java.net/~michaelm/8029354
Yes, looks good Dan. I presume this is going into 9 rather than 8 though...?
Michael.
On 12/12/13 05:14, Dan Xu wrote:
Hi All,
Please review the fix for the JNI pending exception issue in
src/solaris/native/sun/net/spi/DefaultProxySelector.c. I have
refactored the code so that JNI calls will
On 18/12/13 16:27, Alan Bateman wrote:
On 18/12/2013 16:19, Mark Sheppard wrote:
potentially the same issue with
TwoStacksPlainDatagramSocketImpl
for an IPV6 address.
as I have only ever enabled TwoStack via -Djava.net.preferIPv4Stack=true
then the sockaddr_in is sufficient to hold an IPV4 ad
http://cr.openjdk.java.net/~michaelm/8029354/9/webrev.1/
This is the forward port to JDK 9. The patch from 8 applies cleanly.
Thanks,
Michael
On 07/01/14 17:44, Alan Bateman wrote:
On 07/01/2014 17:36, Joe Darcy wrote:
Hello,
Please review these changes to remove use of raw Class in some method
signatures in java.net:
JDK-8031326: Use Class rather than Class in java.net
method signatures
Patch below.
This looks okay to
On 10/01/14 15:37, roger riggs wrote:
Please review:
To enable native code checking consistently for thrown exceptions,
the macros in net_util.h and java/util/jar/pack/coding.cpp are
made consolidated and promoted to jni_util.h
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8
Looks good!
Michael.
On 31/01/14 10:52, Chris Hegarty wrote:
This is a trivial test only change to make it agnostic of system proxy
setting on OS X. The test requires that it makes a direct connection
to the self contained trivial test HTTP server, it should not be
influenced by system proxy
Could I get this change reviewed for JDK 8 please?
http://cr.openjdk.java.net/~michaelm/8033425/webrev.1/
The problem affects appletviewer, but it doesn't seem to
be reproducible with the applet support in jtreg. So,
hence there is no regression test.
Michael
Adding some checks for pending exceptions in the InetAddress native code.
http://cr.openjdk.java.net/~michaelm/8028725/webrev.1/
Thanks
Michael
Nice cleanup. Looks good, and thanks for catching the CHECK_NULL problem
Michael
On 04/02/14 16:12, Chris Hegarty wrote:
And a link to the webrev that can people can access:
http://cr.openjdk.java.net/~chegar/nativeInetCleanup/webrev/
-Chris.
On 02/04/2014 04:01 PM, Chris Hegarty wrote:
Hi
Looks good.
- Michael.
On 05/02/14 09:58, Chris Hegarty wrote:
Some very minor clean up in PlainDatagramSocketImpl to add some missing returns
after “throwing an exception”, as well as checking for a pending exception
after calling setTTL ( that can throw ).
http://cr.openjdk.java.net/~chega
That seems reasonable Amanda. I've run the updated test for a while and
I can't see any problem with it.
Thanks,
Michael
On 10/02/14 08:56, Amanda Jiang wrote:
Hi All,
Please review the fix for JDK-8031661
http://cr.openjdk.java.net/~tyan/amandaj/JDK-8031661/webrev.01/
Description:
Root Caus
: Michael McMahon
Summary
---
Define and implement a new Http client API to eventually replace the legacy
HttpURLConnection and which also implements HTTP 2.0 and websockets.
Motivation
--
Problems with the existing API and implementation:
+ URLConnection based API was designed with multiple
I think it's a good idea. Before changing anything though,
we would need to:
1. identify all APIs that could potentially be affected and figure out
what is
needed for each. For instance:
1. InetAddress
2. SocketPermission
3. URLPermission
4. HttpURLConnection
5. URL/URI
On 20/02/14 03:15, Jonathan Lu wrote:
Hi Michael,
Thanks a lot for your comments.
On Wed, Feb 19, 2014 at 6:28 PM, Michael McMahon
mailto:michael.x.mcma...@oracle.com>>
wrote:
I think it's a good idea. Before changing anything though,
we would need to:
1. identi
On 23/02/14 08:55, Chris Hegarty wrote:
On 22 Feb 2014, at 17:23, Dmitry Samersoff wrote:
Chris,
Didn't look to windows part. Unix part looks good for me. See also below.
I'm a bit concerned because of mixing NET_* abstractions and direct call
to OS functions. It might be better to create NE
On 24/02/14 14:09, Chris Hegarty wrote:
On 24/02/14 10:42, Michael McMahon wrote:
On 23/02/14 08:55, Chris Hegarty wrote:
On 22 Feb 2014, at 17:23, Dmitry Samersoff
wrote:
Chris,
Didn't look to windows part. Unix part looks good for me. See also
below.
I'm a bit concerned
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8035653/webrev.1/
We overlooked one place where JNI native field initialization
is required in Windows Vista+
Thanks
Michael.
Looks good to me. The copyright date on the new src/macosx files could
be updated though.
Thanks
Michael
On 26/02/14 15:45, Seán Coffey wrote:
Looking to backport this one to jdk7u-dev. Given the different build
system, the make logic is different.
bug ID : https://bugs.openjdk.java.net/brow
On 28/02/14 14:40, Chris Hegarty wrote:
[ Volker: there are some trivial AIX changes here, maybe you could
verify them? ]
JDK-8021820 adds -D_DARWIN_UNLIMITED_SELECT to the build, but the
fd_set struct is still limited to 1024.
Snippet from man select(2):
"Although the provision of getdt
On 21/03/14 09:58, Chris Hegarty wrote:
Thanks for doing this Pavel. The changes, and test, look good to me. I
can sponsor this for you.
-Chris.
+1. Looks good here too.
Michael
On 19/03/14 18:03, Pavel Rappo wrote:
Hi everyone,
could you please review my change for JDK-8035158?
Defaul
Hi Mark,
I think in the normal case, the memory is freed by the calling
function. It looks like the other cases aren't consistent though.
Michael
On 21/03/14 14:04, Mark Sheppard wrote:
Hi Chris,
thanks for the review ... yes, the question is intentional.
the freeing of netaddrP is inconsis
My understanding is that the original PMTU discovery spec RFC 1191
is not very effective due to its reliance on ICMP messages that are often
filtered out by routers. There was an update in RFC 4821 which removes
the dependency on ICMP and that seems to be effective
I'm just wondering then how DTL
On 26/03/14 08:43, Alan Bateman wrote:
On 26/03/2014 02:58, Jonathan Lu wrote:
:
Only for the system property to configure the use of IDNs and some
related code to do the checking and conversion, no plan to add new
methods to InetAddress.
Thanks, I'm just wondering whether it would make sen
In my view, it's the current behavior that is surprising. You would
really expect
those methods to return the un-encoded strings. It's odd we haven't come
across
this issue before now, which probably indicates use of '[]' in those
components
is uncommon.
Michael
On 04/04/14 16:01, Chris Hegar
Could I get the following reviewed please?
In addition to providing generic support for java.net.SocketOption,
it also includes 8032808, which implements a platform specific
socket option SO_FLOW_SLA (in jdk.net)
There are changes to two repos:
http://cr.openjdk.java.net/~michaelm/8036979/jdk/0
Is there potential for confusion there? really just
means an "implementation defined" package rather than the Java
language's "default package"?
Michael
On 08/04/14 20:03, Chris Hegarty wrote:
java.net.URLConnection.getContent() incorrectly specifies the default location
of content handler
Chris,
Okay, I think it's fine then. The term "default package" is used, but I
accept
it's not referred to as such, in the JLS.
Thanks,
Michael
On 09/04/14 12:42, Chris Hegarty wrote:
Thanks for looking at this Michael,
On 09/04/14 11:51, Michael McMahon wrote:
Is
type equivalent methods?
2) New protected methods in SocketImpl need an @since tag.
-Chris.
On 08/04/14 18:49, Michael McMahon wrote:
Could I get the following reviewed please?
In addition to providing generic support for java.net.SocketOption,
it also includes 8032808, which implements a
Thanks Alan. All comments accepted, except as clarified below.
Michael
On 09/04/14 15:07, Alan Bateman wrote:
On 08/04/2014 18:49, Michael McMahon wrote:
Could I get the following reviewed please?
In addition to providing generic support for java.net.SocketOption,
it also includes 8032808
Looks fine to me Chris.
- Michael
On 09/04/14 18:21, Chris Hegarty wrote:
Michael, Alan
There is/was an additional reference to the implementation specific
package name in ContentHandler. It is now removed. I think this is the
last one!
Latest specdiff:
http://cr.openjdk.java.net/~chegar/
Hi,
This is the webrev for the 8u20 version of the fix that was reviewed
yesterday for 9.
JDK
===
http://cr.openjdk.java.net/~michaelm/8036979.8u20/jdk/01/webrev/
Top repo
=
http://cr.openjdk.java.net/~michaelm/8036979.8u20/top/01/webrev/
The good news is that the change is almost the sa
ague, but then again UncheckedIOException
doesn't seem right either to me, since it's something other
than an io exception in this situation.
Thanks,
Michael
-Chris.
On 10/04/14 18:13, Michael McMahon wrote:
Hi,
This is the webrev for the 8u20 version of the fix that was reviewed
Thanks Alan. Points taken. I'll add the lambda to the 9 version also.
Michael
On 11/04/14 16:04, Alan Bateman wrote:
Reflection or shared secrets is a coin toss here, I think what you
have is okay. An alternative name for the package private class in
java.net is SocketSecrets, just a suggest
I think it would be an improvement to combine these doPrivileged() blocks
as suggested, though your patch needs work Bernd. For instance,
the multi-catch doesn't work. Also the PrivilegedAction<> type is wrong.
If someone wants to update it, then we can use that. Otherwise, we'll
go with the orig
Could I get the following small change reviewed please?
It fixes a number of recently introduced lint warnings
http://cr.openjdk.java.net/~michaelm/8041397/webrev.1/
Thanks
Michael.
This fixes a recent test failure caused by the change
https://bugs.openjdk.java.net/browse/JDK-8040747
which added some new tests of the literal IP address parsing code. The
new tests are valid with respect
to the parser, but were failing on some platforms because when the
parser returns an erro
Could I get the following change reviewed please for JDK 9
(same change will apply later to 8u-dev)?
In JDK 8 we fixed a problem with Digest authentication
where some parameters were being enclosed in double quotes
incorrectly. It seems some old versions of Tomcat expect this
behavior. So, the fi
Could I get the following small test case change reviewed please?
This fixes a sporadic test case failure due to incorrect use of @build tag
in the script
--- a/test/java/net/URLPermission/nstest/lookup.sh
+++ b/test/java/net/URLPermission/nstest/lookup.sh
@@ -26,7 +26,7 @@
# @library /lib/test
On 14/05/14 11:39, Alan Bateman wrote:
On 14/05/2014 11:35, Michael McMahon wrote:
Could I get the following small test case change reviewed please?
This fixes a sporadic test case failure due to incorrect use of
@build tag
in the script
--- a/test/java/net/URLPermission/nstest/lookup.sh
On 14/05/14 14:20, Daniel Fuchs wrote:
Hi Michael,
On 5/14/14 1:11 PM, Michael McMahon wrote:
On 14/05/14 11:39, Alan Bateman wrote:
On 14/05/2014 11:35, Michael McMahon wrote:
Okay. I just updated my jtreg and the test passes with the wildcard. I'm
not sure why
it was changed to us
On 27/05/14 10:40, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8024832?
http://cr.openjdk.java.net/~prappo/8024832/webrev.00/
Thanks
-Pavel
Just wondering, what does ServerSocket.accept() throw in the same situation?
Michael
I think it should be throwing a SocketException rather than a
NotYetBoundException to be consistent with ServerSocket.accept()
Michael.
On 27/05/14 10:56, Chris Hegarty wrote:
Looks good to me Pavel. I can sponsor this change for you.
-Chris.
On 27 May 2014, at 10:40, Pavel Rappo wrote:
Hi
s not bound yet");
sun.nio.ch.ServerSocketAdaptor.accept will translate
java.nio.channels.NotYetBoundException into an instance of SocketException with
the text you see above. Basically that's what the attached test verifies.
-Pavel
On 27 May 2014, at 10:49, Michael McMahon wrote:
On 27/05/14 10:40, Pavel
On 27/05/14 15:56, mark.reinh...@oracle.com wrote:
2014/5/26 20:01 -0700, michael.x.mcma...@oracle.com:
I think it should be throwing a SocketException rather than a
NotYetBoundException to be consistent with ServerSocket.accept()
No, NotYetBoundException is the correct exception here. The NIO
veral javadoc indicate @since 1.9.
Since it is an 8u20 patch, I wonder if we should change @since 1.9 to
@since 1.8 for both 8u20 and java8?
I could provide a patch to change @since 1.9 to @since 1.8 if this is
what we want.
Thanks a lot!
On 04/11/2014 01:13 AM, Michael McMahon wrote:
Hi,
Th
arty wrote:
Since these APIs are not in 1.8 FCS, is there another way to indicate
what release they were added in?
-Chris.
On 04/06/14 09:51, Michael McMahon wrote:
Hi Deven,
Thanks for pointing that out. I'll see if we can fix it in time for
8u20.
In fact, it should really have the same
Looks good.
- Michael
On 04/06/14 11:29, Chris Hegarty wrote:
Looks like a typo in the original @link tag:
diff --git a/src/share/classes/jdk/net/Sockets.java
b/src/share/classes/jdk/net/Sockets.java
--- a/src/share/classes/jdk/net/Sockets.java
+++ b/src/share/classes/jdk/net/Sockets.java
@@
I'd like to make the same change in 8u-dev
http://cr.openjdk.java.net/~michaelm/8044766/webrev.1/
Thanks,
Michael.
On 4 Jun 2014, at 11:58, Michael McMahon
wrote:
I'd like to make the same change in 8u-dev
http://cr.openjdk.java.net/~michaelm/8044766/webrev.1/
Thanks,
Michael.
Looks good. What matters most I think is that the common case
where there is no IPv6 address included, is efficient.
I think a test case should be possible for this also.
- Michael.
On 09/06/14 06:40, Chris Hegarty wrote:
This looks good to me Pavel.
-Chris.
On 6 Jun 2014, at 18:42, Pavel Ra
Could I get this change reviewed please?
We need to check if the current process has permission to use the
SO_FLOW_SLA
socket option as well as test if the feature is installed.
The problem would cause the new test to fail on Solaris machines with S11.2
unless running with the required privile
On 12/06/14 18:47, Alan Bateman wrote:
On 12/06/2014 18:04, Michael McMahon wrote:
Could I get this change reviewed please?
We need to check if the current process has permission to use the
SO_FLOW_SLA
socket option as well as test if the feature is installed.
The problem would cause the
On 12/06/14 20:35, Alan Bateman wrote:
On 12/06/2014 20:15, Michael McMahon wrote:
It would be possible to change the error back, but what about
supportedOptions() - what should
that return? It doesn't seem right that it would include an option
that cannot be used and how do
we test i
On 13/06/14 10:08, Chris Hegarty wrote:
On 12/06/14 21:04, Michael McMahon wrote:
On 12/06/14 20:35, Alan Bateman wrote:
On 12/06/2014 20:15, Michael McMahon wrote:
It would be possible to change the error back, but what about
supportedOptions() - what should
that return? It doesn't
On 13/06/14 12:10, Alan Bateman wrote:
On 13/06/2014 11:49, Michael McMahon wrote:
Okay. I can see the reasoning why supportedOptions should refer to
the platform rather than the process/instance
running. We could consider adding a sub-class of IOException for
permission related failures
This is a simple test case fix for 8u-dev only. Unfortunately, the test case
for 9 was backported in its entirety and makes calls to APIs not
available in 8.
http://cr.openjdk.java.net/~michaelm/8047187/webrev.1/
Thanks,
Michael.
On 18/06/14 13:53, Artem Smotrakov wrote:
Hello,
Please review this fix for 8u:
https://bugs.openjdk.java.net/browse/JDK-8047186
http://cr.openjdk.java.net/~asmotrak/so_flow_sla/sockets_exceptions/webrev.01/
getOption() and setOption() methods of jdk.net.Sockets class throw
InvocationTarge
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8029607/webrev.1/
It adds support for the IP_TOS socket option to ServerSocketChannel
(and ServerSocket). This means
that the type of service/traffic class can be set on a server socket
and therefore the optio
On 25/06/14 13:09, Alan Bateman wrote:
On 25/06/2014 12:21, Michael McMahon wrote:
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8029607/webrev.1/
This mostly looks good to me. I assume you have run the :jdk_nio tests
and also run them with -vmoption
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8048212/webrev.1/
It fixes a problem caused by the fix for 8029607. The changes for
that fix should not have been applied to Windows. So, this fix ensures
that the IPv4 option is used always on Windows.
Micha
Hi Peter,
Thanks for contributing this. I've started to review it
and will get back to you with comments later in the week.
Regards,
Michael.
On 01/07/14 19:35, Peter Levart wrote:
Hi,
I propose a patch for this issue:
https://bugs.openjdk.java.net/browse/JDK-7186258
The motivation to re-de
On 30/06/14 19:43, Alan Bateman wrote:
On 30/06/2014 17:53, Michael McMahon wrote:
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8048212/webrev.1/
It fixes a problem caused by the fix for 8029607. The changes for
that fix should not have been applied
Hi Peter,
Is it necessary to remove the cache entry in the local host case (L1226) ?
It seems redundant to cache it here, and also explicitly in the
CachedLocalHost object
Michael
On 02/07/14 12:56, Peter Levart wrote:
Hi,
I updated the webrev with first two suggestions from Bernd (expireTi
Peter,
Thanks for the explanation. No. I think your change is good. I've run
tests here locally
and I'm happy with it overall.
Michael
On 07/07/14 14:10, Peter Levart wrote:
On 07/07/2014 12:59 PM, Michael McMahon wrote:
Hi Peter,
Is it necessary to remove the cache entry in
Max,
These changes look fine. Just a couple of minor comments:
L130 in Client.java appears to be superfluous now.
The comment at L186 in Server.java might probably should
be removed or else expanded upon.
Thanks
Michael
On 23/06/14 09:09, Wang Weijun wrote:
Ping again.
On Jun 12, 2014, at
On 10/07/14 09:11, Peter Levart wrote:
On 07/10/2014 02:50 AM, Peter Firmstone wrote:
Are there parties on this list interested in updating java.net.URI to
RFC3986?
Is there anyone here who has previously attempted this? If so what
issues did you find with regard to backward compatibility?
I'll file a bug for this Stanimir. Thanks for reporting it.
Should be able to fix it in JDK 9 fairly promptly
and we'll see about back porting it then.
- Michael.
On 18/08/14 15:04, Stanimir Simeonoff wrote:
Hi,
As the title says there is a major bug with HttpsURLConnection as it breaks
the co
quot; from statements about comparing time
instants). So do you think this needs more testing / another review
or can I consider this reviewed for jdk9-dev ?
Regards, Peter
On 07/07/2014 04:13 PM, Michael McMahon wrote:
Peter,
Thanks for the explanation. No. I think your change is good. I've
This is the recently reported fix to HttpsURLConnection.equals
http://cr.openjdk.java.net/~michaelm/8055299/webrev.1/
The fix includes a test. Not shown in the webrev is java key store
file called testkeys, which is copied from another location
in the test tree and is to be installed in the same
1 - 100 of 1041 matches
Mail list logo
