hg: jdk8/tl/jdk: 8023130: (process) ProcessBuilder#inheritIO does not work on Windows

[alan . bateman]

Changeset: 56d247821694
Author:alanb
Date:  2013-09-23 04:05 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56d247821694

8023130: (process) ProcessBuilder#inheritIO does not work on Windows
Reviewed-by: alanb, martin
Contributed-by: ivan.gerasi...@oracle.com

! src/windows/native/java/lang/ProcessImpl_md.c
! test/java/lang/ProcessBuilder/Basic.java
+ test/java/lang/ProcessBuilder/InheritIO/InheritIO.java
+ test/java/lang/ProcessBuilder/InheritIO/InheritIO.sh

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

[Alan Bateman]

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 instance of 
the new HostLookupException subclass of UnknownHostException.

Issue
https://bugs.openjdk.java.net/browse/JDK-8010371

Webrev
http://cr.openjdk.java.net/~bpb/8010371


So is getaddrinfo returning EAGAIN or is it failing with EAI_SYSTEM and 
errno set to EAGAIN? I also wonder if the EAGAIN means the underlying 
syscall has been interrupted, in which case the normal thing to do is to 
retry.


-Alan

hg: jdk8/tl: 8006843: org.w3c.dom.events.UIEvent.getView is specified to return type that is not in the Java SE specification

[alan . bateman]

Changeset: 187a759c08ba
Author:alanb
Date:  2013-10-02 04:21 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/187a759c08ba

8006843: org.w3c.dom.events.UIEvent.getView is specified to return type that is 
not in the Java SE specification
Reviewed-by: mduigou, tbell

! common/makefiles/javadoc/CORE_PKGS.gmk

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

[Alan Bateman]

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. The usual testing is in progress.

Brian
This looks better, although I think I would reverse re-write the 
expressions to "if (error = ...)".


One thing to consider is whether this condition is really worth 
introducing HostLookupException, particularly when it doesn't include 
additional information (except to distinguish it from its supertype). If 
a new exception is really needed then maybe it could add the error 
message obtained from gai_strerror, alternatively maybe you could 
considered setting the cause of the UHE to something like an IOException 
with the translation of the error.


-Alan.

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

[Alan Bateman]

On 02/10/2013 12:40, Brian Burkhalter wrote:

:

1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then 
do one immediate native retry.
2) If the retry fails with the same error, then throw a UHE with a 
specific message or cause.


It's very possible the retry will fail the same way but should be 
harmless (modulo the delay if is a timeout).


Having the UHE be thrown with the message from gai_strerror would be 
must more useful. The reason I suggesting use a cause is because UHE has 
always been thrown with the host name as the detail message (and very 
possible that there are dependencies somewhere on this).


-Alan.

hg: jdk8/tl/jdk: 8025983: Typo in Javadoc of Files.isRegularFile()

[alan . bateman]

Changeset: 0ac9dc315071
Author:alanb
Date:  2013-10-07 11:48 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ac9dc315071

8025983: Typo in Javadoc of Files.isRegularFile()
Reviewed-by: mchung, chegar

! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/nio/file/Path.java

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

[Alan Bateman]

On 08/10/2013 00:00, Brian Burkhalter wrote:

Resuming this discussion …

Thanks for the previous comments. My feeling at this point is to do one of two 
things:

A) defer to something after JDK 8, or
B) on EAI_AGAIN do not retry but set the cause of the UAE to "new 
SomeException(gai_strerror(error))" where SomeException could be for example 
Exception, RuntimeException, or IOException.

Comments?

Throwing UHE with a useful message or cause would be best, so option B. 
However, I don't think it is critical for jdk8 as it's not a new issue 
(at least I think UHE has always been thrown with just the hostname, 
never the reason if it is known). So if there isn't time to be confident 
with the patch then it should be okay to move this out to 9.


-Alan.

hg: jdk8/tl/jdk: 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers

[alan . bateman]

Changeset: 95bb56c61276
Author:alanb
Date:  2013-10-08 10:49 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95bb56c61276

8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by 
all providers
Reviewed-by: chegar

! src/share/classes/java/nio/file/Files.java
! test/java/nio/file/Files/BytesAndLines.java

Re: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed

[Alan Bateman]

This looks like one for the net-dev list.

On 09/10/2013 09:10, Ivan Gerasimov wrote:

Hello all!

The MemLeakTest had been added with the fix for 8022584.
Since that, the test was reported to fail intermittently, even though 
the leak was eliminated.


I couldn't ever reproduce the failure even on the machines where the 
failure was detected.


Here are the changes I propose:
- Increase number of both warm-up and measured iterations,
- Number of iterations now indicates how many times a single interface 
is probed. It used to probe all the interfaces that many times.

- Increase the memory consumption threshold
- Increase the timeout

These should add some confidence that the failure of the test really 
indicates a memory leak.


In addition to that, in the case of a failure the list of all the 
network interfaces is displayed, so there will be some more 
information about the environment.


Here is the webrev: 
http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/


Sincerely yours,
Ivan Gerasimov

hg: jdk8/tl/jdk: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

[alan . bateman]

Changeset: 2ea162b2ff55
Author:alanb
Date:  2013-10-09 09:20 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ea162b2ff55

8008662: Add @jdk.Exported to JDK-specific/exported APIs
Reviewed-by: chegar, vinnie, dfuchs, mchung, mullan, darcy

! src/share/classes/com/sun/jdi/AbsentInformationException.java
! src/share/classes/com/sun/jdi/Accessible.java
! src/share/classes/com/sun/jdi/ArrayReference.java
! src/share/classes/com/sun/jdi/ArrayType.java
! src/share/classes/com/sun/jdi/BooleanType.java
! src/share/classes/com/sun/jdi/BooleanValue.java
! src/share/classes/com/sun/jdi/Bootstrap.java
! src/share/classes/com/sun/jdi/ByteType.java
! src/share/classes/com/sun/jdi/ByteValue.java
! src/share/classes/com/sun/jdi/CharType.java
! src/share/classes/com/sun/jdi/CharValue.java
! src/share/classes/com/sun/jdi/ClassLoaderReference.java
! src/share/classes/com/sun/jdi/ClassNotLoadedException.java
! src/share/classes/com/sun/jdi/ClassNotPreparedException.java
! src/share/classes/com/sun/jdi/ClassObjectReference.java
! src/share/classes/com/sun/jdi/ClassType.java
! src/share/classes/com/sun/jdi/DoubleType.java
! src/share/classes/com/sun/jdi/DoubleValue.java
! src/share/classes/com/sun/jdi/Field.java
! src/share/classes/com/sun/jdi/FloatType.java
! src/share/classes/com/sun/jdi/FloatValue.java
! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java
! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java
! src/share/classes/com/sun/jdi/IntegerType.java
! src/share/classes/com/sun/jdi/IntegerValue.java
! src/share/classes/com/sun/jdi/InterfaceType.java
! src/share/classes/com/sun/jdi/InternalException.java
! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java
! src/share/classes/com/sun/jdi/InvalidLineNumberException.java
! src/share/classes/com/sun/jdi/InvalidStackFrameException.java
! src/share/classes/com/sun/jdi/InvalidTypeException.java
! src/share/classes/com/sun/jdi/InvocationException.java
! src/share/classes/com/sun/jdi/JDIPermission.java
! src/share/classes/com/sun/jdi/LocalVariable.java
! src/share/classes/com/sun/jdi/Locatable.java
! src/share/classes/com/sun/jdi/Location.java
! src/share/classes/com/sun/jdi/LongType.java
! src/share/classes/com/sun/jdi/LongValue.java
! src/share/classes/com/sun/jdi/Method.java
! src/share/classes/com/sun/jdi/Mirror.java
! src/share/classes/com/sun/jdi/MonitorInfo.java
! src/share/classes/com/sun/jdi/NativeMethodException.java
! src/share/classes/com/sun/jdi/ObjectCollectedException.java
! src/share/classes/com/sun/jdi/ObjectReference.java
! src/share/classes/com/sun/jdi/PathSearchingVirtualMachine.java
! src/share/classes/com/sun/jdi/PrimitiveType.java
! src/share/classes/com/sun/jdi/PrimitiveValue.java
! src/share/classes/com/sun/jdi/ReferenceType.java
! src/share/classes/com/sun/jdi/ShortType.java
! src/share/classes/com/sun/jdi/ShortValue.java
! src/share/classes/com/sun/jdi/StackFrame.java
! src/share/classes/com/sun/jdi/StringReference.java
! src/share/classes/com/sun/jdi/ThreadGroupReference.java
! src/share/classes/com/sun/jdi/ThreadReference.java
! src/share/classes/com/sun/jdi/Type.java
! src/share/classes/com/sun/jdi/TypeComponent.java
! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java
! src/share/classes/com/sun/jdi/VMDisconnectedException.java
! src/share/classes/com/sun/jdi/VMMismatchException.java
! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java
! src/share/classes/com/sun/jdi/Value.java
! src/share/classes/com/sun/jdi/VirtualMachine.java
! src/share/classes/com/sun/jdi/VirtualMachineManager.java
! src/share/classes/com/sun/jdi/VoidType.java
! src/share/classes/com/sun/jdi/VoidValue.java
! src/share/classes/com/sun/jdi/connect/AttachingConnector.java
! src/share/classes/com/sun/jdi/connect/Connector.java
! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java
! src/share/classes/com/sun/jdi/connect/LaunchingConnector.java
! src/share/classes/com/sun/jdi/connect/ListeningConnector.java
! src/share/classes/com/sun/jdi/connect/Transport.java
! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java
! src/share/classes/com/sun/jdi/connect/VMStartException.java
+ src/share/classes/com/sun/jdi/connect/package-info.java
- src/share/classes/com/sun/jdi/connect/package.html
! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java
! src/share/classes/com/sun/jdi/connect/spi/Connection.java
! src/share/classes/com/sun/jdi/connect/spi/TransportService.java
+ src/share/classes/com/sun/jdi/connect/spi/package-info.java
- src/share/classes/com/sun/jdi/connect/spi/package.html
! src/share/classes/com/sun/jdi/event/AccessWatchpointEvent.java
! src/share/classes/com/sun/jdi/event/BreakpointEvent.java
! src/share/classes/com/sun/jdi/event/ClassPrepareEvent.java
! src/share/classes/com/sun/jdi/event/ClassUnloadEvent.java
! src/share/classes/com/sun/jdi/event/Event.java
! src/share/classes/com/sun/jdi/event/EventIterator.java
! src/share/classes/

