windows API has very inconsistent behavior on Teredo Tunneling
Pesudo-Interface, we removed this network interface for this test.
Thank you.
Tristan
On 01/11/2013 22:43, Chris Hegarty wrote:
Hi Tristan,
From what I understand of the issue I see no problem with what you are
suggesting. Webrev
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 changes small and confined for now.
On 5 Nov 2013, at 20:39, Michael McMahon michael.x.mcma...@oracle.com 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/webrev
; not a Reviewer)
Thanks for the review Roger.
-Chris.
Roger
On 11/5/2013 3:39 PM, 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
Changeset: f37d62e295c0
Author:chegar
Date: 2013-11-07 08:04 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f37d62e295c0
8027822: ProblemList.txt Updates (11/2013)
Reviewed-by: chegar, alanb
Contributed-by: Amy Lu amy...@oracle.com
! test/ProblemList.txt
Changeset: 82b276590b85
Author:chegar
Date: 2013-11-07 08:23 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82b276590b85
8027961: Inet[4|6]Address native initializing code should check field/MethodID
values
Reviewed-by: michaelm, rriggs
!
Looks ok to me.
-Chris.
On 11/07/2013 09:31 AM, Michael McMahon wrote:
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.
Virus checkers and, on more modern Windows OSes, Windows Experience
Service, and other external processes, have been causing trouble when it
comes to tests deleting files.
On a number of occasions in the past retry logic has been added to tests
that need to delete files. Also, the jtreg
the difference between these
methods and regular delete. So maybe move to public deleteWithRetry?
-Chris.
Michael
On 07/11/13 10:05, Chris Hegarty wrote:
Virus checkers and, on more modern Windows OSes, Windows Experience
Service, and other external processes, have been causing trouble when
SimpleFileVisitor, rather than FileVisitor
Thanks,
-Chris.
On 11/07/2013 01:24 PM, Alan Bateman wrote:
On 07/11/2013 11:34, Chris Hegarty wrote:
:
I've also received another comment offline about the method names.
They should be more descriptive, and highlight the difference between
these methods and regular
This is an interesting little product bug that was originally thought to
be a test stabilization issue, with
java/net/ipv6tests/BadIPv6Addresses.java.
Depending on the input/configuration/patch level getaddrinfo may try to
lookup a malformed IPv6 literal, and block for several seconds waiting
On 08/11/2013 13:15, Alan Bateman wrote:
...
http://cr.openjdk.java.net/~chegar/8019834/webrev.00/
This looks okay to me. You might want to adjust the bug summary slightly
as UHE for bad IPv6 literal addresses is correct (it's just the hang due
to the lookup).
Thanks Alan, I'll update the
On 11/8/2013 9:47 AM, Chris Hegarty wrote:
Alan,
An alternative might be to just throw the IOException with
InterruptedException as the cause.
Perfect. Updated in the new webrev.
Dan,
You are completely correct. I was only catering for the case where
java.nio.file.FileSystemException: your_file
Changeset: 3112729d6b74
Author:tyan
Date: 2013-11-08 15:12 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3112729d6b74
8022963: java/net/NetworkInterface/Equals.java fails equality for Windows
Teredo Interface
Reviewed-by: chegar
!
Changeset: 771c77b49bb6
Author:chegar
Date: 2013-11-08 15:15 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/771c77b49bb6
8019834: InetAddress.getByName hangs for bad IPv6 literals
Reviewed-by: alanb
! src/share/classes/java/net/InetAddress.java
!
Looks fine to me Tristan, I'll sponsor this change for you.
Trivially, I will add a 30sec timeout to the wait, just in case there is
a problem in the future.
-Chris.
On 11/04/2013 03:12 AM, Tristan Yan wrote:
Hi Everyone
Please review the fix for JDK-8023462
Changeset: 46982ca895b4
Author:tyan
Date: 2013-11-08 18:54 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46982ca895b4
8023462: TEST_BUG: test/com/sun/net/httpserver/bugs/B6433018.java fails on
slow/single core machine
Reviewed-by: chegar
!
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- 8019834 that was pushed to
jdk8/tl today. The patch means that UHE is thrown when doing a lookup of
hosts that
Changeset: b48eded97dff
Author:chegar
Date: 2013-11-11 10:33 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b48eded97dff
8028102: All test targets, jdk/test/Makefile, fail on Windows
Reviewed-by: mduigou
! test/Makefile
Thread.sleep(RETRY_DELETE_MILLIS);
seems not indented correctly.
Thanks,
-Dan
On 11/08/2013 07:35 AM, Chris Hegarty wrote:
On 08/11/2013 15:01, roger riggs wrote:
Hi,
Does renaming the file/directory suffer the same delay?
I have not tried, but I read that MoveFileEx does not suffer from
On 11/13/2013 06:00 AM, Tristan Yan wrote:
Hi Everyone
I am working on bug https://bugs.openjdk.java.net/browse/JDK-8022212.
This is the same root cause as bug JDK-8022963, which is we should not
test Teredo Tunneling Pseudo-Interface interface in windows.
So suggested fix is doing the same
Changeset: 70f1bed5e7fd
Author:chegar
Date: 2013-11-13 16:44 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70f1bed5e7fd
8022213: Intermittent test failures in java/net/URLClassLoader
Reviewed-by: dxu, alanb
! test/java/net/URLClassLoader/closetest/CloseTest.java
!
I haven't seen a follow up on this, so I think we can just go ahead and
remove the test from the ProblemList.txt for now, and revisit, if necessary.
Tristan, I can sponsor this for you.
-Chris.
On 11/14/2013 02:59 PM, Tristan Yan wrote:
Hi Everyone
I am working on
Changeset: d5ddde25d107
Author:tyan
Date: 2013-11-19 13:46 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5ddde25d107
7086879: java/net/InetAddress/CheckJNI.java hangs on Linux when IPv6 enabled
Reviewed-by: chegar
! test/ProblemList.txt
Changeset: cfbee8ee71bf
Author:bvaidya
Date: 2013-11-19 15:31 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfbee8ee71bf
8028094: TEST_BUG: java/lang/ProcessBuilder/Basic.java leaves sleep
processes behind
Reviewed-by: chegar
!
Charlie,
When I run this test with DISPLAY unset, or set to empty string, and
on a system without the latest Gnome 3 libraries ( more specifically NOT
having libgio-2.0.so ), I get a warning that GConf cannot be initialized
(see below). I do not see this test hanging.
---
(process:25718):
On 20/11/13 10:19, Daniel Fuchs wrote:
Hi Tristan,
I believe you should also declare the 'error' flag as
well as the 'clientCtx' variable volatile since they are set
by a thread and read by another.
Good catch Daniel. Tristan, can you update the webrev and create a
changeset. I can then
Changeset: 2972241cf7eb
Author:tyan
Date: 2013-11-21 13:37 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2972241cf7eb
703: test/com/sun/net/httpserver/Test9a.java fails intermittently
Summary: Additional stacktrace information is printed on failure
Reviewed-by: alanb,
: Chris Hegarty; net-dev@openjdk.java.net
主题: 答复: RFR for JDK-8022212 Intermittent test failures in java/net
Thanks Chris for sponsoring this.
Tristan
-邮件原件-
发件人: Chris Hegarty
发送时间: Thursday, November 14, 2013 9:34 PM
收件人: Tristan Yan; net-dev@openjdk.java.net
主题: Re: RFR for JDK-8022212
Changeset: 5bcaf730ceb8
Author:tyan
Date: 2013-11-29 09:29 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bcaf730ceb8
8029348: ProblemList.txt updates (11/2013)
Reviewed-by: chegar
! test/ProblemList.txt
Looks good to me Mark.
-Chris.
On 02/12/13 12:35, Mark Sheppard wrote:
Hi
based on feedback the changes for issue:
https://bugs.openjdk.java.net/browse/JDK-8025211
have been amended to the following:
http://cr.openjdk.java.net/~msheppar/8025211/webrev.02/
please oblige and review
This update looks much better to me.
-Chris.
On 02/12/13 14:33, Michael McMahon wrote:
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
On 26 Nov 2013, at 18:08, Iris Clark wrote:
So overall it looks good to me and should be pushed to the staging forest
once you hear from others that commented previously.
I think that means Chris Hegarty, Michael McMahon, and Sergey Bylokhov.
Alan, please correct me if I'm wrong.
I'm
Changeset: 2a6611ebfb6c
Author:smarks
Date: 2013-12-04 18:02 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a6611ebfb6c
8029141: Add @FunctionalInterface annotation to Callable interface
Reviewed-by: chegar, alanb
! src/share/classes/java/util/concurrent/Callable.java
On 07/12/2013 18:12, Dan Xu wrote:
...
Just so I understand, did you use a JNI global when caching the reference?
-Alan
Hi Alan,
What is a JNI global?
http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp1242
What I use here is a static global variable. I
have
On 08/12/13 17:39, Dan Xu wrote:
On 12/08/2013 01:34 AM, Chris Hegarty wrote:
On 07/12/2013 18:12, Dan Xu wrote:
...
Just so I understand, did you use a JNI global when caching the
reference?
-Alan
Hi Alan,
What is a JNI global?
http://docs.oracle.com/javase/7/docs/technotes/guides/jni
Looks good to me. Thanks Dan.
-Chris.
On 12 Dec 2013, at 05:14, Dan Xu dan...@oracle.com 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 only be run when
On 18 Dec 2013, at 15:13, Alan Bateman alan.bate...@oracle.com wrote:
On 18/12/2013 15:09, Mark Sheppard wrote:
Hi,
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/7102702/webrev/
Good sleuthing!! The change looks good to me.
Yes, this is a good
On 18 Dec 2013, at 14:35, roger riggs roger.ri...@oracle.com wrote:
Thanks Alan,
I corrected the webrev to link both locations that refer to ProxySelector.
http://cr.openjdk.java.net/~rriggs/webrev-javadoc-link-7018010/
Looks good. Thanks Roger.
-Chris.
Roger
On 12/18/2013 6:23
/2013 16:05, Chris Hegarty wrote:
On 18 Dec 2013, at 15:13, Alan Bateman alan.bate...@oracle.com wrote:
On 18/12/2013 15:09, Mark Sheppard wrote:
Hi,
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/7102702/webrev/
Good sleuthing!! The change looks good
Changeset: e2bdddb8bedf
Author:dl
Date: 2013-12-19 10:31 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2bdddb8bedf
8026155: Enhance ForkJoin pool
Reviewed-by: chegar, alanb, ahgross
! src/share/classes/java/util/concurrent/ForkJoinPool.java
!
On 23 Dec 2013, at 18:21, Mark Sheppard mark.shepp...@oracle.com wrote:
Hi,
Please oblige and review the following changes:
http://cr.openjdk.java.net/~msheppar/8027903/webrev/
which address the issue:
https://bugs.openjdk.java.net/browse/JDK-8027903
The test failure was found to
Andreas, Steven,
I updated the bug and assigned it to myself ( to remind me to sponsor the
change ). I'll need to look at the changes in a little more detail, but at
first glance they look right to me. I will also look to see if the test can be
reduced a little, and add appropriate jtreg tags
Thanks Mark,
On 2 Jan 2014, at 16:26, Mark Sheppard mark.shepp...@oracle.com wrote:
Hi Alan,
added an ExceptionDescribe to native code and an -Xcheck:jni to the cmd line
options to produce the
following:
WARNING in native method: JNI call made with exception pending
at
Changeset: 18080cca998a
Author:dl
Date: 2014-01-03 06:22 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18080cca998a
8031133: AbstractMap should specify its default implementation using @implSpec
Reviewed-by: chegar, alanb
! src/share/classes/java/util/AbstractMap.java
handling for SkipException
in the jtreg source. I also cannot find any use of it in the any of the
OpenJDK JDK 9 repositories. Maybe just to be safe you could print a
warning message and simply return?
-Chris.
On Mon, Jan 6, 2014 at 6:16 PM, Chris Hegarty chris.hega...@oracle.com
On 06/01/14 16:05, Dimitar Mavrodiev wrote:
The jtreg version I am using(4.1 fcs b05) seems to be correctly handling
it. What jtreg version should I be using?
See https://bugs.openjdk.java.net/browse/JDK-8026362 for a an example of
this.
Did you try to run your test without ::1 enabled?
Looks good to me Joe.
-Chris.
On 6 Jan 2014, at 19:36, Joe Darcy joe.da...@oracle.com wrote:
Hello,
Please review the simple patch below to address
JDK-8031201: Fix casting lint issues in java.net
(The various ObjectInputStream.GetField.get methods which have a default
The source changes look good to me too.
I see Alan has commented on the test, and I agree. Trivially, can you
also remove the dependency on the old internal HttpServer, and use the
newer com.sun.net.httpserver API. It is easier to user, and more robust.
You can see an example here [1].
Approved.
-Chris.
On 7 Jan 2014, at 17:36, Joe Darcy joe.da...@oracle.com 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.
to verify it, then obviously forgot it
was an internal link. Sorry about this. I’ll repost a mail when the public
server is back online.
-Chris.
Thanks,
Dimitar
Sent from my mobile device.
On Jan 13, 2014 9:11 PM, Chris Hegarty chris.hega...@oracle.com wrote:
Hi Dimitar,
Thank you
Hi Dimitar,
Thank you for following up with this. I came to the same conclusion as you
earlier today, though I noticed it because the test SocksServer was sending a
single byte at a time, for the initial reply.
I took your latest patch and applied a few minor cleanups, as follows:
On 13 Jan 2014, at 19:29, Chris Hegarty chris.hega...@oracle.com wrote:
On 13 Jan 2014, at 19:23, Dimitar Mavrodiev dmavrod...@gmail.com wrote:
Hi Chris,
I can't open the link, but yet I wouldn't mind if you folded your patch into
mine.
How embarrassing. Our public facing server
On 14 Jan 2014, at 10:51, Alan Bateman alan.bate...@oracle.com wrote:
On 14/01/2014 08:28, Chris Hegarty wrote:
On 13 Jan 2014, at 19:29, Chris Hegartychris.hega...@oracle.com wrote:
On 13 Jan 2014, at 19:23, Dimitar Mavrodievdmavrod...@gmail.com wrote:
Hi Chris,
I can't open
On 14 Jan 2014, at 10:53, Chris Hegarty chris.hega...@oracle.com wrote:
On 14 Jan 2014, at 10:51, Alan Bateman alan.bate...@oracle.com wrote:
On 14/01/2014 08:28, Chris Hegarty wrote:
On 13 Jan 2014, at 19:29, Chris Hegartychris.hega...@oracle.com wrote:
On 13 Jan 2014, at 19:23
Cross posting to security-dev, since the question cipher related.
-Chris.
On 27/01/14 09:28, Mark Christiaens wrote:
I wrote a little test client/server setup that transfers 100 MB of data
over an SSL socket configured to use TLS 1.2 AES GCM
(TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256). On my
Looks ok to me Michael.
-Chris.
On 03/02/14 14:04, Michael McMahon wrote:
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,
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 ).
Thanks Alan, I appreciate the drive-by! The changes look good to me.
-Chris.
On 11 Feb 2014, at 13:13, Alan Bateman alan.bate...@oracle.com wrote:
This is drive-by fix to a number of native code warnings in the networking
code.
In NET_SockaddrToInetAddress then CHECK_NULL_RETURN is used
On 14/02/14 14:04, Alan Bateman wrote:
On 14/02/2014 13:52, Florian Weimer wrote:
This patch removes support for old, pre-1.4 SocketImpl and
DatagramSocketImpl classes. Compiling these classes has been
impossible since 1.4 because 1.4 added new abstract methods to the
base classes.
Is this
Michael,
I’m ok with your analysis, and suggested fix.
From the original test output, in the bug description, I can see that there are
58 println’s with Request from: for test3, and two Worker: Error writing to
server”. This would tend to support your analysis that that server, in some
On 20 Feb 2014, at 12:53, michael cui michael@oracle.com wrote:
On 02/20/2014 07:24 PM, Chris Hegarty wrote:
Michael,
I’m ok with your analysis, and suggested fix.
From the original test output, in the bug description, I can see that there
are 58 println’s with Request from
Mark,
I agree with you, there is certainly some additional co-ordination needed
between the thread invoking the stop method and the dispatcher thread.
I wonder why you needed to add the selectNow() and the close() after you have
joined the dispatcher thread? Since you are guaranteed that the
Interruptible I/O on Solaris has been highly problematic and the long standing
plan has been to remove it from the JDK. In JDK6 the VM option
UseVMInterruptibleIO was introduced to allow developers/customers experiment
with disabling it. In JDK7 the default value of UseVMInterruptibleIO was
and might be not available on all
platforms. So it's better to try clock_gettime first
I’ll take a look at these, but if there are any potential behavioural changes,
desirable or otherwise, then they should come under a separate JIRA issue.
-Chris.
-Dmitry
On 2014-02-22 12:29, Chris Hegarty
Thanks for your comments Bernd.
On 22 Feb 2014, at 14:03, Bernd Eckenfels bernd-2...@eckenfels.net wrote:
Hello,
Am 22.02.2014 um 10:33 schrieb Alan Bateman alan.bate...@oracle.com:
http://cr.openjdk.java.net/~chegar/8034174/webrev.00/webrev/
Thank for you for doing this, it's long over
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
dmitry.samers...@oracle.com 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_
Latest webrev:
http://chhegar.ie.oracle.com/chhegar/repos/jdk9/dev/dev/jdk/8034174/webrev.01/webrev/
-Chris.
On 24/02/14 14:12, Michael McMahon wrote:
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
Thanks for jumping on this Michael, one of my recent changes caused the
problem.
Your fix looks good to me. Trivially, the test has a 2006 copyright header.
-Chris.
On 24/02/14 17:55, Michael McMahon wrote:
Could I get the following change reviewed please?
Thanks Sean. Looks good to me.
-Chris.
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/browse/JDK-7076487
webrev :
On 26/02/2014 19:12, Alan Bateman wrote:
On 26/02/2014 17:48, Volker Simonis wrote:
:
That said, '8034174: Remove use of JVM_* functions from java.net code'
broke the AIX build and here's the small change which fixes it again:
http://cr.openjdk.java.net/~simonis/webrevs/8035876/
On 27 Feb 2014, at 08:18, Eric Wang yiming.w...@oracle.com wrote:
…..
Thanks Alan to suggest the correct alias!
Below is the webrev for this bug, Can you or anyone else help to review the
fix?
http://cr.openjdk.java.net/~ewang/JDK-8035633/webrev.00/
Volker,
The changes look fine to me, and in line with what I was thinking too.
Quite trivially you can remove the block '{' from net_util_md.c Line
1637 and 1650. Also, the function comment says Wrapper for select/poll
... ( can remove 'select' ).
I ran your patch through our internal build
[ 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 getdtablesize(2) was intended to allow
user
On 28 Feb 2014, at 17:28, chris...@zoulas.com wrote:
On Feb 28, 3:55pm, michael.x.mcma...@oracle.com (Michael McMahon) wrote:
-- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx
| On 28/02/14 14:40, Chris Hegarty wrote:
| [ Volker: there are some trivial AIX changes here
On 1 Mar 2014, at 01:27, chris...@zoulas.com wrote:
On Feb 28, 5:41pm, chris.hega...@oracle.com (Chris Hegarty) wrote:
-- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx
| We are using select on OS X, only, because of a bug in poll, see
| https
proposed to change that in this issue.
-Chris.
On 02/03/14 19:44, Alan Bateman wrote:
On 28/02/2014 14:40, Chris Hegarty wrote:
:
I think option 2 is preferable:
http://cr.openjdk.java.net/~chegar/8035897/webrev.00/webrev/
I'm still checking to see it an automatic regression test is possible
.
If you guys are OK with the fix, of course.
The changes seem mostly benign to me. I have no objections to being listed as a
reviewer.
-Chris.
Sincerely yours,
Ivan
On 04.03.2014 14:28, Chris Hegarty wrote:
On 4 Mar 2014, at 03:25, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
Yes
On 5 Mar 2014, at 09:48, Eric Wang yiming.w...@oracle.com wrote:
Hi everyone,
Hi Everyone,
I'm working on the test bug https://bugs.openjdk.java.net/browse/JDK-8025209,
The test uses Thread.sleep to sync-up threads which is not a correct
assumption. The fix is just to sync-up 2 threads
Thanks for doing this Pavel. The changes, and test, look good to me. I
can sponsor this for you.
-Chris.
On 19/03/14 18:03, Pavel Rappo wrote:
Hi everyone,
could you please review my change for JDK-8035158?
DefaultProxySelector uses sun.misc.RegexpPool to parse properties that
configure the
Thanks for doing this Pavel. The changes, and test, look good to me. I
can sponsor this for you.
I assume that once this changes is pushed, JDK-8037781: Remove
sun.misc.Regexp* classes, can proceed.
-Chris.
On 19/03/14 18:03, Pavel Rappo wrote:
Hi everyone,
could you please review my
This looks ok to me Mark.
You have added a question/comment on L514. Is this intentional?
L555. Not directly related to your changes, but should netaddrP be freed
there before returning NULL?
-Chris.
On 14/03/14 19:04, Mark Sheppard wrote:
Hi
Please oblige and review the following
:
On 22/03/2014 08:13, Chris Hegarty wrote:
The native SCTP implementation assumes that the given byte buffer (
buffer address + position ) is memory aligned. It re-uses the buffer
for handling notifications from the SCTP Stack ( as well as for
reading data off the socket ). This can result
On 24/03/14 16:17, Alan Bateman wrote:
On 24/03/2014 14:09, Chris Hegarty wrote:
Alan, Dmitry,
I updated the webrev. It now allocates memory dynamically, and asserts
that the number of bytes read is less than the size of
sctp_notification ( for notifications ).
http://cr.openjdk.java.net
Hi Anton,
I don't have any objections to this, but Max is the original author of
this code and may want to take a closer look.
-Chris.
On 20/03/14 14:08, Anton Litvinov wrote:
Hello,
Could you please review the following fix for the bug, which consists in
a deadlock between 2 threads
While hunting around the build recently, when working on another SCTP bug, I
noticed a small issue where SCTP classes are being built on some platforms
unnecessarily.
Webrev:
http://cr.openjdk.java.net/~chegar/8038459/webrev.00/webrev/
Mac OS X and AIX contain only stubs for the SCTP
Looks ok to me Amanda. I can sponsor this change, if needed.
-Chris.
On 28/03/14 05:07, Amanda Jiang wrote:
Hi All ,
Please check and review following changes:
http://cr.openjdk.java.net/~ewang/amanda/JDK-8038276/webrev.00/
Description of issue:
Root Cause:
Test
://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.01/
Thanks to review the fix and sponsor it for me.
-Eric
On 2014/3/28 18:41, Chris Hegarty wrote:
Hi Eric,
I've taken a look at the webrev and I mainly agree with the
changes/refactoring.
On the issue of increasing the timeout to 20 secs; there is a clear
race
Trivial typo fix.
diff --git a/src/share/classes/java/net/HttpCookie.java
b/src/share/classes/java/net/HttpCookie.java
--- a/src/share/classes/java/net/HttpCookie.java
+++ b/src/share/classes/java/net/HttpCookie.java
@@ -74,7 +74,7 @@
private boolean httpOnly; // HttpOnly ... i.e. not
Sincerely yours,
Ivan
On 31.03.2014 17:42, Chris Hegarty wrote:
Trivial typo fix.
diff --git a/src/share/classes/java/net/HttpCookie.java
b/src/share/classes/java/net/HttpCookie.java
--- a/src/share/classes/java/net/HttpCookie.java
+++ b/src/share/classes/java/net/HttpCookie.java
@@ -74,7 +74,7
, which probably indicates use of '[]' in those
components
is uncommon.
Michael
On 04/04/14 16:01, Chris Hegarty wrote:
Pavel,
The code changes and test update look good to me.
I think I agree with the approach here, but just to clarify the change
in behavior, that will be visible after the changes
Following JDK-8004963: URLConnection, downgrade normative reference to
${java.home}/lib/content-types.properties, this bug [1] moves
content-types.properties out of the image lib directory and into
resources.jar ( to be loaded as a resources file ). This approach is
acceptable, since the file
Adding build-dev ( for the makefile changes ).
-Chris.
Original Message
Subject: RFR [9] 8039362: Read content-types.properties as a resource
Date: Mon, 07 Apr 2014 15:27:43 +0100
From: Chris Hegarty chris.hega...@oracle.com
To: OpenJDK Network Dev list net-dev
,.html;\
[3] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46b53f80ab0a
/Erik
On 2014-04-07 16:33, Chris Hegarty wrote:
Adding build-dev ( for the makefile changes ).
-Chris.
Original Message
Subject: RFR [9] 8039362: Read content-types.properties as a resource
Date
java.net.URLConnection.getContent() incorrectly specifies the default location
of content handler classes as sun.net.www.content. ( this location is
implementation specific )
If no content handler factory has yet been set up, or if the factory's
createContentHandler method
returns
, that should not be in the public API.
-Chris.
On 09/04/14 12:44, Michael McMahon wrote:
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
wrote:
On 09/04/2014 14:13, Chris Hegarty wrote:
Flip-flop!
Thinking again about this, you're right.
http://cr.openjdk.java.net/~chegar/8039470/URLConnection-report.html
http://cr.openjdk.java.net/~chegar/8039470/URLConnection-report_01.html
I could go further with this change, but I just want
On 09/04/2014 22:18, Alan Bateman wrote:
On 09/04/2014 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
On 10 Apr 2014, at 08:36, Alan Bateman alan.bate...@oracle.com wrote:
On 09/04/2014 22:19, Chris Hegarty wrote:
http://cr.openjdk.java.net/~chegar/8039470/02/webrev/
That, that is easier to see the changes.
In URL then it's not clear to me why the javadoc has to admit to a system
This looks mainly good to me.
Just a few small comments (mainly on the use of reflection):
1) jdk/net/Sockets.java
You could use a SharedSecret to access the private methods in the
public java.net package, but reflection is ok too.
2) If you stick with reflection then if a lookup of any
601 - 700 of 1795 matches
Mail list logo
