On 16/07/2019 14:48, Claes Redestad wrote:
Hi,
refactored to use a BootLoader::loadLibrary API that is only visible
within the java.base module:
http://cr.openjdk.java.net/~redestad/8227587/open.03/
I've retained the bridge to ClassLoader::loadLibrary for performance,
but without any magic or
On 19/07/2019 16:35, František Kučera wrote:
Hello,
I am interested in the unix domain sockets (UDS, AF_UNIX) support in Java.
Java is able to inherit a channel from the parent process and access
it through System.inheritedChannel(). The channel is passed as an open
file descriptor (FD) to J
On 19/07/2019 13:51, Claes Redestad wrote:
Hi,
please review this cleanup to remove a few java.net access objects that
are no longer in use.
Webrev: http://cr.openjdk.java.net/~redestad/8228394/open.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8228394
(One usage was from sun.misc.Cl
On 18/07/2019 15:43, Patrick Concannon wrote:
Oh OK, I didn't realise. Thanks for pointing this out, Alan!
I've removed the 'othervm' tag, and added it to the new webrev below.
http://cr.openjdk.java.net/~aefimov/pconcann/8227721/01/
This looks good to me.
-Alan
On 17/07/2019 17:52, Patrick Concannon wrote:
:
This fix sets the test to run in 'othervm' mode, and gives 'open'
access to 'java.net' to the unnamed module (where the test lives).
I don't think you need to run the test in /othervm mode as jtreg will
look after spinning up a new agent VM whe
On 24/06/2019 21:57, Rob Spoor wrote:
I found a bug in Inet6Adress.isIPv4CompatibleAddress(). While parsing
correctly uses the ::: format, isIPv4CompatibleAddress()
checks for :: instead.
The notion "IPv4-compatible IPv6 address" is different to "IPv4-mapped
IPv6 address". I think the RFCs
On 18/06/2019 13:53, Andre Naujoks wrote:
:
We tried the old test-code with the Java Version from Debian
experimental and it does indeed work now on linux.
Thanks for confirming.
Java on Windows still throws an Exception when trying to bind like this.
This shouldn't be a big surprise. It's ve
On 02/05/2019 09:25, Alan Bateman wrote:
On 02/05/2019 08:44, Andre Naujoks wrote:
Hello all.
I just noticed, that the fix from Bug JDK-8210493 was reverted for Java
12. With a new bug JDK-8215294 taking over the issue.
Yes, it caused problems so had to be reverted. In addition to
JDK-8215294
On 12/06/2019 11:21, Chris Hegarty wrote:
The fix for JDK-8224477 missed the `@` in a couple of code tags.
Looks good.
On 11/06/2019 18:14, Michael McMahon wrote:
Hi Alan
I've made the suggested changes. I need to confirm with Pavel what the
background
was for the Linux kernel check. For now, it is still there in the
test. Maybe, that could
be removed as part of another change later, if that turns out to be
p
On 11/06/2019 12:11, Michael McMahon wrote:
Thanks for the review Alan.
I've made the changes suggested by you and Daniel
and added a test to Scoping.java for checking the connected IP address.
http://cr.openjdk.java.net/~michaelm/8216417/webrev.3/index.html
One suggestion for the AbstractPlainS
On 10/06/2019 15:18, Michael McMahon wrote:
Hi,
Could I get the following change to net/nio reviewed please?
It is a general cleanup of IPv6 scope_id handling which removes
a lot of native code trickery (mostly in Linux) and simplifies the
handling
of scope_ids such that:
a) when binding/con
On 07/06/2019 19:46, Chris wrote:
java.net.SocketAddress can represent an IPv6 address with port.
Because parts of an IPv6 address are separated with colons and a colon
is also used to separate the address from the port, RFC 2732 specifies
that the address be in square brackets in this case, e.g.
On 07/06/2019 15:16, Chris Hegarty wrote:
:
“socket implementation factory” is better. Updated:
Looks good, many inconsistencies resolved. For the CSR then the only
real change is the no-arg Socket constructor to specify existing
behavior, everything else is below the radar.
-Alan
On 07/06/2019 14:20, Chris Hegarty wrote:
Alan, Daniel,
On 7 Jun 2019, at 13:07, Alan Bateman wrote:
On 07/06/2019 12:24, Chris Hegarty wrote:
...
Replacing with "plain" with system-default is okay but it does remind me of
problems in the other constructors. The no-
On 07/06/2019 12:24, Chris Hegarty wrote:
Another minor followup that we agreed to address after the integration
of 8221481 (Reimplement the Legacy Socket API).
Prior to 8221481, there was just a single default SocketImpl, the
"plain" socket impl. There are now two, PlainSocketImpl and
NioSocket
On 06/06/2019 16:25, Chris Hegarty wrote:
The changes in 8220493 (Prepare Socket/ServerSocket for alternative
platform SocketImpl) disallow a number of scenarios where it is not
possible for `ServerSocket::implAccept` to accept a new connection with
a given Socket.
Right, the original CSR has all
On 06/06/2019 12:07, Chris Hegarty wrote:
Prior to 8221481 (Reimplement the Legacy Socket API), these tests were
run with the plain socket impl. They should be run with both
system-default SocketImpls to ensure that the impls behave as expected.
Looks good.
On 04/06/2019 13:56, Chris Hegarty wrote:
Alan,
On 4 Jun 2019, at 13:50, Alan Bateman wrote:
On 04/06/2019 13:48, Chris Hegarty wrote:
Updated as suggested:
https://cr.openjdk.java.net/~chegar/8225214/webrev.01/
I assume soLinger doesn't need to be public. I guess I'd
On 04/06/2019 13:48, Chris Hegarty wrote:
Updated as suggested:
https://cr.openjdk.java.net/~chegar/8225214/webrev.01/
I assume soLinger doesn't need to be public. I guess I'd rename it
something like testSoLingerValues so that it's a bit cleaner when
reading the call in doSocketTests but what
On 04/06/2019 12:54, Chris Hegarty wrote:
Please review this change to fix a bug in the handling of SO_LINGER in
the plain socket impl, when setting or retrieving the option through
the new-style setOption or getOption, respectively. The implementation
of the new-style option just delegates to th
On 03/06/2019 16:17, Arthur Eubanks wrote:
I don't think it's a big difference either way, but changed it to
System.out. Also added some extra info to the "Exception Tests"
log to show the addresses it's testing. Now it looks like:
webrev.03 looks okay to me.
-Alan
This looks okay. Hopefully we can get rid of this code as part of the
fix for 8216417.
-Alan
On 30/05/2019 15:54, Chris Hegarty wrote:
The test for 8224730 [1] exposes an issue in the macOS package-private
java.net.DefaultInterface - NetworkInterface::getInetAddresses is
invoked without a doPr
On 30/05/2019 12:04, Chris Hegarty wrote:
The current default implementation of openConnection(URL,Proxy) simply
throws UnsupportedOperationException. Pedantically, this violates its
own specification, since it does not throw IllegalArgumentException when
passed a null value.
To resolve this, th
On 29/05/2019 14:48, Chris Hegarty wrote:
:
On 29/05/2019 12:50, Alan Bateman wrote:
One suggestion is to rename the socketAdapterXXX methods to
serverSocketAdaptorXXX to align with the class name. Otherwise looks
good.
Yes, that is better.
Updated webrev:
https://cr.openjdk.java.net
On 29/05/2019 17:27, Arthur Eubanks wrote:
:
Moved NetworkConfiguration.printSystemConfiguration() to the
beginning, removed counting and printing the number of
interfaces/throwing SkippedException.
new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.02/
This looks okay to me, the
On 29/05/2019 12:36, Chris Hegarty wrote:
Good idea. I've expanded the test to cover the ServerSocket adapter too.
Good news is that it found no issues ( but of course will increase
coverage and catch possible future accidental breakages ).
Webrev:
https://cr.openjdk.java.net/~chegar/8224730/
On 29/05/2019 09:19, Chris Hegarty wrote:
:
The test already has a test library dependency, so the addition of
SkippedException does not introduce any new significant burden
for standalone testing.
There are a couple of tests in the nio/channels area that are useful to
run outside of the jtreg e
On 29/05/2019 08:28, Daniel Fuchs wrote:
Would you prefer to throw AssertionError instead? It's also
a possibility. Chris thought it might be "too strong".
It might be odd to have a test system configured without multicast
enabled but it's not wrong. So I think the test should pass.
:
Right
On 29/05/2019 08:08, Daniel Fuchs wrote:
The idea is that if a test machine has no IPv4 and no
IPv6 multicast interfaces then it's probably misconfigured.
Also if a regression is introduced that causes this to happen,
then we'd probably want to see it.
AFAIK the SkippedException is a good matc
On 28/05/2019 15:39, Chris Hegarty wrote:
Please review this small change to ServerSocket::toString so that it
correctly implements its specified behaviour ( to reveal the local
address if SecurityManager::checkConnect succeeds ). Looks like this was
a minor oversight in the implementation that w
On 28/05/2019 18:27, Arthur Eubanks wrote:
:
new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.01/
The purpose of L237-244 isn't clear. Maybe it's useful to print the
count of interfaces supporting multicast but it is necessary to throw
SkipException when the count is 0? For debu
On 27/05/2019 19:37, Chris Hegarty wrote:
:
Thanks, both issues resolved in-place.
Looks good.
:
ServerSocket options are mentioned here as that is the behaviour in
the current shipping release ( to return the server related options ), not
the client related ones, see
http://hg.openjdk.
On 27/05/2019 16:48, Chris Hegarty wrote:
Updated webrev:
https://cr.openjdk.java.net/~chegar/8224477/webrev.04/
This version looks good.
A minor nit is that there's a blank line added to
SocketChannelImpl.setOption that separates a comment from the code that
it documents, I assume this i
On 27/05/2019 11:48, Chris Hegarty wrote:
This next iteration addresses all of Alan's comments and suggestions.
Additionally, while here we can take the opportunity to cleanup the spec
inconsistencies of the getOption/setOption methods across the socket
impls. The current default implementation
On 23/05/2019 18:19, Arthur Eubanks wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8224645
webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.00/
Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails
with NoSuchElementException on Solaris.
java.util.NoSuchElemen
On 23/05/2019 17:32, Chris Hegarty wrote:
Thank you Alan,
I believe that I addressed all your comments and suggestions.
Additionally, while here I noticed an issue where these methods were not
always consistent with their spec to throw IOException when the socket
has been closed.
https://cr.op
On 23/05/2019 11:30, Daniel Fuchs wrote:
Hi,
I have observed an intermittent failure on Solaris.
So I changed the patch to problem-list the test on all platform.
Is that still OK?
http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01
Looks fine.
On 22/05/2019 13:54, Chris Hegarty wrote:
While we're here, let's address both the NPE and the IAE.
Okay, I only mentioned it because the JIRA issue had two cases. Also
it's one that we came across when working on the new implementation (it
is called out as a compatibility difference in the Ri
On 21/05/2019 19:36, Chris Hegarty wrote:
The get/setOption methods of java.net Socket, ServerSocket, and
DatagramSocket, are specified to throw NullPointerException if the given
option name is null ( rather than UnsupportedOperationException, which
is currently thrown ). The implementation corre
On 17/05/2019 18:22, Arthur Eubanks wrote:
Done, order is protocol family, group/notGroup InetAddress,
NetworkInterface, source InetAddress
http://cr.openjdk.java.net/~aeubanks/8224019/webrev.02/
Thanks, this version looks okay to me.
-Alan
On 16/05/2019 23:38, Arthur Eubanks wrote:
I've added testing exceptions to IPv6 as well, PTAL.
This required hardcoding IPv4 and IPv6 loopback addresses for the IPv4
and IPv6 code paths. Else DatagramChannel.join() fails since you can't
mix IPv4 and IPv6 addresses, and InetAddress.getLocalHost
On 16/05/2019 01:45, Arthur Eubanks wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8224019
webrev: http://cr.openjdk.java.net/~aeubanks/8224019/webrev.00/index.html
test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java
assumes
NetworkConfiguration.probe().ip4MulticastInterf
Thanks Chris and Michael for the reviews/help so far. I've uploaded a
new webrev to address most of their points here:
http://cr.openjdk.java.net/~alanb/8221481/2/webrev/index.html
and delta webrev with the changes from 1 to 2 here:
http://cr.openjdk.java.net/~alanb/8221481/1to2/webrev/ind
On 09/05/2019 12:02, Chris Hegarty wrote:
:
I agree that the method name could be improved. It’s really:
“skip test if cannot create a minimally-operational IPv4 or IPv6 socket"
Some concrete method name suggestions ( more welcome ):
- IPSupport::skipTestIfNonOperational
- IPSupport::ski
On 09/05/2019 11:51, Michael McMahon wrote:
Ok, thanks. A test that might be useful could be one that compares the
supported options between the old
and new impls for both client and server sockets. I guess it shouldn't
be required for the initial push though.
There are several existing tests
On 09/05/2019 10:21, Daniel Fuchs wrote:
On 09/05/2019 08:09, Alan Bateman wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8223573/webrev.00/
I skimmed through the diffs and they look okay with me. Minor nit in
6550798/test.java is there is a space in "HttpServer.create (". Also
wo
On 08/05/2019 18:24, Daniel Fuchs wrote:
Hi,
Please find below another patch in the series for intermittently
failing tests:
8223573: Replace wildcard address with loopback or local host in
tests - part 4
https://bugs.openjdk.java.net/browse/JDK-8223573
patch:
http://cr.openjdk.java.n
On 08/05/2019 12:02, Chris Hegarty wrote:
:
New webrev: http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/
:
P.S. adding nio-dev since there are a few tests in that area
being updated.
Thanks for forwarding.
IPSupports.skipIfConcurrentConfigurationIsInvalid is a bit strange and I
thi
On 08/05/2019 16:25, Chris Hegarty wrote:
This is a nice. The code is well structured and much more readable than
the plain implementation.
Thanks for doing through the implementation.
:
NioSocketImpl.java
If configureBlocking returned a boolean, then an assert could be
written to ensure t
On 08/05/2019 12:51, Chris Hegarty wrote:
While the vast majority of libnet.so is devoted to socket related
implementation, not all is. There are a small number of low-level pieces
of functionality that can be used with support for either IPv4 or IPv6
being present. The NIO implementation als
On 07/05/2019 17:30, Chris Hegarty wrote:
On 1 May 2019, at 14:10, Alan Bateman <mailto:alan.bate...@oracle.com>> wrote:
JEP 353 [1] is now a candidate and I would like to get the CSR [2]
finalized and the changes reviewed so that it can be targeted.
The webrev with the change
On 07/05/2019 16:44, Michael McMahon wrote:
Hi Alan,
What's the purpose of the change to the UdpTest?
The deprecated Socket constructors can be used to create a Socket that
uses UDP. This means the new SocketImpl has to support the creation of
UDP sockets and use the ResourceManager to enforce
On 07/05/2019 16:39, Daniel Fuchs wrote:
Thaks Alan!
On 07/05/2019 16:17, Alan Bateman wrote:
This looks good. In passing, it might be clearer if
AcceptInheritHandle.test named is argument args rather than sysProps
as it's an array of arguments for the child. Also you coul
On 07/05/2019 16:06, Daniel Fuchs wrote:
Hi,
Some more tests seen failing when using the wildcard address.
One of them actually needs the wildcard so for that one I simply
edited the summary to make it clear. There are more in the pipe
after those are fixed...
http://cr.openjdk.java.net/~dfuchs
On 06/05/2019 18:31, Arthur Eubanks wrote:
I added a test that set an empty SecurityManager and called
InetAddress.getLoopbackAddress(). It passed, there were no permission
issues.
Then I looked at the code around NetworkInterface.getByInetAddress(),
and I don't see anything related to security
On 02/05/2019 10:33, Andre Naujoks wrote:
:
I just wanted to notify you, that the whole issue with binding to a
multicast address is not Linux specific.
Understood as it's always been platform specific as to whether you could
bind to a multicast address. This is one of the reason why we've had a
On 02/05/2019 08:44, Andre Naujoks wrote:
Hello all.
I just noticed, that the fix from Bug JDK-8210493 was reverted for Java
12. With a new bug JDK-8215294 taking over the issue.
Yes, it caused problems so had to be reverted. In addition to
JDK-8215294 there is also JDK-8216417 which we expect
On 01/05/2019 23:53, Arthur Eubanks wrote:
Webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8223214
NetworkInterface.getByInetAddress denies knowledge of addresses that you
don't have a permission to connect to so I think this will ne
JEP 353 [1] is now a candidate and I would like to get the CSR [2]
finalized and the changes reviewed so that it can be targeted.
The webrev with the changes is here:
http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html
The new implementation is one source file; the only other co
On 30/04/2019 10:53, Michael McMahon wrote:
Thanks for all the comments. A new webrev is at:
http://cr.openjdk.java.net/~michaelm/8216978/webrev.2/index.html
The CSR now also includes the minor API doc update suggested for the
no-arg SocketImpl constructor.
This looks okay to me.
-Alan
On 29/04/2019 17:47, Michael McMahon wrote:
:
It still ends up as a close of the socket's file descriptor at the OS
level
one way or the other. Closing a socket's InputStream or OutputStream
never resulted in a shutdown() call to the OS. If you want socket
shutdown
then you need to call shutd
On 29/04/2019 13:00, Daniel Fuchs wrote:
Hi Alan,
On 29/04/2019 12:17, Alan Bateman wrote:
I don't think AbstractPlainSocketImpl.isBound needs to be volatile as
it is guarded by the synchronization on the impl (the doConnect and
bind methods are synchronized).
I see that it is set ou
On 29/04/2019 10:52, Michael McMahon wrote:
Hi,
This is another change which is part of the general cleanup of
SocketImpls.
The change removes support for pre JDK 1.4 socketimpls which do not
implement
the timed connect method. These SocketImpls have not been compilable
since 1.4 and limited
On 26/04/2019 14:33, Daniel Fuchs wrote:
Hi,
Please find below a test stabilization fix for:
8129315: java/net/Socket/LingerTest.java and
java/net/Socket/ShutdownBoth.java timeout intermittently
http://cr.openjdk.java.net/~dfuchs/webrev_8129315/webrev.00/index.html
One minor comment i
On 23/04/2019 16:54, Arthur Eubanks wrote:
I believe that `DONT_ENABLE_IPV4`is not strictly required. Maybe just
drop it? Is it an initial attempt to support an IPv6-only JDK build?
If so, then maybe we separate out that requirement.
It was in the IPv6 code right below so I just
On 16/04/2019 22:34, Arthur Eubanks wrote:
Hi,
Copied from the bug https://bugs.openjdk.java.net/browse/JDK-8222562:
Some of the networking code tries to support dual socket support.
However, it doesn't work with IPv6 only systems.
setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, 0) returns a failur
Just a quick summary on where we are on this effort.
I've submitted the JEP [1] so it can be considered for the roadmap.
There wasn't any additional feedback from the draft that I sent here in
February.
In the mean-time, the "preparatory" changes have been pushed to jdk/jdk:
JDK-8220493: Pre
On 25/03/2019 15:46, can comert wrote:
Hello everyone,
I have created a commit for fixing the JDK Bug 8173620 which is
documented here:
https://bugs.openjdk.java.net/browse/JDK-8173620
Here is content for the commit for fixing the "Should not reach here"
error in case of the call to underlyi
On 22/03/2019 11:44, Chris Hegarty wrote:
This review request is for a specification only change. It clarifies the
behaviour of the timeout accepting methods of Socket and ServerSocket,
when the given a negative timeout. A negative timeout value will result
in an IllegalArgumentException being th
On 20/03/2019 16:28, Lundell, Jared wrote:
I have a use case where I need to implement a custom SocketImpl class and I've
run into some difficulty caused by the current design of SocketImpl and the
related classes in OpenJDK. My use case is implementing a custom proxy
protocol, similar in spi
On 21/03/2019 16:06, Chris Hegarty wrote:
:
Very timely, I'm just preparing a patch to resolve 8219446: "Specify
behaviour of timeout accepting methods of Socket and ServerSocket if
timeout is negative". I will drop the tests for IAE, since you already
have it covered. You can drop the comment
There are a number of tests in niosocketimpl-branch of the sandbox that
are needed to exercise Socket in ways that aren't fully exercised by the
existing tests. I'd like to bring some of these tests into jdk/jdk in
advance of the new NIO based SocketImpl, specifically:
- AsyncShutdown: invoke
Looks okay, surprised this wasn't noticed before.
On 19/03/2019 20:43, Chris Hegarty wrote:
HandlerLoop should be run in othervm, as it sets the system-wide URL
protocol handler factory which could inadvertently affect subsequent
tests run in the same agentvm. An example of this is in the bug
de
On 17/03/2019 09:14, Chris Hegarty wrote:
This review request resolves an issue where IPv6 socket addresses, used
in socket connect, are not correctly enclosed in square brackets when
tunneling over HTTP.
http://cr.openjdk.java.net/~chegar/8220663/
This looks okay to me.
-Alan
On 16/03/2019 11:32, Chris Hegarty wrote:
*
+ * @implNote
+ * Implementations may define additional target names, but should use
naming
+ * conventions such as reverse domain name notation to avoid name
clashes.
+ *
* @see java.security.BasicPermission
* @see java.security.Permission
* @see
On 13/03/2019 12:09, Chris Hegarty wrote:
Trivially, there should be a comma after the year. Just add it.
Looks okay.
We have a branch in the sandbox named "niosocketimpl-branch" with a
replacement for the underlying implementation used by java.net.Socket
and ServerSocket. I've mentioned this in previous mails [1]. We also
have a draft JEP [2].
I'd like to get the changes that allow for the platform Socket
On 12/03/2019 09:05, Chris Hegarty wrote:
Minor typo in the link target, should be BodySubscribers ( plural ).
Looks okay.
Just another update on the effort to replace the legacy PlainSocketImpl.
The changes in the sandbox are in good shape. I spent a bit of time
comparing the behavior differences between the old and new
implementations and I haven't found anything significant so far. Sergey
Kuksenko has improved t
On 13/02/2019 01:31, Brian Burkhalter wrote:
Removing NET_Write{V,v} does not break the Unix build, at least for
Linux, macOS, and Solaris, so perhaps these can in fact be removed [1]
as suggested in the issue description.
Classic networking doesn't scatter/gather APIs so I don't know why ther
On 25/01/2019 14:08, Alan Bateman wrote:
I've created a branch in the sandbox, named "niosocketimpl-branch",
with a prototype SocketImpl implementation based on the infrastructure
in sun.nio.ch package that supports the NIO channel implementations.
The branch also includes
On 29/01/2019 10:21, Bernd Eckenfels wrote:
How will that look like on Windows, will it use IO Completion Ports? I
guess scalability becomes much more of an issue with typical thousands
of classic sockets.
What’s the expected performance of this? The blocking IO had a lot
less latency compare
I've created a branch in the sandbox, named "niosocketimpl-branch", with
a prototype SocketImpl implementation based on the infrastructure in
sun.nio.ch package that supports the NIO channel implementations. The
branch also includes the changes to java.net.Socket and ServerSocket to
use this
On 24/01/2019 13:09, Michael McMahon wrote:
I've updated the webrev at
http://cr.openjdk.java.net/~michaelm/8216986/webrev.2/
to add some tests and also I found the same dubious implementation of
getLocalPort()
in HttpConnectSocketImpl.java. The test infrastructure needed some
cleanup also.
Th
On 23/01/2019 11:44, Michael McMahon wrote:
Hi
Could I get the following webrev reviewed please?
It is just to remove dead code from SocksSocketImpl.
Most of the code was an (unused) attempt to implement
SOCKS for ServerSockets. getLocalPort() was potentially buggy
and should not override the su
On 23/01/2019 10:55, Florian Weimer wrote:
:
Sorry, what I meant is that available() says that there are bytes, and
then when you try to read them, you get an exception because they are no
longer there. I doubt that's the intent behind the
InputStream::available specification, but as I said, it
On 23/01/2019 09:42, Florian Weimer wrote:
:
Do you plan to read from the socket buffer in the implementation of
available()? The problem is that even if there is currently data in the
socket buffer, further data that arrives later can clear it. I think
this can only happen as part of a connect
On 22/01/2019 08:07, Langer, Christoph wrote:
Hi Alan,
the change looks good to me.
In src/java.base/unix/native/libnio/ch/Net.c and
src/java.base/windows/native/libnio/ch/Net.c you could change the code from
...
int n = NET_SocketAvailable(fdval(env, fdo), &count);
if (n != 0) {
...
to o
On 21/01/2019 18:00, Michael McMahon wrote:
Hi Alan,
Looks fine apart from extra space on line 85: ExtendedSocketOptions.java
Thanks, I'll fix that before pushing.
-Alan
This is a small change to add a method to sun.nio.ch.Net to get the
number of bytes in the socket input buffer. The motive for adding this
to make it possible for the socket adaptors to implement
InputStream::available and also to support an alternative SocketImpl
based on NIO. I've used the op
ExtendSocketOptions is the supporting class that the socket
implementations use for JDK-specific socket options. Vyom improved it
last year to select options based on the socket type but more is needed
to handle socket options that are specific to connecting or listening
sockets. As things stan
Looks okay to me too. I think we should encourage new multicast
applications to move to DatagramChannel as it a defines factory methods
to specify the protocol family at creation time. Also
setOption(IP_MULTICAST_IF, ...) and the join methods are also specified
for such cases. Going forward I
On 02/01/2019 10:43, Claes Redestad wrote:
:
While we're in the area then it would be nice to eliminate the use of
Class::newInstance too - if each of the built-in protocol handlers is
public with a public no-arg constructor then
getConstructor().newInstance() should do it.
To be perfectl
On 02/01/2019 09:02, Claes Redestad wrote:
Hi,
during bootstrap we load and use at least two of the jrt, file and jar
URLStreamHandlers via URL$DefaultFactory. Avoiding use of reflection to
instantiate these slightly speed up bootstrap by reducing number of
classes loaded and doing fewer relativ
On 12/12/2018 16:53, Claes Redestad wrote:
Hi,
please review this patch to use String.isEmpty when applicable:
Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8215281
Why?
- It reads better :-)
- Better startup/warmup due fewer method
On 12/12/2018 16:15, Chris Hegarty wrote:
The backout looks correct, and I agree with the approach.
-Chris.
On 12/12/2018 16:09, Pavel Rappo wrote:
Hello,
Please review the following change:
http://cr.openjdk.java.net/~prappo/8215292/webrev.00
That change backs out the fix for "Bind to
On 10/12/2018 17:54, Daniel Fuchs wrote:
Hi Alan,
Here is an updated webrev that takes into account
your later feedback:
http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.02/
This update looks good to me.
-Alan
On 07/12/2018 15:13, Daniel Fuchs wrote:
Hi,
Please find below a fix for
8215008: Clear confusion between URL/URI paths and file system paths
https://bugs.openjdk.java.net/browse/JDK-8215008
It adds a small non normative @apiNote to java.net.URL and java.net.URI.
http://cr.openjdk.java.net/~df
On 29/11/2018 20:29, Michael McMahon wrote:
:
I've updated the webrev after the last comments:
http://cr.openjdk.java.net/~michaelm/8211842/webrev.2/
It's really just refactoring. So, unless anyone has a comment I will push
the fix shortly.
Thanks for the update, this version looks good to me
401 - 500 of 1542 matches
Mail list logo