hg: jdk8/tl/jdk: 7011859: java/util/concurrent/Semaphore/RacingReleases.java failing

[alan . bateman]

Changeset: 99b7bbe0474f
Author:dl
Date:  2013-10-10 09:57 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99b7bbe0474f

7011859: java/util/concurrent/Semaphore/RacingReleases.java failing
Reviewed-by: alanb, dholmes

! 
src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java

Re: RFR: 7076487 (sctp) SCTP API classes does not exist in JDK for Mac

[Alan Bateman]

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 existing jdk_sctp tests cover this.

http://cr.openjdk.java.net/~michaelm/7076487/webrev.1/
This looks okay to me (I didn't look at the Sctp* sources closely as I 
assume they are just a copy of the dummy implementation from src/windows).


A minor comment (a question) is whether there is a convention to sort 
the values of EXFILES or not. If there is then you might have to 
re-order them.


-Alan

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

[Alan Bateman]

On 09/10/2013 19:16, Brian Burkhalter wrote:

:
I have created a simple implementation for option B:

http://cr.openjdk.java.net/~bpb/8010371/webrev.3/

I should note that the Unix Inet6 implementation was already using the call 
ThrowUnknownHostExceptionWithGaiError() to generate the UHE so in this case the 
message should already have been useful. This call formats the UHE message such 
as would:

sprintf(error_message, "%s: %s", hostname, gai_strerror(error))

I changed the Unix Inet4 implementation to do this as well instead of calling 
JNU_ThrowByName().

Thanks for persevering with this, we are on the right road now.

I just looked at JDK-8010371 and the "OS" field is set to "linux". I 
don't know if this is right but as IPv6 is usually enabled by default 
these days then I have to guess that the person that submitted the bug 
has IPv6 disabled or is running with -Djava.net.preferIPv4Stack=true, 
otherwise it would be a non-issue (as you have discovered).


The other thing about your observation is that 
ThrowUnknownHostExceptionWithGaiError is creating the UHE with the both 
the hostname and the error message. This resolves to the concern in one 
or two of the mails that the UHE names the exception message "host" and 
that someone might assume that the exception detail is the hostname.


So thumbs up on the update to src/solaris/native/java/net/Inet4Address.c.



For Windows I added a similar NET_ ThrowUnknownHostExceptionWithGaiError and 
modified Inet{4,6} to mimic the Unix case. Note that the Windows code has not 
yet been compiled pending comments.

Inet4AddressImpl.lookupAllHostAddr uses gethostbyname and when I look at 
the MSDN documentation then I don't see EAI_AGAIN as possible error. It 
does list WSATRY_AGAIN and I'm wondering if they have the same value and 
whether the WSA* error is only returned by WSAGetLastError?


However I think we have a problem with using gai_strerror here as the 
MSDN documentation says that it is not thread safe. This means we may 
have to look for a WSA equivalent or maybe drop the Windows part of the 
fix (using a mutex of some synchronization might be possible but the 
scope would require research and of course it wouldn't work with 3rd 
party native code that is also using it).


-Alan

hg: jdk8/tl/jdk: 8019526: (fs) Files.lines, etc without Charset parameter

[alan . bateman]

Changeset: 9632de07d963
Author:alanb
Date:  2013-10-11 20:47 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9632de07d963

8019526: (fs) Files.lines, etc without Charset parameter
Reviewed-by: psandoz, henryjen

! src/share/classes/java/nio/file/Files.java
! test/java/nio/file/Files/BytesAndLines.java
! test/java/nio/file/Files/StreamTest.java

Re: Fix for JDK-8023555

[Alan Bateman]

On 12/10/2013 13:33, Tristan Yan wrote:


Please review fix for JDK-8023555

http://cr.openjdk.java.net/~pzhang/Tristan/webrev/ 



Thanks


Skipping the test when configured to be the loopback seems reasonable to 
me too. A minor comment on the message but it should be "a" rather than 
"an". Also to keep things consistent you should put a space in "if(".


-Alan.

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

[Alan Bateman]

On 10/10/2013 21:24, Brian Burkhalter wrote:On 10/10/2013 21:24, Brian 
Burkhalter wrote:

:
Assuming that the general idea is correct, there are a few possible 
alternatives for a final version for Windows. I am not concerned in this 
discussion about picky details including naming which can be fine tuned at the 
end.

1) In net_util_mh.c/NET_ThrowUnknownHostExceptionWithGaiError replace 
gai_strerror() with FormatMessage().

2) In Inet4AddressImpl.c and Inet6AddressImpl.c replace 
NET_ThrowUnknownHostExceptionWithGaiError with NET_ThrowByNameWithLastError 
(see net_md_util.c).

3) In net_md_util.c change (line 97 in 
http://cr.openjdk.java.net/~bpb/8010371/webrev.3/ version)

 { WSATRY_AGAIN, 0,  "Nonauthoritative host not found" },

to

 { WSATRY_AGAIN, "UnknownHostException",  "Nonauthoritative host 
not found" },

and in Inet4AddressImpl.c and Inet6AddressImpl.c replace 
NET_ThrowUnknownHostExceptionWithGaiError with NET_ThrowNew().

4) In NET_ThrowUnknownHostExceptionWithGaiError instead of using gai_strerror() use the 
hard-coded error message "Nonauthoritative host not found".

The pros and/or cons for each, respectively, are

1) Most closely matches the Unix version and avoids hard-coded messages.

2) Simple and obviates the need for 
NET_ThrowUnknownHostExceptionWithGaiError(), but the exception message has a 
different format from the Unix version and contains the error code instead of 
an error string.

3) Simple and obviates the need for 
NET_ThrowUnknownHostExceptionWithGaiError(), but the exception message format 
is slightly different from the Unix version and the change could have the 
undesirable (and unpredictable) side effect of an UnknownHostException being 
thrown somewhere else where a SocketException used to be thrown.

4) Simplest option but has distasteful hard-coding (as do option 3 indirectly 
and NET_ThrowNew() for that matter).

If the "con" of option 2 is acceptable then I think that would be the best way 
to go, otherwise option 1.

Option #2 seems reasonable, the exception messages for similar network 
conditions are rarely the same on Windows and Unix anyway. However I 
think it's important to have verified it with one or two errors to be 
confident that the errors translate as expected.


One other thing to add is that winsock_errors dates from early versions 
of Windows whether there wasn't a means to translate Windows Sockets 
errors. We should look at eliminating it (not for JDK 8 of course, it's 
too late) so that all errors are handle translated consistently.


-Alan

hg: jdk8/tl/jaxp: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc

[alan . bateman]

Changeset: de8c803d4958
Author:aefimov
Date:  2013-10-13 13:50 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/de8c803d4958

8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc
Reviewed-by: alanb, shade

! src/com/sun/org/apache/xpath/internal/XPathContext.java

hg: jdk8/tl/jdk: 8026398: Can't load jdk.Exported, ClassNotFoundException

[alan . bateman]

Changeset: 0b6632e570b0
Author:alanb
Date:  2013-10-15 10:52 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b6632e570b0

8026398: Can't load jdk.Exported, ClassNotFoundException
Reviewed-by: chegar, mchung

