Hi Peter,
This is certainly a thorny issue, and I agree with the approach of using
StampedLock.
Some small comments / questions:
1) Why abuse fieldsLock in hostAddress(), rather than grabbing the
writeLock ?
2) Does the setAccessible in readObject need to be in a doPriv?
Also should th
Thanks Mark, Reviewed.
-Chris.
P.S. At some point in the future, we should try to create a general test
utility library to retrieve suitable network interfaces for tests to use.
On 7 Aug 2014, at 19:15, Mark Sheppard wrote:
> Hi,
> please oblige and review the following fix
> http://cr.open
Michael,
This looks mainly ok to me. It is nice to be adding to the common test
infrastructure, where possible. Just a few minor comments...
1) Do the tests what use this also need to ensure that the classfile is
compiled? We had trouble in the past when running concurrently.
@build jd
Michael,
The source changes look fine to me, but I know you are waiting on
another dependent bug to be able to update the test.
-Chris.
On 25/08/14 11:47, Michael McMahon wrote:
Thanks for looking at it. I need to get this one reviewed first
though, to re-organise one of the test support cla
On 26 Aug 2014, at 15:06, Alan Bateman wrote:
> On 26/08/2014 15:01, Michael McMahon wrote:
>> Could I get the following small change reviewed please?
>>
>> One file was missed from my earlier change to SimpleSSLContext
>>
>> http://cr.openjdk.java.net/~michaelm/8056065/webrev.1/
> This looks o
Amanda,
I see you have implemented a getFreePort in this test, and it attempts
to find a port within a range of 10 of the given port. I would have a
concern about this when the test is run concurrently. Though we have
come across similar issues in the past, as the socket permission needs
to h
Reviewed.
As you said, this is not the default implementation on recent Windows
platforms, but possibly worth fixing so it can be backported to older releases.
On this point, there is potential here for a lot of cleanup, even removal of
the TwoStacks implementation in 9. I think this would be a
A small issue was found when running JCK tests on modern Windows platforms,
that have IPv6 enabled, but forced to run with the IPv4 Stack,
-Djava.net.preferIPv4Stack=true. NetworkInterface.getHardwareAddress() can
return a zero length byte array, where is should, and is specified to, return
nul
On 11/09/14 14:42, Chris Hegarty wrote:
A small issue was found when running JCK tests on modern Windows platforms,
that have IPv6 enabled, but forced to run with the IPv4 Stack,
-Djava.net.preferIPv4Stack=true. NetworkInterface.getHardwareAddress() can
return a zero length byte array, where
On 12/09/14 12:47, Bernd Eckenfels wrote:
Hello,
A short question out of couriosity, why is the code for the v6 and v4 case
different, anyway?
This is legacy code using Windows APIs that predate IPv6 support in the
platform. There is a huge opportunity for cleanup and modernization
here. H
On 30 Sep 2014, at 08:47, Daniel Fuchs wrote:
> On 30/09/14 17:31, Alan Bateman wrote:
>> On 30/09/2014 08:21, Mark Sheppard wrote:
>>> Hi
>>>
>>> Please oblige and review the following small change to test
>>> test/java/net/InetAddress/IPv4Formats.java
>>>
>>> --- a/test/java/net/InetAddress/
rong.
-Chris.
> Michael
>
>> M.
>>
>> On 30/09/2014 17:35, Chris Hegarty wrote:
>>>
>>> On 30 Sep 2014, at 08:47, Daniel Fuchs wrote:
>>>
>>>> On 30/09/14 17:31, Alan Bateman wrote:
>>>>> On 30/09/2014 08:21, Mark Sheppard w
Reviewed.
-Chris.
On 1 Oct 2014, at 00:01, Dmitry Samersoff wrote:
> Looks good for me!
>
> -Dmitry
>
> On 2014-10-01 02:26, Mark Sheppard wrote:
>> Thanks Tom and Dmitry
>>
>> last up best dressed ...
>>
>> .invalid as the test domain is a good recommendation
>>
>> change is now
>>
>> -
On 1 Oct 2014, at 01:48, Ivan Gerasimov wrote:
> Hello!
>
> This is a javadoc bug.
> In the code sample a redundant argument to a constructor of URI is passed.
> Probably a copy-paste error.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059450
> WEBREV: http://cr.openjdk.java.net/~igera
Looks good to me Sean.
-Chris.
On 3 Oct 2014, at 13:38, Seán Coffey wrote:
> Following bugs need to be backported to jdk7u-dev to correct issues where
> SO_FLOW_SLA availability might not be available or where sufficient
> permissions are not in place.
>
> https://jbs.oracle.com/bugs/browse/
This looks ok to me.
-Chris.
On 15/10/14 12:03, Michael McMahon wrote:
http://cr.openjdk.java.net/~michaelm/8042622/webrev.1/
The issue is that ResponseCache is receiving all the headers from our
MessageHeader internal implementation class. This includes
a dummy/fake header that represents the
On 20 Oct 2014, at 20:01, Martin Sawicki (MS OPEN TECH)
wrote:
>
> From: Alan Bateman [mailto:alan.bate...@oracle.com]
>
> The attribution line allows for multiple contributors to be listed. The
> changes are now in jdk9/dev:
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8
>
On 4 Nov 2014, at 10:51, Alan Bateman wrote:
> On 04/11/2014 10:44, Michael McMahon wrote:
>> Could I get the following small change reviewed please?
>>
>> http://cr.openjdk.java.net/~michaelm/8062744/webrev.1/
>>
>> In JDK 9 the problem only affects the Socket.supportedOptions() method,
>> bu
On 4 Nov 2014, at 11:15, Michael McMahon wrote:
> On 04/11/14 11:10, Alan Bateman wrote:
>> On 04/11/2014 11:00, Michael McMahon wrote:
>>>
>>> Thanks Alan. How about I just split the test and check the option setting
>>> behavior in OptionsTest.java
>>> which doesn't have any reference to the
On 4 Nov 2014, at 12:05, Michael McMahon wrote:
> On 04/11/14 11:18, Chris Hegarty wrote:
>> On 4 Nov 2014, at 11:15, Michael McMahon
>> wrote:
>>
>>> On 04/11/14 11:10, Alan Bateman wrote:
>>>> On 04/11/2014 11:00, Michael McMahon wrote:
>>>
On 4 Nov 2014, at 16:24, Michael McMahon wrote:
> On 04/11/14 14:45, Michael McMahon wrote:
>> On 04/11/14 12:49, Chris Hegarty wrote:
>>> On 4 Nov 2014, at 12:05, Michael McMahon
>>> wrote:
>>>
>>>> On 04/11/14 11:18, Chris Hegarty wrote
This is a trivial change to fix a failed previous attempt to prevent all
HTTP requests, with a streaming body, from automatically being retried,
by the HttpURLConnection implementation.
The existing implementation only prevents POST requests from being
automatically retried, it should prevent
top() method performs a join, only, for the
> dispatcher thread
> so that all housekeeping is done prior to exiting stop.
>
> regards
> Mark
>
> On 24/02/2014 17:08, Chris Hegarty wrote:
>> Hi Mark,
>>
>> I think join should be sufficient here.
>>
&g
hris.
> regards
> Mark
>> On 13/11/2014 10:49, Chris Hegarty wrote:
>>> On 12 Nov 2014, at 22:12, Mark Sheppard wrote:
>>>
>>> Hi
>>>Please oblige and review the updated patch
>>> http://cr.openjdk.java.net/~msheppar/8015692/webrev.02a
Looks good, thanks Mark.
-Chris
> On 21 Nov 2014, at 22:08, Mark Sheppard wrote:
>
> Hi
> minor update to fix, the boolean handlerRunAsExpected flag has been removed,
> so the fix rectifies the URL construction
>
> http://cr.openjdk.java.net/~msheppar/8065222/webrev.01/
>
> regards
> Mark
>
This test has been failing intermittently since I updated it recently to cover
another similar issue. The test shares a ServerSocket instance across two
threads, and as such it should be a volatile field. The test should also ensure
that any thread that it starts completes before it continues it
Looks good to me Mark.
-Chris
> On 28 Nov 2014, at 18:09, Mark Sheppard wrote:
>
> Hi,
> Please oblige and review the minor change
> http://cr.openjdk.java.net/~msheppar/8066130/webrev/
>
> to address the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8066130
>
> a previous amendment t
On 11 Dec 2014, at 11: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
Konstantin,
I did reply to this RFR [1], with a question, that is still unanswered.
-Chris.
[1] http://mail.openjdk.java.net/pipermail/net-dev/2014-December/008782.html
On 15/12/14 11:15, Konstantin Shefov wrote:
Gently reminder. Please review.
-Konstantin
On 11.12.2014 14:09, Konstantin Sh
A socket connection which is returned by ServerSocket.accept() is
inherited by a child process. The expected behavior is that the socket
connection is not inherited by the child process. This is an oversight
in the original implementation, that only sets HANDLE_FLAG_INHERIT for
newly created so
wrote:
> On 17/12/2014 15:47, Chris Hegarty wrote:
>> A socket connection which is returned by ServerSocket.accept() is inherited
>> by a child process. The expected behavior is that the socket connection is
>> not inherited by the child process. This is an over
This looks ok to me Amanda.
-Chris.
On 17 Dec 2014, at 23:23, Amanda Jiang wrote:
> Hi,
>
> May I request your review for following changeset?
> There is one networking tests that has dependency on internal API
> sun.net.www.ParseUtil.
> This fix is to remove the internal API dependency from
want to prevent all handles from being
inherited. Are you suggesting something different ?
-Chris.
> -Dmitry
>
>
> On 2014-12-17 18:47, Chris Hegarty wrote:
>> A socket connection which is returned by ServerSocket.accept() is
>> inherited by a child process. The expected behavior
On 18 Dec 2014, at 13:20, Alan Bateman wrote:
> On 18/12/2014 11:52, Chris Hegarty wrote:
>> Thanks for looking at this Alan.
>>
>> Surprisingly this issue has existed for a long time. I tested with the FCS
>> version of JRE 5, 6, 7, 8, and 9-ea, on Windows Server
On 22 Dec 2014, at 20:15, Amanda Jiang wrote:
> Thank you Chris, could you please sponsor this?
Pushed.
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/80a5f6aa2033
-Chris.
> Thanks,
> Amanda
>
> On 12/18/14 4:18 AM, Chris Hegarty wrote:
>> This looks ok to me
Looks ok Felix.
You could put the construction of the new DatagramSocket in a
try-with-resources, so it will be closed always, even if the test fails.
-Chris
> On 29 Dec 2014, at 10:04, FELIX YANG wrote:
>
> Hi all,
> please review the fix for 8042581. This failure was only observed on
>
On 27 Dec 2014, at 15:53, Doychin Bondzhev wrote:
> This is a copy of my email that I sent earlier to core-libs-dev.
> ---
>
> Hi,
>
> I want to report for a problem that I see when I have more then one IP
> addresses assigned to same interface.
>
> Here is an output from ip addr com
te:
>> On 29/12/2014 15:46, Chris Hegarty wrote:
>>> Looks ok Felix.
>>>
>>> You could put the construction of the new DatagramSocket in a
>>> try-with-resources, so it will be closed always, even if the test fails.
>>>
>>> -Chris
>
Reviewed.
As a temporary measure to get more diagnostic information on a very difficult
intermittent failure, 8065078, I agree with this change. Once we get the
additional diagnostic information, then we can revisit this code.
-Chris.
On 8 Jan 2015, at 14:16, Mark Sheppard wrote:
> Hi
>p
On 15/12/14 12:01, Alan Bateman wrote:
On 15/12/2014 11:25, Chris Hegarty wrote:
Konstantin,
I did reply to this RFR [1], with a question, that is still unanswered.
-Chris.
[1]
http://mail.openjdk.java.net/pipermail/net-dev/2014-December/008782.html
I can think of configurations where the
On 16/01/15 11:29, Alan Bateman wrote:
On 16/01/2015 10:49, Chris Hegarty wrote:
:
I don't see any reason to update the spec here, given that the set of
allowable character is not clearly defined in the relevant RFC's.
I think we need to create a bug to look into this more. In
On 16/01/15 12:50, Konstantin Shefov wrote:
Hi Chris, Alan, thank you for reviewing.
I have made a new webrev
http://cr.openjdk.java.net/~kshefov/6933879/webrev.01
I have removed ":" and added a test case.
This looks ok to me.
-Chris.
-Konstantin
16.01.2015 14:42, Chris Hegarty
approve by one more
person?
You have a Reviewer, and I see no objections. So you are good to push.
-Chris.
Thanks
-Konstantin
On 16.01.2015 17:02, Chris Hegarty wrote:
On 16/01/15 12:50, Konstantin Shefov wrote:
Hi Chris, Alan, thank you for reviewing.
I have made a new webrev
http
This is a fix for a minor oversight when refactoring the initializing of
Inet[4|6]Address IDs, used in many places in the networking native code.
It would appear that there is an initInetAddressIDs() call missing from
the Windows Dual Stacks Socket implementation,
Java_java_net_DualStackPlainS
On 23/01/15 14:05, Alan Bateman wrote:
On 23/01/2015 13:51, Chris Hegarty wrote:
This is a fix for a minor oversight when refactoring the initializing
of Inet[4|6]Address IDs, used in many places in the networking native
code.
It would appear that there is an initInetAddressIDs() call missing
Looks good to me Sean.
Good to see additional logging in this area.
-Chris.
On 22/01/15 15:21, Seán Coffey wrote:
Looking for a review around this issue that came in as a reported
performance regression in NTLM proxy authentication. It turned out that
HttpsClients were being discarded after Pr
Looks good to me, thanks Rob.
-Chris.
On 28 Jan 2015, at 16:46, Rob McKenna wrote:
> This is a fix to a possible race in the current sctp code. In a nutshell the
> conditional only checks that isaCls is not null. However if isaCls is set by
> one thread and that thread is interrupted before s
Reviving an old code review [1], after further investigation…
Pertinent details from previous review:
"A socket connection which is returned by ServerSocket.accept() is
inherited by a child process. The expected behavior is that the socket
connection is not inherited by the child process. This i
ore pushing.
Thanks,
-Chris.
> Sincerely yours,
> Ivan
>
> On 28.01.2015 23:01, Chris Hegarty wrote:
>> Reviving an old code review [1], after further investigation…
>>
>> Pertinent details from previous review:
>> "A socket connection which is returned
On 28 Jan 2015, at 21:24, Alan Bateman wrote:
>
> On 28/01/2015 20:01, Chris Hegarty wrote:
>> Reviving an old code review [1], after further investigation…
>>
>> Pertinent details from previous review:
>> "A socket connection which is returned by ServerS
On 29 Jan 2015, at 09:21, Alan Bateman wrote:
> On 28/01/2015 21:40, Chris Hegarty wrote:
>> I’ll make the change, add a test, and then update the webrev.
>>
> On second thoughts, it shouldn't need to be changed because the child SOCKET
> is created before Acce
This is phase 1, of getting java.net.URL work with modules.
Being able to effectively specify URL protocol handler factories as fully
qualified class names, through the 'java.protocol.handler.pkgs' system property
is problematic. It requires the protocol handler factory implementation class
to
Thanks for the comments Alan…
On 30 Jan 2015, at 14:32, Alan Bateman wrote:
> On 30/01/2015 13:36, Chris Hegarty wrote:
>> This is phase 1, of getting java.net.URL work with modules.
>>
>> Being able to effectively specify URL protocol handler factories as fully
>
Just catching up…
On 2 Feb 2015, at 08:42, Alan Bateman wrote:
> On 01/02/2015 10:45, Peter Levart wrote:
>> :
>>
>> I see. But if URLStreamHandlerFactories are only supposed to be located via
>> the system class loader, is that different from what we have now when
>> URLStreamHandlers are be
itted the implementation changes, so we can agree
the spec changes first. They are much simpler now.
-Chris.
On 02/02/15 09:15, Chris Hegarty wrote:
Just catching up…
On 2 Feb 2015, at 08:42, Alan Bateman wrote:
On 01/02/2015 10:45, Peter Levart wrote:
:
I see. But if URLStreamHandlerFact
On 02/02/15 11:00, Paul Sandoz wrote:
On Jan 30, 2015, at 10:10 PM, Alan Bateman wrote:
On 30/01/2015 15:35, Chris Hegarty wrote:
:
Update webrev and spec diffs:
http://cr.openjdk.java.net/~chegar/8064924/01/
I think the javadoc looks much better now, thanks.
Minor comments in URL
On 02/02/15 20:52, Alan Bateman wrote:
I'm happy with this approach. One outstanding point from the discussion
is whether the URLStreamHandlerFactory implementation will need to be
granted RuntimePermission("setFactory"), if so then this will need to go
into the javadoc.
I think that we sh
Agreed. Updated in-place
http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html
-Chris.
On 04/02/15 14:44, Alan Bateman wrote:
On 04/02/2015 14:29, Peter Levart wrote:
:
I agree that this is the most appropriate way with which you can force
some provider's class code (t
On 04/02/15 16:01, Peter Levart wrote:
On 02/04/2015 04:45 PM, Alan Bateman wrote:
On 04/02/2015 15:10, Weijun Wang wrote:
It should be checked, otherwise a non-initialized parent object comes
into being.
In general then permission checks in constructors are a bad idea but
we have an establish
Thank you for the comments Alan.
On 06/02/15 10:20, Alan Bateman wrote:
On 04/02/2015 15:11, Chris Hegarty wrote:
Agreed. Updated in-place
http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html
I think the approach and naming is good. A few small comments on the
On 10 Feb 2015, at 15:28, Konstantin Shefov
wrote:
> Hello,
>
> I have evaluated https://bugs.openjdk.java.net/browse/JDK-8071458
6933879 allowed a minimal additional set of non-alphanumeric characters.
8071458 was filed to examine the potential specification implications that
arose during
On 10 Feb 2015, at 11:35, Alan Bateman wrote:
> On 09/02/2015 14:57, Chris Hegarty wrote:
>> :
>>
>> Updated webrev [ spec and implementation] :
>> http://cr.openjdk.java.net/~chegar/8064924/04/
>>
> The updated javadoc looks good. I haven't had a ch
On 13 Feb 2015, at 16:11, Alan Bateman wrote:
> On 10/02/2015 16:20, Chris Hegarty wrote:
>> On 10 Feb 2015, at 11:35, Alan Bateman wrote:
>>
>>> On 09/02/2015 14:57, Chris Hegarty wrote:
>>>> :
>>>>
>>>> Updated webrev [ spec an
Looks ok to me Mark.
-Chris.
On 18/02/15 13:19, Mark Sheppard wrote:
Hi
please review the following small change
http://cr.openjdk.java.net/~msheppar/8046893/webrev/
which addresses the parfait issue in
https://bugs.openjdk.java.net/browse/JDK-8046893
regards
Mark
Sean,
Thanks for moving this forward. I think it might be possible to simplify this
by flipping the logic, like:
diff --git a/src/java.base/share/classes/java/net/SocksSocketImpl.java
b/src/java.base/share/classes/java/net/SocksSocketImpl.java
--- a/src/java.base/share/classes/java/net/SocksSoc
to test
> for same. It should help preserve behaviour in that area.
Good catch Sean.
> updated webrev : http://cr.openjdk.java.net/~coffeys/webrev.7178362.v2/webrev/
Looks good.
-Chris.
> regards,
> Sean.
>
>> On 24/02/2015 17:41, Chris Hegarty wrote:
>> Sean,
&g
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, otherwis
I would personally close this as 'not a bug'.
I see no value in trying add additional clarification around something
that has never, to the best of my knowledge, been the source of
confusion. The description in JIRA seems overly pedantic.
-Chris.
On 19/03/15 14:47, Alan Bateman wrote:
On 19
Looks ok to me Rob.
-Chris.
On 18/03/15 23:28, Rob McKenna wrote:
Pressed send a little too early. This test was added by:
8067846: (sctp) InternalError when receiving SendFailedNotification
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b10dc4dc6903
-Rob
On 18/03/15 23:27, Rob McKenna wr
The work done as part of JDK-8064924 [1] to introduce a new service type,
java.net.spi.URLStreamHandlerProvider, provides a clean provider mechanism that
will work well with modules. That part of the change should remain, but the
removal of support to find handlers through the java.protocol.hand
On 14/04/15 20:33, Alan Bateman wrote:
This looks okay to me although maybe we can use the opportunity to
replace the use of StringTokenizer with a regex.
Right. I used String.split("\\|"), but reverted to the original code as
the regex doesn't use the fast-path. But you are right split i
On 15/04/15 15:16, Paul Sandoz wrote:
On Apr 15, 2015, at 1:36 PM, Chris Hegarty wrote:
Paul,
Yes, one could use a Pattern.splitAsStream, sorry could not resist :-) assuming
this area is not sensitive to bootstrap issues e.g.
hander =
p.splitAsStream().map(String::trim).flatMap(this
On 15 Apr 2015, at 16:43, Paul Sandoz wrote:
> On Apr 15, 2015, at 4:35 PM, Chris Hegarty wrote:
>>>
>>> I marginally prefer using flatMap rather than map/filter e.g. change
>>> getHandler to return Stream< URLStreamHandler> and change the last line to
>
Looks fine.
Not for now, but sometime we should consider adding a utility to the test
library to retrieve an appropriate set of network interfaces suitable for use
in tests ( rather than patching all these tests individually ).
-Chris.
> On 26 May 2015, at 20:21, Mark Sheppard wrote:
>
> Hi
Looks fine Mark. We fixed a few other tests recently to be more tolerant of
network interference.
-Chris.
> On 26 May 2015, at 20:34, Mark Sheppard wrote:
>
> Hi
> please oblige and review the following change
> http://cr.openjdk.java.net/~msheppar/8077377/webrev/
>
> to address the issue
Looks good Paul, just a few minor comments. ( looked at all, but *security* and
*sql* )
NetworkInterface
s/Enumertion/Stream
L127 * will be returned in the Enumeration. However, if the caller has the
s/an/a
L131 * @return an Stream object with all or a subset of the InetAddresses
Brian,
Your changes look ok to me.
-Chris.
On 22 Jun 2015, at 22:56, Brian Burkhalter wrote:
> Please review this test-only change at your convenience.
>
> Issue:https://bugs.openjdk.java.net/browse/JDK-8129510
> Patch:see diff below
>
> The analysis in the comments on
> htt
Pavel,
The latest changes look good to me. Can you please add a license header to the
service descriptor file ( I know we don't do this consistently ).
-Chris
> On 24 Jun 2015, at 13:20, Pavel Rappo wrote:
>
> Thanks Alan. Both issues are fixed now, webrev updated in place.
>
>> On 24 Jun 20
Looks good Mark.
-Chris.
On 24 Jun 2015, at 16:34, Mark Sheppard wrote:
> Hi
> Please oblige and review the change below
> which addresses the issue
> https://bugs.openjdk.java.net/browse/JDK-8129507
>
> This amends the url.openConnection() to take the Proxy.NO_PROXY argument,
> so that a di
This change looks good to me Artem, and completes the ( incomplete ) work I
done on this a few years back. Though why anyone is still using SOCKS v4 I’ll
never know!
I can sponsor this change for you.
-Chris.
On 26 Jun 2015, at 18:22, Artem Smotrakov wrote:
> Hello,
>
> Please review this
On 2 Jul 2015, at 16:36, Chris Hegarty wrote:
> This change looks good to me Artem, and completes the ( incomplete ) work I
> done on this a few years back. Though why anyone is still using SOCKS v4
> I’ll never know!
>
> I can sponsor this change for you.
Alexander,
Wow, that's a lot of boiler plate for a manual test. Surely a
README.txt, or similar would be sufficient?
I noticed that with your changes, now this test has a dependency on the
jdk.desktop module ( imports from java.awt.* ). Is it really necessary
to have a dialog window pop-up?
On 04/08/15 13:53, Alexander Fomin wrote:
Hi Chris
On 04.08.2015 13:29, Chris Hegarty wrote:
Alexander,
Wow, that's a lot of boiler plate for a manual test. Surely a
README.txt, or similar would be sufficient?
I noticed that with your changes, now this test has a dependency o
Looks good to me too.
-Chris.
On 23 Aug 2015, at 21:04, Claes Redestad wrote:
> Looks good to me.
>
> /Claes (not a Reviewer)
>
> On 2015-08-21 21:49, Rob McKenna wrote:
>> Hi folks, looking for a review for this simple change.
>>
>> The change for https://bugs.openjdk.java.net/browse/JDK-80
On 3 Sep 2015, at 10:13, Andrej Golovnin wrote:
> Hi Pavel,
>
>> So you need the ability to send pings and unsolicited pongs. Do you handle
>> pong
>> replies from the server? If so, do you control their arrival times and their
>> consistency with previous pings sent? What about unsolicited pon
On 3 Sep 2015, at 11:49, Andrej Golovnin wrote:
> Hi Chris,
>
>> Will adding the ability to send ping(ByteBuffer) be sufficient for your
>> usage? If so, then I think we should add it, but not pong. The
>> implementation will automatically send a pong message in response to
>> receiving a p
The changes look fine to me too.
-Chris.
On 04/09/15 16:04, Daniel Fuchs wrote:
Hi Vyom,
I'm not a net/JNI expert but what you are proposing
looks good to me too. Ivan has already given his assent.
Unless I hear objections - or comments from other reviewers,
I will sponsor this change and pus
Hi Vyom,
On 07/09/15 10:26, Vyom Tewari wrote:
Hi everyone,
Can you please review my changes for below bug.
Bug:
JDK-8080402 : File Leak in
jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
Webrev:
http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/
This change ensure th
This looks like a nice cleanup, and fix. Thanks Ivan.
-Chris.
On 05/09/15 15:25, Ivan Gerasimov wrote:
Hi everyone!
The fix didn't bring enough attention back in February for some reason.
So, I'd like to re-request a review.
I've added a regression test, which reliably reproduces a deadlock o
On 8 Sep 2015, at 05:56, David Holmes wrote:
> Hi Sebastian,
>
> On 8/09/2015 1:54 PM, Sebastian Sickelmann wrote:
>> Hi,
>>
>> please find the link to the webrev[1] hosted at my dropbox in my first mail
>> in this thread at the buttom of this mail.
>>
>> A direkt link to the including patch
On 7 Sep 2015, at 17:41, Mark Sheppard wrote:
> a couple of other considerations in the context of this issue perhaps?
>
> in this s is being duped onto fd, and part of the dup2 operation is the
> closing of fd, but
> what's is the expected state of file descriptor fd in the event of a dup2
>
On 8 Sep 2015, at 21:01, Sebastian Sickelmann
wrote:
> Hi,
>
> Please find my small patch[1] to javadoc in java.net.URL that adresses
> JDK-4906983(javadoc-fix)[2].
>
> I signed the SCA/OCA some time ago. Feel free to check at the OCA
> Signatures-List[3]
>
> thanks to david buck for hosting
the valid values from @param port,
and add something like the following to MalformedURLException: “.., or the port
is a negative number other than -1” ?
-Chris.
On 10 Sep 2015, at 11:13, Chris Hegarty wrote:
>
> On 8 Sep 2015, at 21:01, Sebastian Sickelmann
> wrote:
>
>>
e
>> valid port numbers also above 65535 and the special -1.
>>
>> But i asked myself should
>> new URL("http://server:-1/path";);
>> be realy a valid URL? What do you think?
>>
>> Special thanks to David who hosted the new webrev:
>> http
; <http://cr.openjdk.java.net/~dbuck/4906983.1/>
I think these changes are good as is ( pending the outcome of the mail exchange
with Mark Sheppard ).
-Chris.
> -- Sebastian
>
>
> Am 10.09.2015 um 12:38 schrieb Chris Hegarty:
>> Another minor comment...
>>
>>
On 13/09/15 20:18, Sebastian Sickelmann wrote:
Am 13.09.2015 um 16:25 schrieb Chris Hegarty:
On 13 Sep 2015, at 14:07, Mark Sheppard
<<mailto:mark.shepp...@oracle.com>mark.shepp...@oracle.com> wrote:
Hi
I don't think the URL string http://server:-1/path can be
considered a
at is why I asked the question.
-Chris.
OK, that's fine
On 13/09/2015 15:25, Chris Hegarty wrote:
Is this suggested wording for the “spec” accepting constructors? I
think what we have for the constructors accepting protocol, host,
port, etc, is more accurate.
> On 14 Sep 2015, at 16:45, Sebastian Sickelmann
> wrote:
>
> Am 14.09.2015 um 10:53 schrieb Chris Hegarty:
>> On 13/09/15 20:18, Sebastian Sickelmann wrote:
>>> Am 13.09.2015 um 16:25 schrieb Chris Hegarty:
>>>>
>>>>> On 13 Sep 2
The changes look good to me Vyom.
-Chris.
On 16/09/15 10:08, Vyom Tewari wrote:
Hi All,
Please review my changes for below bug.
Bug:
JDK-8073542 : File Leak in
jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c
Webrev:
http://cr.openjdk.java.net/~dfuchs/vyom/8073542/webrev.
This looks ok to me Artem.
-Chris
On 30/09/15 11:11, Artem Smotrakov wrote:
Hello,
Please review this small fix which updates NTLM implementation to use
doPrivileged() methods when it reads system properties. Currently it
requires property permissions to read "ntlm.debug" and "ntlm.version"
sy
201 - 300 of 2074 matches
Mail list logo