! make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

[Alan Bateman]

On 14/10/2013 20:43, Brian Burkhalter wrote:

:

Here's the patch updated for this option:

http://cr.openjdk.java.net/~bpb/8010371/webrev.4/ 



I think this is okay, the only concern is that the host name is no 
longer guaranteed to be in the exception detail (but for WSATRY_AGAIN 
then it might not matter because the problem is unlikely to be specific 
to the host name that is being looked up).


-Alan.

Re: RFR: JDK-8026245, , InetAddress.getLocalHost crash if IPv6 disabled (macosx)

[Alan Bateman]

On 15/10/2013 15:05, Rob McKenna wrote:

Hi folks,

Looking for a review for the following:

http://cr.openjdk.java.net/~robm/8026245/webrev.01/

It seems there were a number of issues with the original fix for 
7180557. This patch resolves those:


- No existing net tests exercised the ipv4 only codepath
- the extern to lookupIfLocalhost was in the wrong place
- as a result of the prior review the call to lookupIfLocalhost was 
moved to below the call to getaddrinfo. It was then decided to move it 
back. Unfortunately the if (error) block was left in.


-Rob
Good to see this one figured out. For the extern then it might be better 
to put it near the top of the file, alternatively local to 
lookupAllHostAddr.


In Inet6AddressImpl.c then is ni_preferIPv6AddressID needed? It looks 
like it is only needed in the initialize function.


For the tests then I assume you mean -Djava.net.preferIPv4=true 
(preferIPv4 and preferIPv6 aren't used, to my knowledge anyway).


-Alan

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

[Alan Bateman]

On 15/10/2013 16:28, Brian Burkhalter wrote:


The hostname is guaranteed to be in the exception detail:

void
NET_ThrowByNameWithLastError(JNIEnv *env, const char *name,
   const char *defaultDetail) {
char errmsg[255];
sprintf(errmsg, "errno: %d, error: %s\n", WSAGetLastError(), 
defaultDetail);

JNU_ThrowByNameWithLastError(env, name, errmsg);
}

The "hostname" string is passed to the third parameter in the above 
method.


For JNU_ThrowByNameWithLastError then the third parameter is the 
default/fallback, only used when the error cannot be translated. As I 
said, it's not a big deal as you are only using it for the WSATRY_AGAIN 
case.


-Alan.

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

[Alan Bateman]

On 17/10/2013 00:21, Brian Burkhalter wrote:

Dmitry,

I think you are correct: that slipped by both me and the reviewers. I have 
reopened the issue and posted an amendment to the original webrev here:

http://cr.openjdk.java.net/~bpb/8010371/webrev.4-amendment/

I've restored the bug fields and I assume you'll create a new bug for 
the follow-up. Sorry this was missed in the original review (probably 
because it went through so many iterations).


-Alan.

Re: JDK 8 RFR 8026806: Incomplete test of getaddrinfo() return value could lead to incorrect exception for Windows Inet 6

[Alan Bateman]

On 18/10/2013 00:10, Dmitry Samersoff wrote:

Brian,

Looks good for me (not a reviewer).

-Dmitry
I'm okay with it too (apologies we didn't catch it in the 10-iteration 
first round, I'm sure it slipped in during one of those iterations).


-Alan.

hg: jdk8/tl/jdk: 3 new changesets

[alan . bateman]

Changeset: da695008417f
Author:alanb
Date:  2013-10-18 13:45 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da695008417f

8026859: (fs) test/java/nio/file/Files/StreamTest.java fails to compile 
intermittently
Reviewed-by: psandoz

! test/java/nio/file/Files/StreamTest.java

Changeset: 4e065f5b4a16
Author:igerasim
Date:  2013-10-18 16:06 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e065f5b4a16

8026756: Test java/util/zip/GZIP/GZIPInZip.java failed
Reviewed-by: alanb

! test/java/util/zip/GZIP/GZIPInZip.java

Changeset: 329cf77821e8
Author:alanb
Date:  2013-10-18 13:51 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/329cf77821e8

7050570: (fs) FileSysteProvider fails to initializes if run with file.encoding 
set to Cp037
Reviewed-by: sherman, ulfzibis

! src/share/classes/sun/nio/fs/Util.java
! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java
! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java
! src/solaris/classes/sun/nio/fs/LinuxFileStore.java
! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java
! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java
! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java
! src/solaris/classes/sun/nio/fs/UnixException.java
! src/solaris/classes/sun/nio/fs/UnixFileStore.java
! src/solaris/classes/sun/nio/fs/UnixFileSystem.java
! src/solaris/classes/sun/nio/fs/UnixMountEntry.java
! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java

hg: jdk8/tl/jdk: 2 new changesets

[alan . bateman]

Changeset: 602aa6fa46c6
Author:alanb
Date:  2013-10-18 15:51 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/602aa6fa46c6

8026876: (fs) Build issue with 
src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java
Reviewed-by: psandoz

! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java

Changeset: 93f4f012deaf
Author:alanb
Date:  2013-10-18 16:01 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93f4f012deaf

Merge

hg: jdk8/tl/corba: 8021257: com.sun.corba.se.** should be on restricted package list

[alan . bateman]

Changeset: 52ad44f9a3ec
Author:alanb
Date:  2013-10-22 11:40 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/52ad44f9a3ec

8021257: com.sun.corba.se.** should be on restricted package list
Reviewed-by: chegar, coffeys, smarks
Contributed-by: alan.bate...@oralce.com, mark.shepp...@oracle.com

! src/share/classes/javax/rmi/CORBA/Stub.java
! src/share/classes/javax/rmi/CORBA/Util.java
! src/share/classes/javax/rmi/PortableRemoteObject.java
! src/share/classes/org/omg/CORBA/ORB.java

hg: jdk8/tl/jdk: 8024833: (fc) FileChannel.map does not handle async close/interrupt correctly

[alan . bateman]

Changeset: f15ad52cffed
Author:alanb
Date:  2013-10-22 12:04 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f15ad52cffed

8024833: (fc) FileChannel.map does not handle async close/interrupt correctly
Reviewed-by: alanb
Contributed-by: chris.w.den...@gmail.com

! src/share/classes/sun/nio/ch/FileChannelImpl.java
+ test/java/nio/channels/FileChannel/InterruptMapDeadlock.java

hg: jdk8/tl/jdk: 8021257: com.sun.corba.se.** should be on restricted package list

[alan . bateman]

Changeset: 6f9515a9519f
Author:alanb
Date:  2013-10-22 11:43 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f9515a9519f

8021257: com.sun.corba.se.** should be on restricted package list
Reviewed-by: chegar, coffeys, smarks, mullan
Contributed-by: alan.bate...@oralce.com, mark.shepp...@oracle.com

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/java/lang/SecurityManager/CheckPackageAccess.java

hg: jdk8/tl/jdk: 7074436: (sc) SocketChannel can do short gathering writes when channel configured blocking (win)

[alan . bateman]

Changeset: 54869853c06c
Author:alanb
Date:  2013-10-22 14:13 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54869853c06c

7074436: (sc) SocketChannel can do short gathering writes when channel 
configured blocking (win)
Reviewed-by: chegar

! src/windows/native/sun/nio/ch/SocketDispatcher.c
! test/java/nio/channels/SocketChannel/ShortWrite.java

Re: ProblemList updating request for JDK-7079145: java/net/ipv6tests/UdpTest.java

[Alan Bateman]

On 24/10/2013 03:59, Eric Wang wrote:

On 2013/10/24 10:57, Eric Wang wrote:

Hi,

This is a review request to remove the test 
java/net/ipv6tests/UdpTest.java from ProblemList.txt. The test 
tracked by JDK-7079145 
 is hung if linux 
kernel is 2.6.18.
By upgrading the kernel to higher version 2.6.32, the problem doesn't 
exist.


Thanks,
Eric

Sorry, forgot to update the webrev:
http://cr.openjdk.java.net/~ewang/7079145/webrev.00/ 

It's good to liberate this test. From what I can tell, 2.6.16 was 2006 
so I wouldn't expect too many people to be testing on that kernel nowadays.


-Alan.

hg: jdk8/tl/jdk: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable

[alan . bateman]

Changeset: 700d62b8d9cc
Author:alanb
Date:  2013-10-24 13:24 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/700d62b8d9cc

8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is 
Serializable
Reviewed-by: rriggs, psandoz, chegar
Contributed-by: d...@cs.oswego.edu, alan.bate...@oracle.com

! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java
! src/share/classes/java/util/concurrent/atomic/DoubleAdder.java
! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java
! src/share/classes/java/util/concurrent/atomic/LongAdder.java
+ test/java/util/concurrent/atomic/Serial.java

Re: RFR 8026880: NetworkInterface native initializing code should check fieldID values

[Alan Bateman]

On 29/10/2013 16:56, Chris Hegarty wrote:
This is a trivial change, good practice, to check return values from 
GetFieldID, and friends.


I've taken a quick look over the networking native code and see no 
other similar issues.


http://cr.openjdk.java.net/~chegar/8026880/webrev.00/
This looks okay but doesn't the Windows implementation need to be 
updated too?


-Alan

Re: RFR 8026880: NetworkInterface native initializing code should check fieldID values

[Alan Bateman]

On 29/10/2013 17:11, Chris Hegarty wrote:


D'oh, I spent too much time looking for other places where this was 
missing, and I forgot about src/windows!


Updated webrev:
  http://cr.openjdk.java.net/~chegar/8026880/webrev.01/

This looks okay to me.

-Alan

Re: URGENT - In correct push Fwd: [JBS] (JDK-8025198) Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

[Alan Bateman]

On 04/11/2013 12:10, David Holmes wrote:
My commit pulled in a bunch of local changes that should never have 
been pushed (the import commit failed due to whitespace and when I 
re-issued the commit I didn't restrict it to the single test file).


Can anyone roll this back on the actual server?
It might be simpler to just push another change that anti-deltas the 
launcher/other changes. That would get jdk8/tl fixed up before too many 
people are impacted.


-Alan.

Re: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java)

[Alan Bateman]

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 delete. So maybe move to public 
deleteWithRetry?
That might be a bit better as otherwise it's not obvious how it differs 
from Files.delete. Also to keep the names consistent then 
deleteTreeWithRetry should probably be deleteFileTreeWithRetry.


On interrupting the sleep then it looks like the methods aren't 
consistent, one will throw InterruptedException, the other will complete 
early without an exception and without the interrupt status set.


If you want then you could extend SimpleFileVisitor instead, that would 
allow you to drop the preVisitDirectory method.


A passing comment on closetest/Command is that the copyFile method could 
use Files.copy with REPLACE_EXISTING.


Also rm_minus_rf (amusing name) doesn't need to use isFile or 
isDirectory as FilesUtil.deleteFIleTree will do the right thing.


-Alan.

Re: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java)

[Alan Bateman]

On 07/11/2013 14:59, Chris Hegarty wrote:

Given both Michael and Alan's comments. I've update the webrev:
  http://cr.openjdk.java.net/~chegar/fileUtils.01/webrev/

1) more descriptive method names
2) deleteXXX methods return if interrupted, leaving the
   interrupt status set
3) Use Files.copy with REPLACE_EXISTING
4) Use SimpleFileVisitor, rather than FileVisitor

This looks better although interrupting the sleep means that the 
deleteXXX will quietly terminate with the interrupt status set (which 
could be awkward to diagnose if used with tests that are also using 
Thread.interrupt). An alternative might be to just throw the IOException 
with InterruptedException as the cause.


-Alan.

Re: RFR 8019834: InetAddress.getByName should always throw UHE for bad IPv6 literals

[Alan Bateman]

On 08/11/2013 11:32, Chris Hegarty wrote:
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 for a reply. The test, BadIPv6Addresses.java, tries to lookup 
many bad addresses, and was appearing to hang in our test environments.


If a bad IPv6 literal is passed into getByName, then the 
implementation should catch this early. It should not ever try to 
lookup the given name in lookupAllHostAddr. There is already code in 
getAllByName(String, InetAddress) to do this, there is just a bug in 
the logic.


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).


-Alan

8028074: InetAddress.getByName fails with UnknownHostException: invalid IPv6 address if host name starts with a-f

[Alan Bateman]

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 start with a-f. I ran into it because I happen to be on a 
machine that starts with "a" :-)


I'd like to get a patch into jdk8/tl quickly so that others don't run 
into this. The proposed patch is attached.


-Alan

diff --git a/src/share/classes/java/net/InetAddress.java 
b/src/share/classes/java/net/InetAddress.java

--- a/src/share/classes/java/net/InetAddress.java
+++ b/src/share/classes/java/net/InetAddress.java
@@ -1144,7 +1144,7 @@
 ifname = host.substring (pos+1);
 }
 }
-if ((addr = IPAddressUtil.textToNumericFormatV6(host)) 
== null) {
+if ((addr = IPAddressUtil.textToNumericFormatV6(host)) 
== null && host.contains(":")) {
 throw new UnknownHostException(host + ": invalid 
IPv6 address");

 }
 } else if (ipv6Expected) {

hg: jdk8/tl/jdk: 8028074: InetAddress.getByName fails with UHE "invalid IPv6 address" if host name starts with a-f

[alan . bateman]

Changeset: 50df04934e86
Author:alanb
Date:  2013-11-08 21:07 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50df04934e86

8028074: InetAddress.getByName fails with UHE "invalid IPv6 address" if host 
name starts with a-f
Reviewed-by: chegar

! src/share/classes/java/net/InetAddress.java

hg: jdk8/tl/jdk: 8028044: [TEST_BUG] Calendar shell tests do not pass TESTVMOPTS

[alan . bateman]

Changeset: 9130770fb6e3
Author:alanb
Date:  2013-11-09 16:46 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9130770fb6e3

8028044: [TEST_BUG] Calendar shell tests do not pass TESTVMOPTS
Reviewed-by: dholmes, alanb
Contributed-by: patrick.zh...@oracle.com

! test/java/util/Calendar/GenericTimeZoneNamesTest.sh
! test/java/util/Calendar/NarrowNamesTest.sh

Re: qualified host parameter for UnknownHostException?

[Alan Bateman]

On 08/11/2013 21:34, Bernd Eckenfels wrote:

Hello,

BTW: it would be good if UHE had a data member of the not-found host 
value. Actually the javadoc hints in that direction:


# public UnknownHostException(String host)
#
# Parameters:
#host - the detail message.

which is quite confusing. Maybe a new constructor like UHE(String 
cause, String host, String osError) would be really usefull?
The name of the parameter is confusing because the detail message can 
include both the hostname and the error details (if known). This came 
recently during the lengthy discussion about JDK-8010371 [1].


-Alan.

[1] http://mail.openjdk.java.net/pipermail/net-dev/2013-October/007390.html

hg: jdk8/tl/jdk: 8028099: Many com/sun/management/OperatingSystemMXBean tests failing with CCE (win)

[alan . bateman]

Changeset: 2525b91ca5a6
Author:alanb
Date:  2013-11-11 08:36 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2525b91ca5a6

8028099: Many com/sun/management/OperatingSystemMXBean tests failing with CCE 
(win)
Reviewed-by: mchung

! src/windows/classes/sun/management/OperatingSystemImpl.java

Re: RFR: 8028060 test/java/net/URLPermission/nstest/lookup.sh failing (win)

[Alan Bateman]

On 11/11/2013 15:37, Michael McMahon wrote:

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.net/~michaelm/8028060/webrev.1/


The ${PS} part looks fine. Changing LookupTest -getport to not emit a 
newline is okay too although I just worry that VM warnings or other 
output could be problematic.


So overall I think it's okay, but a good candidate to replace the shell 
tests with a pure java test at some point.


-Alan.

hg: jdk8/tl/jdk: 8028208: (aio) Assertion in clearPendingIoMap when closing at around time file lock is acquired immediately (win)

[alan . bateman]

Changeset: 0c414ac10700
Author:alanb
Date:  2013-11-12 17:37 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c414ac10700

8028208: (aio) Assertion in clearPendingIoMap when closing at around time file 
lock is acquired immediately (win)
Reviewed-by: chegar

! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
! test/ProblemList.txt

hg: jdk8/tl/jdk: 8028239: test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh with NoClassDefFoundError

[alan . bateman]

Changeset: c4c84b5a3dfa
Author:alanb
Date:  2013-11-13 07:43 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4c84b5a3dfa

8028239: test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh with 
NoClassDefFoundError
Reviewed-by: mchung, egahlin

! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh

hg: jdk8/tl/jdk: 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission

[alan . bateman]

Changeset: a493871959c2
Author:alanb
Date:  2013-11-13 16:52 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a493871959c2

8028270: Files.readSymbolicLink calls AccessController directly so security 
manager can't grant the permission
Reviewed-by: mchung, martin, chegar

! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java
! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
! test/java/nio/file/Files/CheckPermissions.java

hg: jdk8/tl/jdk: 8028343: More ProblemList.txt updates (11/2013)

[alan . bateman]

Changeset: ecf85f4aecf0
Author:alanb
Date:  2013-11-14 10:40 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecf85f4aecf0

8028343: More ProblemList.txt updates (11/2013)
Reviewed-by: chegar

! test/ProblemList.txt

hg: jdk8/tl/jdk: 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests

[alan . bateman]

Changeset: 2e574350a2b6
Author:alanb
Date:  2013-11-19 14:08 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e574350a2b6

8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests
Reviewed-by: dholmes, sla, tbell

! test/Makefile

hg: jdk8/tl: 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests

[alan . bateman]

Changeset: 9937f406e27e
Author:alanb
Date:  2013-11-19 14:11 +
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/9937f406e27e

8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests
Reviewed-by: dholmes, sla, tbell

! make/jprt.properties
! test/Makefile

Re: RFR 8028581: [TESTBUG] java/net/Socket/LingerTest.java failing

[Alan Bateman]

On 19/11/2013 15:18, Michael McMahon wrote:
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/webrev.1/
It's hard to believe that this timeout was exceeded but the change is 
harmless (and okay with me).


-Alan.

hg: jdk8/tl/jdk: 8028589: Instrument tools/jar/JarEntryTime.java to make it easier to diagnose failures

[alan . bateman]

Changeset: 36821ee241a2
Author:alanb
Date:  2013-11-19 15:09 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36821ee241a2

8028589: Instrument tools/jar/JarEntryTime.java to make it easier to diagnose 
failures
Reviewed-by: chegar

! test/tools/jar/JarEntryTime.java

Re: RFR for JDK-703666 test/com/sun/net/httpserver/Test9a.java fails intermittently

[Alan Bateman]

On 20/11/2013 04:59, Tristan Yan wrote:


/Hi All/

/I am working on https://bugs.openjdk.java.net/browse/JDK-703, 
this bug was opened 3 years ago and test was put into ProblemList. I 
ran a 1000 times loop to try to reproduce the failure but I got no 
luck. Also I use same jdk binaries run all regression tests a couple 
of hundred time I don't see any failure on this test either./


/I suggest we bring this test back from ProblemList and add a debug 
info for only possible failure place./


//

/http://cr.openjdk.java.net/~ewang/tristan/JDK-703/webrev.00/ 
/


//

/Please let me know if you have any suggestion or comments./

//

/Tristan Yan(Haibo Yan)/

//

I remember seeing this failing a few times (a lot time ago) but there 
was insufficient information to know why it failed. So print the stack 
trace and un-excluding the test seems the right thing to do (and we just 
hope that if it does fail again that someone will paste the stack trace 
into the bug).


-Alan

hg: jdk8/tl/jdk: 8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone

[alan . bateman]

Changeset: ecd6c25b54ce
Author:alanb
Date:  2013-11-20 21:34 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecd6c25b54ce

8028734: test/java/util/Locale/InternationalBAT.java changes does not restore 
the default TimeZone
Reviewed-by: naoto

! test/java/util/Locale/InternationalBAT.java

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

[Alan Bateman]

On 20/11/2013 18:26, Volker Simonis wrote:

Hi,

this is the second review round for "8024854: Basic changes and files 
to build the class library on AIX 
". The previous 
reviews can be found at the end of this mail in the references section.


I've tried to address all the comments and suggestions from the first 
round and to further streamline the patch (it perfectly builds on 
Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). 
The biggest change compared to the first review round is the new 
"aix/" subdirectory which I've now created under "jdk/src" and which 
contains AIX-only code.
Thanks for the update and addressing all the original comments and 
suggestions. In particular, moving most of the AIX specific files to 
src/aix and including an implementation of dladdr, make a big difference 
and makes this much easier to review.


I've skimmed through all the non-client files in the webrev and just 
have a few comments:


NetworkLibraries.gmk - is the exclude of bsd_close.c right? It looks 
like it will add this to LIBNET_EXCLUDE_FILES even when building on Mac.


In the old verifier code (check_code.c) then it's not clear to me that 
the caller wrapper is needed but in any case the change suggests to me 
that we should look at the malloc usages so that they better handle the 
size==0 case. I realize the wrappers are to avoid changing too much and 
it should be okay to handle this via a separate bug.


In net_util.c then it's a bit ugly to be calling aix_close_init. 
Michael/Chris - what you would think about the JNI_OnLoad calling into a 
platform specific function to do platform specific initialization?


The changes to java_md_solinux.c look okay to me but it makes me wonder 
if this should be renamed as it no longer exclusively Solaris + Linux.


Port.java - one suggestion for unregisterImpl is to rename it to 
preUnregister and change it to protected so that it's more obvious that 
it supposed to be overridden.


UnixNativeDispatcher.c - this looks okay (must reduced since the first 
round), I just wonder if the changes to *_getpwuid and *_getgrgid are 
really needed as this just impacts the error message. Also might be good 
to indent the #ifdef to be consistent with the other usages in these 
functions.


That's mostly it. I notice that only a small number of tests have been 
updated. Are there more test updates to come? I'm pretty sure we have a 
lot more tests that may require update (searching for SunOS might give 
some hints).


-Alan.

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

[Alan Bateman]

On 21/11/2013 15:54, Volker Simonis wrote:

:
But actually I've just realized that it is not need at all, because 
'aix_close.c' isn't in the PATH for any other OS than AIX (that could 
be probably called a feature of the new file layout:) So I'll simply 
change it to:

   48 ifeq ($(OPENJDK_TARGET_OS), aix)
   49   LIBNET_SRC_DIRS += $(JDK_TOPDIR)/src/aix/native/java/net/
   50 endif

This make sense.




Yes, exactly. I didn't wanted to change too much code. But as the 
C-Standard states 
(http://pubs.opengroup.org/onlinepubs/95399/functions/malloc.html) 
"...If size is 0, either a null pointer or a unique pointer that can 
be successfully passed to free() shall be returned..." it is perfectly 
legal that malloc/calloc return a NULL pointer if called with a zero 
argument. This case is currently not handled (i.e. it's handled as an 
'out of memory' error) in check_code.c and I agree that this should be 
fixed via a separate bug.

Yes, let's use a separate bug for this.




In net_util.c then it's a bit ugly to be calling aix_close_init.
Michael/Chris - what you would think about the JNI_OnLoad calling
into a platform specific function to do platform specific
initialization?


What about renaming 'initLocalAddrTable()' into something like 
'platformInit()' and moving the call to 'aix_close_init' to a 
AIX-specific version of 'platformInit()' in net_util_md.c?
I don't have a strong opinion on the name of the function, platformInit 
is fine for now.




:


You're right - we could rename it to something like 'java_md_unix.c'. 
But no matter how fancy the name would be, the file would still be in 
the 'src/solaris/bin' subdirectory:( So I think we'd better leave this 
for a later change when we completely factor  out the Linux/Mac code 
from the 'solaris/' directory.
I think JDK 9 is a good time to finally tackle this issue (as you 
probably know, this is something that I've brought up on porters-dev or 
build-dev a few times).




Port.java - one suggestion for unregisterImpl is to rename it to
preUnregister and change it to protected so that it's more obvious
that it supposed to be overridden.


Done. Also changed the comment to JavaDoc style to be more consistent 
with the other comments in that file.

Thanks.


UnixNativeDispatcher.c - this looks okay (must reduced since the
first round), I just wonder if the changes to *_getpwuid and
*_getgrgid are really needed as this just impacts the error
message. Also might be good to indent the #ifdef to be consistent
with the other usages in these functions.


You're right. This change was done before you fixed "7043788: (fs) 
PosixFileAttributes.owner() or group() throws NPE if owner/group not 
in passwd/group database" 
(http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f91c799f7bfb). After 
you're fix it was  "automatically" adapted. I've removed the special 
AIX handling as suggested because I think as well that another error 
message in the exception won't have any impact.

Thanks.



:


I'm currently working on it and created "8028537: PPC64: Updated 
jdk/test scripts to understand the AIX os and environment" for it 
because I didn't wanted to blow up this change unnecessarily.

Okay.

So overall I think this patch is in good shape (I have not reviewed the 
AWT/2D/client changes in any detail) and I don't see any blocking issues 
to this going in.


-Alan

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

[Alan Bateman]

On 26/11/2013 16:23, Volker Simonis wrote:

Hi,

thanks to everybody for the prompt and helpful reviews. Here comes the
final webrev which incorporates all the corrections and suggestions from
the second review round:

http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/

I've successfully build (and run some smoke tests) with these changes on
Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, MacOSX and
AIX (5.3, 7.1).


I've skimmed over the last webrev with focus on:

NetworkingLibraries.gmk where I see this is now fixed for all platforms.

net_util.* and the platform specific net_util_md.* where I see you've 
added platformInit so it's much cleaner.


UnixNativeDispatcher.c where the error translation is now removed (and 
looks fine).


So overall it looks good to me and should be pushed to the staging 
forest once you hear from others that commented previously.


-Alan

Re: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java

[Alan Bateman]

On 29/11/2013 14:21, Mark Sheppard wrote:

Hi
please oblige and review the following changes

http://cr.openjdk.java.net/~msheppar/8025211/webrev/
which address the issue raised in the bug
https://bugs.openjdk.java.net/browse/JDK-8025211

an intermittent failure occurs on some windows test machines.

this replaces a Thread.sleep(5000) with explicit synchronization 
between sender

and receiver via a CountDownLatch

(cc'ing net-dev)

Would an alternative here be to just get rid of the server thread (do 
both the send + receive on the main thread)?


-Alan

Re: RFR: 8029127: A redirect POST request does not work and illegalStateException on HttpURLConnection.getInputStream

[Alan Bateman]

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/

The change looks okay but I do have a few comments on the  test.

Copyright dates make it look like it came from 2006 :-)

Is the @compile tag right, shouldn't it compile RedirectOnPost too? 
Might be easier to use /com/sun/...  as / indicates the root of the test 
tree.


Import of javax.xml.soap, I can't see this being used.

Does the test really need to use SSL? I guess I don't like seeing tests 
need to grab files from other locations in the test tree.


Is "error" used?

Should the statics be moved into main?

runTest (L72-74), looks like the formatting is messed up here.

runTest - would be nice if this used try-with-resources.

Otherwise I think the test seems to cover the redirect okay, it just 
needs a bit of polishing so that it can be maintained.


-Alan.

Re: RFR: 8029354: URLPermission. throws llegalArgumentException: Invalid characters in hostname

[Alan Bateman]

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 classes) 
have been doing all the time
since the field is not directly of interest to http 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
I think this makes the most sense. Even more so when you consider 
configuring the policy to grant permission to GET or POST to a specific 
HTTP URL then this grant is independent of whether of any authentication 
that might be required.


-Alan.

Re: RFR: 8029354: URLPermission. throws llegalArgumentException: Invalid characters in hostname

[Alan Bateman]

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/webrev.2/

I added a test that uses the protocol handler. it should be reliable 
enough

as it does not actually go as far as opening an actual socket connection.


This does look much simpler and I think the approach is good.

A minor point on the wording, maybe "when creating a URLPermission" 
rather than "at object creation".


Also maybe "of this this" would be better as "defined by this class".

Does the userinfo = "" case need special handling now?

-Alan.

Re: Strange Issue With Static Global Variable in Native

[Alan Bateman]

On 07/12/2013 01:22, Dan Xu wrote:

Hi All,

When working on src/solaris/native/sun/net/spi/DefaultProxySelector.c, 
previously I tried to cached a jobject (The cached java object is 
java.net.Proxy.NO_PROXY, which is a special type of Proxy.) as a 
global static variable, no_proxy, in this c file. Its value is 
initialized in the init() native function call. In the following proxy 
query by calling native function, getSystemProxy(), I will just return 
this no_proxy object if no proxy is found.


But strangely, in the case that I return this no_proxy object back to 
java side, the program may throw an ClassCastException saying that the 
object that is passed to java side is a java.io.FileDescriptor instead 
of a java.net.Proxy. The problem only happened in jprt in test, 
java/net/ProxySelector/MultiThreadedSystemProxies.java. If I test it 
in my local linux, it seems always passed.


In addition, instead of caching this special proxy object, I modified 
my change to create no_proxy jobject every time I need by using the 
same code that I previously used to create no_proxy in the init() 
function. And the change can pass the jprt test without any issue. 
Does anyone know why the cached proxy object changed to a 
FileDescriptor? Thanks!


-Dan

Just so I understand, did you use a JNI global when caching the reference?

-Alan

Re: RFR: simple javadoc cleanup in java.net

[Alan Bateman]

On 18/12/2013 14:35, roger riggs 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.

-Alan

Re: RFR:JDK-7102702 - java/net/PortUnreachableException/OneExceptionOnly.java failing

[Alan Bateman]

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.

-Alan.

Re: RFR:JDK-7102702 - java/net/PortUnreachableException/OneExceptionOnly.java failing

[Alan Bateman]

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 address

If we think it worthwhile,
I can make the equivalent change in TwoStack, and re-execute the 
regression suites.


Out of curiosity, is TwoStack* even needed nowadays? I would think that 
once Windows XP is gone that it shouldn't be needed.


-Alan

Re: RFR: java/net/MulticastSocket/SetGetNetworkInterfaceTest.java throws java.net.SocketException: Cannot assign requested address

[Alan Bateman]

On 23/12/2013 18:21, Mark Sheppard 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 be due to an interface configured with 
an IPv6 address and
no IPv4 address. The native code was calling 
mcast_set_if_by_addr_v4(...), which

raised an exception.
Do you know what the exception is? Just wondering what exception is 
being cleared/ignored.


-Alan

Re: RFR: java/net/MulticastSocket/SetGetNetworkInterfaceTest.java throws java.net.SocketException: Cannot assign requested address

[Alan Bateman]

On 02/01/2014 16:26, Mark Sheppard wrote:

Hi Alan,
  added an ExceptionDescribe to native code and an -Xcheck:jni to the 
cmd line options to produce the

following:

Thanks, it is clearer now.

What you have is okay but I guess I'm just concerned that 
mcast_set_if_by_if_v4 can potentially fail for reasons other than 
setsockopt failing. Also the IPv6 mcast functions are more complicated 
and can potential fail for many reasons. I realize this is going beyond 
the scope of what you are looking at but would it make sense for these 
mcast functions to return an int (0 for success, non-0 when they fail) 
and only return with a pending JNI exception if a JNI function has 
failed. In other words? In other words, move the throwing of the 
network/SocketException to the caller so that it clearer to anyone 
reading the code where the errors are handled. That would give you 
something like:


rc = mcast_set_if_by_addr_v4(...)
if ((*env)->ExceptionOccurred(env)) return;

I'm not suggesting this has to be done now but I think the real issue 
here is that this code needs a bit of a clean-up (as it has grow over time).


-Alan

Re: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6

[Alan Bateman]

On 03/01/2014 11:04, Dimitar Mavrodiev wrote:

Greetings all,

I've fixed this and created a test to cover it, is there a sponsor who 
could push this through? Here's a link to the webrev 
https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/index.html.


It's a simple fix that correctly consumes the bytes from a SOCKS reply 
which represent an IPv6 address or a domain name. I also had to fix 
SocksServer as it was not correctly constructing a String 
representation of an IPv6 address from byte[].


I didn't find it necessary to cover the case of DOMAIN_NAME in the 
test as name resolution happens locally and not on the SOCKS server, 
which is perhaps worth another fix.



Thanks for the patch and I see that your OCA has been processed.

I checked section 5 of RFC 1928 and it does indeed appear that the 
DOMAINNAME (0x03) and IP V6 address (0x04) cases were not implemented 
correctly. Your patch looks right. In passing, I see that the constants 
for SOCKS are defined in an interface (which is an anti-pattern) and we 
should clean that up at some point (not necessary for this patch of course).


On the test then I think it will need to check that IPv6 is enabled as 
part of the setup, otherwise it looks like it will fail. I realize that 
IPv6 is enabled by default everywhere these days but we regularly test 
on machine that don't have it configured. One other thing about the test 
is that it will require a GPL header. Would you have cycles to expand 
the SOCKS test infrastructure to cover the DOMAIN_NAME case? I ask about 
that case because it was the lack of test coverage that meant this 
mis-handling slipped through (although I don't think it is actually used 
and doesn't appear to have been noticed before).


Otherwise, I think this is a good (and I would be happy to sponsor it).

-Alan.

Re: JDK 9 RFR of JDK-8031201: Fix casting lint issues in java.net

[Alan Bateman]

On 06/01/2014 19:36, Joe Darcy wrote:

Hello,

Please review the simple patch below to address

 JDK-8031201: Fix casting lint issues in java.net


This looks okay to me.

-Alan

Re: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6

[Alan Bateman]

On 06/01/2014 15:21, Dimitar Mavrodiev wrote:

Thanks, Chris.

I've removed the dependency on the internal HttpServer. Here's another 
webrev 
https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/2/index.html.
I'm not 100% sure how jtreg handles TestNG tests throwing SkipException. 
If it doesn't then it probably means adding a flag so that the test 
passes silently when IPv6 is not enabled.


-Alan

Re: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6

[Alan Bateman]

On 06/01/2014 16:39, Dimitar Mavrodiev wrote:
Ok, better safe than sorry. Here's the webrev 
https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/3/index.html.
Can you verify that it passes okay when you run jtreg with 
-vmoption:-Djava.net.preferIPv4Stack=true . I ask because I don't see a 
check in testSocksOverIPv6 and it looks like it will always try to 
connect to ::1.


-Alan.

Re: JDK 9 RFR of 8031326: Use Class rather than Class in java.net method signatures

[Alan Bateman]

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 me.

-Alan.

Re: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6

[Alan Bateman]

On 07/01/2014 12:29, Dimitar Mavrodiev wrote:

Hi Alan,

I've fixed that. Here's the webrev 
https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/4/index.html.



Thanks for the update, it seems to be okay now for IPv6 disabled case.

One thing I do see though is that the test fails intermittently on 
Windows (in my case Windows Server 2012) when IPv6 is enabled. The 
typical output is attached. I haven't dug into yet.


-Alan

[TestNG] Running:
  java/net/Socks/SocksIPv6Test.java

config SocksIPv6Test.setUp(): success
test SocksIPv6Test.testSocksOverIPv6(): failure
java.net.SocketException: Reply from SOCKS server has bad length
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:505)
at java.net.Socket.connect(Socket.java:585)
at java.net.Socket.connect(Socket.java:534)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
at sun.net.www.http.HttpClient.(HttpClient.java:211)
at sun.net.www.http.HttpClient.New(HttpClient.java:308)
at sun.net.www.http.HttpClient.New(HttpClient.java:326)
at 
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1122)
at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1101)
at 
sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:942)
at 
sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:940)

at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.AccessController.doPrivileged(AccessController.java:713)
at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:939)
at 
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:886)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1466)
at 
sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90)
at 
sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1386)
at 
sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1384)

at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.AccessController.doPrivileged(AccessController.java:713)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1383)

at SocksIPv6Test.testSocksOverIPv6(SocksIPv6Test.java:133)

Re: RFR: (8030875) Macros for checking and returning on exceptions

[Alan Bateman]

On 10/01/2014 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-8030875/
This looks okay to me. It would be good if Kumar takes a look at this 
too because it results in a mix of macros in the pack code.


-Alan

hg: jdk8/tl/jaxws: 8027908: serialVersionUID of javax.xml.bind.TypeConstraintException accidently changed

[alan . bateman]

Changeset: bd943bdbce05
Author:alanb
Date:  2014-01-13 16:17 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/bd943bdbce05

8027908: serialVersionUID of javax.xml.bind.TypeConstraintException accidently 
changed
Reviewed-by: alanb
Contributed-by: iaroslav.savyts...@oracle.com

! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

[Alan Bateman]

On 14/01/2014 08:40, Volker Simonis wrote:

Hi,

could you please review the following changes for the ppc-aix-port 
stage/stage-9 repositories (the changes are planned for integration 
into ppc-aix-port/stage-9 and subsequent backporting to 
ppc-aix-port/stage):
I'd like to review this but I won't have time until later in the week. 
From an initial look then there are a few things are not pretty (the 
changes to fix the AIX problems with I/O cancellation in particular) and 
I suspect that some refactoring is going to be required to handle some 
of this cleanly. A minor comment is that bug synopsis doesn't really 
communicate what these changes are about.


-Alan.

Re: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6

[Alan Bateman]

On 14/01/2014 08:28, Chris Hegarty wrote:

On 13 Jan 2014, at 19:29, Chris Hegarty  wrote:


On 13 Jan 2014, at 19:23, Dimitar Mavrodiev  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 is temporarily offline so I copied 
the webrev to a temporary server just 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.

http://cr.openjdk.java.net/~chegar/7100957/webrev.00/webrev/

The Buffered*, flush and try-with-resource changes look good. So will 
there be a combined webrev with everything? Also about about Dimi's 
change to readSocksReply to handle fragmentation, should that be 
included too?


-Alan.

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

[Alan Bateman]

On 15/01/2014 06:24, David Holmes wrote:


I'm not a fan of runtime checks of this kind though if it is only a 
very samll number of values it might be okay.


Another option would be to make those classes into "templates" as done 
with Version.java.template and substitute the right values at build time.


But I'll let Alan and net-dev folk come back with their preferred 
technique for this.


I plan to spend time on Volker's webrev later in the week (just too busy 
with other things right now). For the translation issue then it's an 
oversight in the original implementation, it just hasn't come up before 
(to my knowledge anyway). The simplest solution here maybe to to just 
move them to sun.net.ch.Net and have them initialized to their native 
value. In general then I'm not too concerned about that one, it's the 
changes to support async close on AIX that are leaping out at me.


-Alan

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

[Alan Bateman]

On 16/01/2014 09:38, Volker Simonis wrote:



Hi Alan,

I think sun.nio.ch.IOUtil seems even more appropriate to me for these 
constants. What do you think?


Would it be OK for you if I initialize them right in the static 
initializer of  IOUtil based on "os.name " or do you 
prefer to have native methods which return the right constants?
I have a small preference for sun.nio.ch.Net because these constants are 
used with Net.poll. Would you be open to separating this one from the 
AIX changes? The reason is that it isn't AIX specific, rather just an 
oversight that hasn't been an issue because it doesn't impact other 
platforms. Using os.name initially would be okay although we could 
change that over time.


-Alan

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

[Alan Bateman]

On 16/01/2014 16:26, roger riggs wrote:

Please review:

The native macros for checking and returning when exceptions
are thrown have been renamed to include the "JNU_" prefix
consistent with other functions in jni_util.h.

The macros have been renamed and existing uses in the jdk repository
for networking, pack200, and have been updated. A jprt run has passed 
(except for unrelated failures).


webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/
Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? They 
don't require a JNIEnv so I'm wondering if JNU_* really make sense here.


-Alan.

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

[Alan Bateman]

On 16/01/2014 10:34, Volker Simonis wrote:

:
I just thought because poll is more file-descriptor oriented and not
network specific. And the constants are also used for example in:

src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java:
src/solaris/classes/sun/nio/ch/sctp/Sctp*
src/solaris/classes/sun/nio/ch/Port.java

But actually I have no prefernece here so I can put them just as well
to sun.nio.ch.Net
It's not used for anything except sockets here (there aren't any 
selectable channels that aren't also network channels). So I think 
sun.nio.ch.Net is marginly cleaner here.




:

Sure, no problem. Although I still would like to push this to
ppc-aix-port/stage-9 and ppc-aix-port/stage first because that's where
we really need it. Anyway, the current plan is to merge
ppc-aix-port/stage-9 into jdk9 mainline by the end of January and
ppc-aix-port/stage into 8u-dev by the end of March (for 8u20). Would
that be ok?

I see you've created a bug for this. I guess it's okay if comes via the 
ppc port although would still be good to get it into jdk9/dev early as 
it impacts all platforms.


-Alan.

Re: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

[Alan Bateman]

On 17/01/2014 05:40, Tristan Yan wrote:

Hi All

Please review the simple code fix for JDK-8031666.

http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/

This test fails in very small chance. Adding socket timeout a little 
bigger.
Looking at JDK-8031666 then the failure seems to be with the runAfter + 
receive at end of test2. So I wonder have you the right issue number? In 
the webrev then you've increased the timeout for tests that expect to 
timeout (so I assume making the timeout longer just makes the test take 
longer).


As regards the runAfter + receive at the end then maybe the issue is 
that the runner thread was just slow to start, causing it to take more 
than 3 seconds (which I think is tolerance of 2s in checkTime).


-Alan

Re: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

[Alan Bateman]

On 17/01/2014 10:39, Tristan Yan wrote:

Agree, reset timeout should be better move
http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/
Thank you
Tristan

This looks okay but I just wonder if we also need to adjust the 
tolerance in checkTime. As I read it then it checks allows for +/- 50%, 
which in this case is 1000-3000ms. I just wonder if 3 seconds is enough 
given some of the extreme environment that these tests are expected to 
run in. Also the test doesn't look at the package contents and so the 
receive will complete if it receives anything. Maybe not for this fix 
but I assume the test should check that the expected packet is received.


-Alan

Re: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

[Alan Bateman]

On 17/01/2014 11:45, Chris Hegarty wrote:


On 17/01/14 11:24, Tristan Yan wrote:

Shall we adjust runAfter time a little bigger also if you're doing this.
Because if network is fast enough. All thing could be finished less than
3000 ms


No, this is just a wait/delay time before sending the packet. A simple 
update to the expected time, 2000 -> 4000, should be sufficient.

Yes, that would help as it would allow for a delay up to 6 seconds.

-Alan

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

[Alan Bateman]

On 20/01/2014 09:59, Volker Simonis wrote:

:
Hi Alan,

yes, that's interesting. Sounds like a very similar problem on Mac.

I would suggest the following:

I cut out the "Async Close AIX FIX" stuff from this change (i.e.
"8031581: PPC64: Addons and fixes for AIX to pass the jdk regression
tests" and send out a new webrev for the remaining part. I think that
the remaining part was more or less reviewed and we can then push it
faster.

In the mean time, I'll recheck which tests exactly fail with my
missing "Async Close AIX FIX" stuff and which of these tests will be
fixed by your 7133499 webrev. Maybe we can really get trough with it
or with it and a few enhancements. I'll let you know my results later
today. By the way, my webrev already contained a AixNativeThread.c
implementation in src/aix/native/sun/nio/ch.

The only remaining problem I see with this approach is that we would
need to downport your 7133499 change to 8u-dev in the 8u20 time frame
to make our AIX port work. Would this be OK for you?

I'm okay with this plan and if you re-generate the webrev without the 
async close changes then I can look at it quickly so that you can get it 
into the stage-9 forest.


On 7133499 then it would be a good candidate for 8u-dev too, I don't 
expect any problems but we will need to get it approved on the jdk8u-dev 
list.


-Alan.

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

[Alan Bateman]

On 20/01/2014 13:45, Volker Simonis wrote:

:
Hi everybody,

so here's the second version of this webrev:

http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/

This looks okay to me.

The typo ("legel" -> "legal") still exists in zip_util.c and maybe that 
can be fixed before you push this (no need to generate a few webrev of 
course).


For the JDWP socket transport then it's interesting that shutdown is 
being used to cause the reader thread to be preempted. That may be 
useful when it comes to addressing the bigger async close issue.




The main changes compared to the first webrew are as follows:

  - the POLL-constants related stuff has been factored out into its own
webrev ("8031997: PPC64: Make the various POLL constants system
dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997).
I see this has been pushed to ppc-aix-port/stage-9. Would you have any 
objection if I brought this into jdk9/dev (minus the AixPollPort 
change)? We can use a different bug number so as not to cause duplicate 
bug issues. It should trivially merge when you come to sync'ing up the 
staging forest.




  - the "Async close on AIX" workarounds have been taken out as well
and will be handled separately
Thanks for separating this one out as I suspect this that doing this 
cleanly is going to involve changes for all platforms.


-Alan.

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

[Alan Bateman]

On 20/01/2014 16:29, Volker Simonis wrote:

:

@Alan: on the other hand, the bulk integration from
ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so
maybe you could wait until that happens?

In that case then ignore my request, I assumed it would not be pushed to 
jdk9/dev until end-Feb.


-Alan

hg: jdk8/tl/jdk: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X

[alan . bateman]

Changeset: b56ff7d30a72
Author:alanb
Date:  2014-01-24 11:50 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b56ff7d30a72

8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on 
OS X
Reviewed-by: sla, chegar, psandoz

! src/solaris/native/common/jni_util_md.c

Re: RFR [9] 7150539: HttpURLConnection.getResponseMessage() doesn't throw IOException on server error (OS X)

[Alan Bateman]

On 31/01/2014 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 settings.

Looks good to me too.

-Alan

Re: RFR: 8033425 Delay loading of net library in PortConfig initialization (workaround for for 8033367)

[Alan Bateman]

On 03/02/2014 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,
hence there is no regression test.

Michael

This looks good to me.

-Alan.

Re: RFR: 8028725: [Parfait] warnings from b116 for jdk.src.solaris.native.java.net: JNI pending exceptions

[Alan Bateman]

On 04/02/2014 11:05, Michael McMahon wrote:

Adding some checks for pending exceptions in the InetAddress native code.

http://cr.openjdk.java.net/~michaelm/8028725/webrev.1/

This looks okay to me. Does the Windows code need the same changes?

-Alan

Re: RFR: 8028725: [Parfait] warnings from b116 for jdk.src.solaris.native.java.net: JNI pending exceptions

[Alan Bateman]

On 04/02/2014 11:24, Alan Bateman wrote:

On 04/02/2014 11:05, Michael McMahon wrote:
Adding some checks for pending exceptions in the InetAddress native 
code.


http://cr.openjdk.java.net/~michaelm/8028725/webrev.1/

This looks okay to me. Does the Windows code need the same changes?
Ignore my mail, I read it as Inet4* and Inet6* but I see you've done 
both the Unix and Windows implementation.


-Alan.

Re: RFR [9] Inet[4|6]Address class and fieldID initialization in networking native code

[Alan Bateman]

On 04/02/2014 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.

This is a good clean-up and looks good to me.

-Alan.

8034182: Misc. warnings in java.net code

[Alan Bateman]

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 to check the 
return value from setInet6Address_ipaddress but the return is an int 
rather than a pointer. In PlainDatagramSocketImpl's mcast_join_leave 
then the issue is using a jbyte* when a char* is expected. In 
Inet6AddressImpl.c then the warning is code before declaration (the 
SunStudio compilers complain about that).


While looking at these warnings then I noticed that the 
setInet6Address_XXX functions (and one of the get functions) return a 
jboolean but are declared to return an int. While not wrong, it's not 
obvious so I changed these functions to return a jboolean.


The webrev with the proposed changes is here:

http://cr.openjdk.java.net/~alanb/8034182/webrev/

-Alan.

Re: Adding values to enum java.net.StandardProtocolFamily

[Alan Bateman]

On 13/02/2014 12:54, Florian Weimer wrote:
Can we add further enumeration values to 
java.net.StandardProtocolFamily?  The spec does not say so, unlike 
javax.lang.model.SourceVersion, and the code in the JDK expects a 
binary flag, so I think the answer is "no".


Does this mean the expected way to add support for further protocol 
families would be to create a separate implementation of 
java.net.ProtocolFamily?


If there are protocol families that will be part of Java SE and 
supported in all implementations then they could be added 
StandardProtocolFamily. On the other hand, if this is platform or JDK 
implementation specific then implementing ProtocolFamily is the way to 
go (the enum extending interface pattern is something that we've used in 
other areas too).


-Alan

Re: Adding values to enum java.net.StandardProtocolFamily

[Alan Bateman]

On 13/02/2014 15:04, Florian Weimer wrote:


Naming is fundamentally different.  With that caveat, it would be 
possible to expose a socket-based interface, but application code 
would have to adhere to the platform naming convention.


When we prototyped this in the past then we used a new SocketAddress 
type for naming. In general, this requirement has been around for a long 
time, it just has never been high priority so this is why it hasn't been 
done.


-Alan.

Re: Remove support for old socket implementations

[Alan Bateman]

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 okay in principle?  Could you create bug ID for this?

I don't have any objection but I think it requires a bit of discussion 
and some insight into whether anyone might be running with ancient 
SocketImpl (that would have been compiled a long time ago).


-Alan.

Re: RFR [9]: 8034174 Remove use of JVM_* functions from java.net code

[Alan Bateman]

On 22/02/2014 08:29, Chris Hegarty wrote:

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 changed to be "false" so that it is disabled by 
default. It is now finally being removed.

This bug tracks changing the native in src/share/native/java/net and 
src/solaris/native/java/net so that the system calls are used directly rather 
than going through the JVM_* functions.

http://cr.openjdk.java.net/~chegar/8034174/webrev.00/webrev/


Thank for you for doing this, it's long over due.

I've taken a first pass over this and it looks good. For NET_RecvFrom 
and other that take a socket address then maybe the len should be a 
size_t rather than int (they may have been in the JVM_* function due to 
difference in the definitions of size_t, which is no longer a concern 
here I think).


One comment on the Windows changes is that it might be clearer if they 
were changed to check for SOCKET_ERROR rather than -1 as that matches 
the Windows Sockets documentation.


I also notice that several of the files include jvm.h and I wonder if 
this is needed now.


In JNI_OnLoad then it uses GetEnv to check the JNI version and I assume 
this code can just be removed.


In net_util.h the removal of JVM_* means it means "like the system 
procedures", maybe it should be system calls or system functions.


-Alan.

Re: RFR [9]: 8034174 Remove use of JVM_* functions from java.net code

[Alan Bateman]

On 22/02/2014 14:03, Bernd Eckenfels wrote:

Hm, I actually like to have that JVM_ abstraction layer. Looks like it is now 
replaced by NET_ in some parts, do we really want to remove it in others? (the 
JVM_IO_ERR beeing an obvious advantage)

Support for green threads went away when we moved to HotSpot back in JDK 
1.3 and since then there hasn't been any need for socket and other 
blocking operations to go through the JVM interface. The residual usage 
in the classic networking code has been because of Solaris interruptible 
I/O and that has been disabled by default since JDK 7. We removed the 
use of the JVM_ functions in other parts of the platform in JDK 7 so 
Chris's work is really just a continuation of this effort. Eventually it 
should be possible to just remove these functions from the JVM interface 
and this would be a welcome cleanup.


As regards a general porting/abstraction interface then it doesn't 
exist. The Host Porting Layering (HPI) bit rotted a long time ago and 
was eventually removed (several years ago). To date there hasn't been a 
big need for a replacement. There is certainly work that could be done 
to improve the portability in many areas, it just hasn't been a priority.


-Alan

Re: RFR[9](XS): 8035876: AIX: Fix AIX build after '8034174: Remove use of JVM_* functions from java.net code'

[Alan Bateman]

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/
https://bugs.openjdk.java.net/browse/JDK-8035876


This looks okay to me.

-Alan

Re: RFR[9](M): 8035949 : Remove unused macro USE_SELECT and clean up Unix version of net_util_md.{c,h}

[Alan Bateman]

On 28/02/2014 14:08, Chris Hegarty wrote:

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' ).



It looks okay to me too.

AFAIK, USE_SELECT was a build time option a long time ago (when the JDK 
had the HPI). It's good to see this dead code go away now.


-Alan.