On 24/09/2019 16:01, Patrick Concannon wrote:
Hi,
Would it be possible to have both my fix JDK-8230946, and CSR
JDK-8231305, reviewed?
This fix and CSR addresses the javadocs for DatagramSocket::receive,
DatagramChannel::connect and DatagramChannel::receive and aims at
clarifying the Secur
On 24/09/2019 16:32, Milan Mimica wrote:
:
I looked into it and found this:
The difference is how Java_sun_nio_ch_Net_poll is implemented. On unix
it uses poll(2), on Windows it uses select(2). Regarding timeouts,
poll() has "wait at least"[2] semantics and overruns by design, while
select() on
On 24/09/2019 23:47, mark.reinh...@oracle.com wrote:
Using network proxies with Java applications is still, after all these
years, painful on Linux.
Is there a reason not to change the default value of the system property
`java.net.useSystemProxies` [1] to `true`?
This is a problematic area, I t
On 26/09/2019 14:26, Patrick Concannon wrote:
Hi Chris,
Thanks for your reply.
I've added the test case to
test/jdk/java/net/DatagramSocket/DatagramTimeout.java as requested.
You can find the new webrev here:
http://cr.openjdk.java.net/~pconcannon/8222829/webrevs/webrev.01/
We should proba
On 26/09/2019 15:16, Daniel Fuchs wrote:
Hi,
Please find below a patch for:
https://bugs.openjdk.java.net/browse/JDK-8231506
8231506: Fix some instabilities in a few networking tests
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8231506/webrev.00/
In SocketImplCombinations, the update
On 27/09/2019 16:07, Patrick Concannon wrote:
Hi Alan,
Thanks for the review.
On 24/09/2019 16:25, Alan Bateman wrote:
The clarification to DatagramSocket.receive on how it behaves when
there is a security manager and not connected may require some
adjusting to DatagramChannel&#
On 27/09/2019 16:00, Patrick Concannon wrote:
Hi Alan,
I've added a similar check for DatagramChannel socket adaptor as
requested. You can find it in the webrev below.
http://cr.openjdk.java.net/~pconcannon/8219446/webrevs/webrev.01/
Thanks, look good (just a minor nit that you've lost a
On 30/09/2019 15:10, Patrick Concannon wrote:
Hi Alan,
A new issue has been created as requested, and can be found here:
https://bugs.openjdk.java.net/browse/JDK-8231570
In JDK-8231570, I think Chris is concerned that a custom SM will
observe, and may prevent, send/receive from binding where
On 30/09/2019 21:55, mark sheppard wrote:
Hi Daniel,
looks like an interesting saga … will give that twirl on my dinky
laptop
wrt why MulticastSocket sets SO_REUSEADDR I reckon Chris or Alan
are the authority on that.
There may be several applications that need to bind to the same po
On 02/10/2019 11:16, Patrick Concannon wrote:
Hi Daniel,
Well spotted. I've fixed that now, and updated the webrev.
Looks good.
On 04/10/2019 14:34, Daniel Fuchs wrote:
:
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8231260/webrev.00/
The apiNote looks okay. DatagramChannelImpl::disconnect looks okay but I
assume "might not preserve" should be "does not preserve" (if you make
that change then the "This is the exp
On 04/10/2019 16:25, Florian Weimer wrote:
:
@@ -873,10 +873,15 @@
synchronized (stateLock) {
ensureOpen();
if (state == ST_CONNECTED)
throw new AlreadyConnectedException();
+// ensure t
On 04/10/2019 17:03, Florian Weimer wrote:
:
The kernel will do it atomically during connect, so there is no race
condition. With the change above, the port is selected and opened,
packets can arrive (from arbitrary addresses), and only then the socket
is bound to the remote address.
I don't se
On 07/10/2019 12:34, Daniel Fuchs wrote:
Hi Alan,
Here is the new webrev - I believe I have addressed all your comments:
http://cr.openjdk.java.net/~dfuchs/webrev_8231260/webrev.01
Thanks for the update, this version looks good to me.
-Alan.
On 08/10/2019 15:20, mark sheppard wrote:
:
Q: is localAddress.getPort() == 0 indicative that the DatagramChannel is
unbound ?
getLocalAddress() returns a SocketAddress when bound, it returns null
when not bound. I don't think we should get too hung up on corner case
that arises when the
On 16/10/2019 19:20, Patrick Concannon wrote:
:
webrev: http://cr.openjdk.java.net/~pconcannon/8231570/webrevs/webrev.02/
Looks good.
On 04/11/2019 15:09, Daniel Fuchs wrote:
:
It looks like Cache#remove can be fixed simply by using an explicit
iterator and using iterator#remove instead of List#remove.
Yes - we could have used an Iterator. I don't like much LinkedList.
We could have used ArrayList and an explicit Iterator i
On 08/11/2019 15:07, Chris Hegarty wrote:
This is a review request for the following bug fixes in the SCTP area. The
changes for each fix are quite small, but affect similar files and tests, so I
have built a webrev containing all four MQ patches together.
8232097: (sctp) SctpNet.init() result
On 13/11/2019 16:12, Patrick Concannon wrote:
Hi,
Could someone please review my fix for issue JDK-8233860
'java/net/SocketOption/AfterClose.java test incorrectly handles
IP_MULTICAST_IF' ?
The test, AfterClose.java, makes a call to setOption() after a socket
has been closed to verify t
On 13/11/2019 17:41, Patrick Concannon wrote:
Hi Alan,
Thanks for your feedback.
My mistake. I've changed that now in the webrev below.
http://cr.openjdk.java.net/~pconcannon/8233860/webrevs/webrev.01/
Looks good.
On 14/11/2019 11:58, Patrick Concannon wrote:
Hi,
Could someone please review my fix for issue JDK-8234103
'DatagramSocketImpl::socket is not needed' ?
DatagramSocketImpl has a socket field that links back to the
DatagramSocket, which is only used to determine whether this
DatagramSocket su
On 14/11/2019 17:00, Daniel Fuchs wrote:
Hi,
Please find below a fix (and CSR) for:
8233141 DatagramSocket.send doesn't specify exception thrown when
no target address
https://bugs.openjdk.java.net/browse/JDK-8233141
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8233141/webrev.00/
On 15/11/2019 13:13, Patrick Concannon wrote:
Hi,
Could someone please review my fix for issue JDK-8234083
'DatagramSocket should report SO_BROADCAST as a supported option'?
DatagramSocket has setBroadcast/getBroadcast methods, but omits
SO_BROADCAST as a supported option. This fix adds
On 21/11/2019 07:38, Baesken, Matthias wrote:
Thanks !
May I have a second review ?
Looks good.
-Alan
On 21/11/2019 10:16, Baesken, Matthias wrote:
Should I remove the others too (would open another jira-issue for
this, or are there concerns ) ?
As far as I checked, the other findings are all unreferenced /
unused these days .
If they are definitely unused then go ahead but you might n
On 21/11/2019 14:34, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8233296: MulticastSocket getOption/setOption inverts the value
of IP_MULTICAST_LOOP
https://bugs.openjdk.java.net/browse/JDK-8233296
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8233296/webrev.00/
I think I
On 22/11/2019 13:29, Baesken, Matthias wrote:
Hello,
The linktime section-gc ( see also
https://mail.openjdk.java.net/pipermail/build-dev/2019-November/026326.html
)
found a couple of other potentially unused functions / variables in
libnet .
This change removes the found functio
Daniel's summary is useful but changing URLClassPath doesn't feel right.
Are you in a hurry to find a solution to this? Just asking as I think
I'd prefer to see other options explored that fixed it in the protocol
handler instead.
-Alan
On 25/11/2019 13:31, Rob McKenna wrote:
Thanks Danie
On 22/11/2019 16:35, Chris Hegarty wrote:
:
QuickAckTest only creates one DatagramSocket and one MulticastSocket, so
just consumes two UDP socket resources. Prior tests run in the same VM
must be consuming the majority of UDP socket resources ( and not
releasing them), then this test just happens
On 02/12/2019 15:36, Daniel Fuchs wrote:
Hi,
Please find below a doc-only fix that specifies, for each
socket type in the java.net package, the minimal set of option
that that type supports.
The doc changes have been largely imported from corresponding
types in java.nio.channels.
8235141: Spe
On 03/12/2019 09:59, Michael McMahon wrote:
:
8234823: java/net/Socket/Timeouts.java testcase testTimedConnect2()
fails on Windows 10
http://cr.openjdk.java.net/~michaelm/8234823/webrev.1/
For this one, it should be okay to increase the timeout to a much larger
timeout if you want. For exampl
On 03/12/2019 16:39, Daniel Fuchs wrote:
It's true that there might be some overlap. This test is more about
proving consistency between the doc and the different implementations
provided by the JDK. It's too easy for something to fall through the
gaps otherwise.
The javadoc update looks good.
On 05/12/2019 15:50, Patrick Concannon wrote:
Hi,
Could some please review my fix for issue JDK-8233191 'MulticastSocket
joinGroup/leaveGroup do not specify their behavior when the outgoing
interface has not been set'?
This javadoc fix clarifies the behaviour of 2-arg joinGroup/leaveGroup
On 05/12/2019 16:01, Daniel Fuchs wrote:
This looks good to me Patrick.
With this fix multicast socket options can be set on DatagramSocket,
except on windows when the DualStackPlainDatagramSocketImpl is used.
DualStackPlainDatagramSocketImpl.java:
246 if (isReusePortAvailable())
247
On 05/12/2019 15:14, Julia Boes wrote:
Hi,
I wonder however if the links to the deprecated setInterface method
should remain in the two args joinGroup/leaveGroup, since the
behavior is still in effect should you call that method.
Agreed, I updated the webrev and specdiff accordingly.
http
On 05/12/2019 17:17, Patrick Concannon wrote:
Hi,
Thanks for the feedback. I've made those changes now, and you can find
them in the new webrev below.
http://cr.openjdk.java.net/~pconcannon/8233191/webrevs/webrev.01/
I should have been clearer, my comment wasn't about replacing
null with {@c
On 06/12/2019 10:01, Patrick Concannon wrote:
Hi Alan,
Ah OK. I didn't spot that in your original email. Yeah that seems like
more concise way to put it.
I've made that change now, and updated the previous webrev.
http://cr.openjdk.java.net/~pconcannon/8233191/webrevs/webrev.01/
Yes, I thi
On 06/12/2019 15:34, Aleks Efimov wrote:
:
I've created webrev with your latest changes - it could be convenient
for other reviewers:
http://cr.openjdk.java.net/~aefimov/anuraaga/7006496/00
I will happily sponsor this change once it gets necessary approvals
This could be split into two issues
On 09/12/2019 18:03, Michael McMahon wrote:
Hi,
Could I get the following webrev reviewed please? The deprecation
arises from
the general deprecation of the Solaris port and the fact this is a
Solaris only feature.
http://cr.openjdk.java.net/~michaelm/8234871/webrev.1/
Looks okay to me.
-A
On 15/12/2019 16:52, Simone Bordet wrote:
Hi,
the Jetty integration with HttpServerProvider is failing a couple of
tests in JDK 14 (they pass in earlier JDKs).
This is due to the fact that com.sun.net.httpserver.BasicAuthenticator
has been changed to report the charset in the WWW-Authenticate h
On 17/12/2019 14:35, Patrick Concannon wrote:
Hi,
Could someone please review my fix and CSR for issue JDK-8235783
'DatagramSocket::disconnect should allow an implementation to throw
UncheckedIOException'?
DatagramChannel's connect and disconnect methods throw an IOException
while DatagramS
On 18/12/2019 10:55, Daniel Fuchs wrote:
We already have two implementations of DatagramSocket: one is the plain
DatagramSocket, the other is the DatagramSocket adapter created by
DatagramChannel::socket.
Even without preparing for DatagramSocket reimplementation this
is a step forward in homoge
DatagramSocket and MulticastSocket delegate to a DatagramSocketImpl, a
provider-like mechanism that dates from early JDK releases. I'm
wondering if anyone is aware of any implementations and whether they are
still maintained. The context for asking is whether anyone would notice
if the JDK d
On 18/12/2019 16:47, Chris Hegarty wrote:
:
Specifically on this point, the two-arg variants of `joinGroup` and
`leaveGroup` throw an UnsupportedOperationException if invoked on a
MulticastSocket that has a DatagramSocketImpl which was compiled against
a pre-1.4 version of the DSI interface. ( th
On 20/12/2019 17:53, Chris Hegarty wrote:
The MulticastSocket implementation on Windows uses the two stacks
implementation. The two stacks implementation creates a socket on the
IPv4 stack and another on the IPv6 stack. Operations are then performed
on both sockets as appropriate. If the socket i
On 20/12/2019 22:34, Chris Hegarty wrote:
Thanks Alan,
1) I updated the file descriptor check from ` > 0` to ` >= 0`
2) Removed the pre-existing incorrect comment, and
3) Added a few more test scenarios that check the index = 0 cases
Updated webrev:
https://cr.openjdk.java.net/~chegar/8236441/
This is a patch to "upgrade" the DatagramChannel socket adaptor to
extend MulticastSocket. This is one of the final changes needed to
DatagramChannel and its socket adaptor buddy to make it easy to replace
the legacy DatagramSocket and MulticastSocket implementation. Daniel has
a draft JEP [1]
On 10/01/2020 15:26, Patrick Concannon wrote:
Hi Alan,
Thanks for the feedback.
I've incorporated your comments into the webrev below.
http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.01/
Thanks, this version looks good to me.
-Alan
On 10/01/2020 16:29, Patrick Concannon wrote:
Hi Chris,
Well spotted.
I've made those changes and updated the webrev.
http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.02/
"channel's socket" -> "socket". Well spotted!
Something for another (and not important) issue is that
Da
On 14/01/2020 11:49, Patrick Concannon wrote:
Hi,
Could someone please review my fix for JDK-8237075 '@since tag missing
from DatagramSocket and MulticastSocket methods' ?
This trivial fix adds in the missing @since tags for methods listed
below. These methods were originally added in JDK 1.
On 14/01/2020 17:49, Daniel Fuchs wrote:
Hi Alan,
Globally this looks good to me. One small nit is that the `oldImpl`
field could now also become final (by applying the same trick you
did with createImpl - that is - have oldImpl() return a boolean
rather than set the field and assign the result
On 16/01/2020 11:45, Chris Hegarty wrote:
:
Generally, I agree with updating the socket adapter to support
multicast. It will certainly help with future work in this area.
The instanceof checks in the constructors highlight that there is an
abstraction missing here - to support creating a custom
On 24/01/2020 08:36, Denghui Dong wrote:
Hi team,
Could I have a review of a small change that converts TIMEOUT
of ResolverConfigurationImpl into property.
Summary:
The value of TIMEOUT of ResolverConfigurationImpl was hardcoded, it's
useful to use a system property to specify
the value of it
On 24/01/2020 09:22, Denghui Dong wrote:
Hi Alan,
In our production environment, the content of /etc/resolv.conf may be
modified because of some reason, and we found that JVM can't know it when it
running.
There are some ways to fix this problem, one way is Adding -Dsun.net.spi.nameservice.
On 24/01/2020 09:53, Denghui Dong wrote:
yes, you are right.
In that case,
src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java is
probably the code that should be reading the property and then creating
the ResolverConfiguration with this timeout. Reading the property there
will
On 24/01/2020 11:14, Patrick Concannon wrote:
Hi,
Could someone please review my fix and CSR for issue JDK-7021373
'DatagramPacket exception conditions are not clear' ?
This fix updates the spec concerning the exceptions thrown by the
constructors of the DatagramPacket class, and several met
On 24/01/2020 11:49, Daniel Fuchs wrote:
If I'm not mistaken, one side effect here is that this allows
the DatagramSocketAdaptor to throw IllegalArgumentException when
it is not connected and passed a DatagramPacket in which the port
as not been set.
Yes, that's the outlier I mentioned in the re
On 24/01/2020 15:16, Chris Hegarty wrote:
:
Can we please have a class-level specification of whatthe
valid port range is; 0 <= port <= 0x? This should be
verifiable .
I agree this would be useful to have and it could be linked to from the
various places that mention the range.
-Alan
On 27/01/2020 19:14, Daniel Fuchs wrote:
Hi,
Please find below a doc-only fix for:
8237896: MulticastSocket should link to DatagramChannel as
an alternative for multicasting.
https://bugs.openjdk.java.net/browse/JDK-8237896
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8237896/we
On 28/01/2020 11:22, Daniel Fuchs wrote:
I'm not sure I understand why obtaining a MulticastChannel from
a DatagramSocket is important. Maybe the wording needs to be
clarified?
If someone has a MulticastSocket then they can't get to a
DatagramChannel to use the alternative join method that is r
On 27/01/2020 17:27, Patrick Concannon wrote:
I’ve taken the @throws IAE from DatagramPacket::getSocketAddress, and
logged it as a separate issue as it seems further work is needed in
deciding how to move forward with it. See
https://bugs.openjdk.java.net/browse/JDK-8237890
Thanks for sep
On 29/01/2020 16:18, Daniel Fuchs wrote:
Hi Alan.
Alright. I've transformed the second note in an @see:
http://cr.openjdk.java.net/~dfuchs/webrev_8237896/webrev.02/
This looks okay to me.
-Alan
On 31/01/2020 16:46, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8238231: Custom DatagramSocketImpl's create method not called when
with protected constructor
https://bugs.openjdk.java.net/browse/JDK-8238231
This is a behavioral regression introduced by JDK-8236925 [1].
Thank
On 31/01/2020 17:30, Daniel Fuchs wrote:
:
doh! trying to be too smart. I don't think we need the volatile given
that getImpl() synchronizes and we (now) can ever observe true if
create() has been called. Unless you're concerned about getImpl()
being called before the constructor has set creat
On 31/01/2020 19:42, Daniel Fuchs wrote:
I think I disagree but I agree it's non obvious so I will switch
the boolean to volatile.
http://cr.openjdk.java.net/~dfuchs/webrev_8238231/webrev.02
Good, this version is correct. I see that getImpl() is synchronizing on
"this". I guess that is okay but
On 31/01/2020 21:42, Daniel Fuchs wrote:
Yes. Well I syncronized on `this` because other methods such as
`bind` or `connectInternal` already synchronize on `this`.
If the impl has not been created it's more likely that it will
be by one of these.
Okay.
Just to summarize on this issue: A Datagr
On 13/02/2020 16:53, Chris Hegarty wrote:
:
Did you intentionally use heap byte buffers, or should the test use direct
buffers?
That is a good discussion point as there is a matrix of heap vs. direct,
blocking vs. non-blocking, scatter/gather, ... that could be added to
create more comprehens
On 28/02/2020 22:06, Bernd Eckenfels wrote:
What is the MAC address of the loopback interface on Solaris anyway?
Maybe it's enough to assume there is none if the execution fails?
I'm also curious if there are any platforms or configurations where the
loopback has a hardware address. Mostly won
On 09/03/2020 12:39, Patrick Concannon wrote:
Hi,
Could someone please review my fix for JDK-8239355 '(dc) Initial value
of SO_SNDBUF should allow sending large datagrams (macOS)' ?
By default, macOS imposes a size of 9216on Datagrams which limits
applications that don't set the SO_SNDBUF
On 09/03/2020 18:08, Daniel Fuchs wrote:
Hi Alan,
On 09/03/2020 17:01, Alan Bateman wrote:
On 09/03/2020 12:39, Patrick Concannon wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8239355
webrev:
http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.00/index.html
This is a
On 10/03/2020 18:32, Patrick Concannon wrote:
Hi Alan and Daniel,
Thanks for the feedback.
I've changed the test to be DatagramChannel specific, and it now
checks getOption(SO_SNDBUF) for both IPv4 and IPv6. You can find the
updated webrev below.
http://cr.openjdk.java.net/~pconcannon/8239
Vyom,
Are you planning to create a native test for this? I realize the fix you
are discussing here isn't too interesting for >= JDK 13 but I think it
could be useful to ensure that we have a test that signals threads in
all of the blocking operations (connect might be tricky butt at least
rea
On 11/03/2020 08:09, Vyom Tewari26 wrote:
Hi Alan,
Thanks for comment yes for >=JDK13 we are using new socket impl which
does not have this problem, i am not planning to wright a test, to
test this issue we need to get the native thread ID then we have to
interrupt the thread to see if JDK c
On 11/03/2020 10:58, Daniel Fuchs wrote:
:
testSend sends to the loopback address but I think we need this test
to send datagrams on the network (sending to the loopback is okay too
but I think you want this test to send a datagram on the network
because we want fragmentation on the network(.
On 11/03/2020 16:54, Patrick Concannon wrote:
Hi,
I've included those additional changes, and they can be found in the
new webrev below.
http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.03/
Thanks for the update, looks good. I assume the updates to the IPSupport
infra isn't need
On 16/03/2020 04:25, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
Bug: https://bugs.openjdk.java.net/browse/JDK-8241039
CSR: https://bugs.openjdk.java.net/browse/JDK-8241047
webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/
I see you've created a new issue (and
On 16/03/2020 16:00, Xuelei Fan wrote:
Hi Alan,
Thanks for the review. All comments look good to me. Here is the
update webrev:
http://cr.openjdk.java.net/~xuelei/8241039/webrev.01/
HandshakeCompletedEvent.java and SSLSession.java are updated.
Thanks. One suggestion is to use "The def
On 17/03/2020 05:21, Vyom Tiwari wrote:
Hi Daniel/Michael,
Please find the latest
webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.2/index.html),
where i put a test case as well.
Can you look at make/test/JtregNativeJdk.gmk? That should give you ideas
on how to develop tests th
Looks okay and matches the sigs in the generated header files.
-Alan
On 17/03/2020 08:52, Vipin Mv1 wrote:
A gentle reminder to please review this patch.
Thanks & Regards
Vipin MV
On 20/03/2020 07:19, Ivan Gerasimov wrote:
Hello!
An OOM error is intermittently observed on MacOS when joining a
multicast group.
A workaround was implemented as part of the fix for JDK-8236925.
It is proposed to backport a portion of that fix, which helps to
mitigate the issue on MacOS.
On 20/03/2020 12:22, Daniel Fuchs wrote:
Hi Ivan,
Looks good to me. I wonder if you should add
@bug 8044365
to the MulticastSendReceiveTests.java while you're at it.
Every test that joins a multicast has the potential of hitting this,
it's very random, so probably not useful to put it on this s
The approach seems okay until the test infrastructure is fixed to ignore
the problematic interfaces. Would you mind listing the DatagramChannel
tests with the other DatagramChannel tests that are already excluded so
they aren't in random order.
-Alan
On 23/03/2020 13:22, Daniel Fuchs wrote:
On 23/03/2020 16:37, Patrick Concannon wrote:
This is a request for review for the implementation changes for JEP
373: 'Reimplement Legacy DatagramSocket API' [1]. A CSR has also been
created [2].
The implementation of JEP 373 can be viewed on the JDK-8230211-branch
in the sandbox [3].
A li
On 26/03/2020 15:36, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8241336: Some java.net tests failed with NoRouteToHostException on
MacOS with special network configuration
https://bugs.openjdk.java.net/browse/JDK-8241336
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_82413
On 26/03/2020 20:35, Daniel Fuchs wrote:
Hi Alan.
On 26/03/2020 17:29, Alan Bateman wrote:
NetworkConfiguration.isTestable - is the hardcoded check for "awdl"
needed? I don't think I've seen it with non-link local address so I
can't tell if it is needed. I'm
On 27/03/2020 09:30, Daniel Fuchs wrote:
Hi Alan,
On 27/03/2020 09:06, Alan Bateman wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.02/
This mostly looks good except that I'd prefer if the the code in
assertNotSame be moved into testSendNoReceive (it was an oversig
On 29/03/2020 05:44, Ivan Gerasimov wrote:
Hello!
The fix follows up on JDK-8241727 [1].
This is a javadoc/comments only fix in the net and nio areas.
The changes are to remove redundant empty lines, correct indentation,
or otherwise restore harmony.
Would you please help review this rather
On 28/03/2020 06:43, Jaikiran Pai wrote:
There's an issue raised in Quarkus repo[1], where Apache Kafka
(embedded) no longer starts on Java 14. From what I can see the root
cause is this[2].
JDK-8225499[3] changed the implementation (and even the javadoc) of
the InetSocketAddress.toString()
On 31/03/2020 11:15, Patrick Concannon wrote:
Hi,
Could someone please review my fix for JDK-8240533 'Inconsistent
Exceptions are thrown by DatagramSocket and DatagramChannel when
sending a DatagramPacket to port 0.' ?
Currently, DatagramSocket throws an IOException when sending to port
0,
On 30/03/2020 19:27, Patrick Concannon wrote:
Hi Alan,
Thanks for your feedback.
I've incorporated your comments into the revised webrev below.
http://cr.openjdk.java.net/~pconcannon/8241072/webrevs/webrev.01/
With regards to the UnreferencedXXX tests, I can take a look at these
separate
On 31/03/2020 18:27, Chris Hegarty wrote:
:
- In DatagramSocket::createDelegate, "enable broadcast if possible” - Possibly
due to refactoring, but I cannot reconcile this with the old implementation.
DatagramSocket is specified to make a best attempt to enable this option
so I think it's in
On 01/04/2020 16:04, Chris Hegarty wrote:
:
Updated webrev:
https://cr.openjdk.java.net/~chegar/8241988/webrev.01/
Looks good although I can't immediately see why options is package private
I assume the tests runs in /othervm because of the
setDatagramSocketImplFactory.
-Alan
On 01/04/2020 18:42, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8241786: 3 DatagramChannel tests and 2 MulticastSocket tests
fail due to "SocketException: No buffer space available"
https://bugs.openjdk.java.net/browse/JDK-8241786
webrev:
http://cr.openjdk.java.net/~dfuch
On 02/04/2020 09:48, Daniel Fuchs wrote:
:
DefaultInterface might be better in a test infra class (in java/net)
to avoid duplicate it in several tests.
I have considered that. The problem is that it requires the test that
uses it to add @modules java.base/java.net:+open directive in the te
On 03/04/2020 12:04, Daniel Fuchs wrote:
Hi Alan,
Hopefully that's fixed now. Only change is in AdaptorMulticasting.java
http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.03
Thanks, looks good.
-Alan
On 08/04/2020 14:07, Daniel Fuchs wrote:
Hi Pavel,
On 08/04/2020 13:56, David Holmes wrote:
and `@exception` tags for checked exceptions that were neither thrown
nor imported
Hopefully that's only on internal classes.
From a quick scan, the changes are to internal classes and a few
non-publi
On 10/04/2020 11:16, Patrick Concannon wrote:
Hi,
Could someone please review my webrev and CSR for JDK-8237890
'DatagramPacket::getSocketAddress doesn't specify what happens if
address or port are not set' ?
DatagramPacket::getSocketAddress is misleading in that it can throw an
IllegalA
On 10/04/2020 22:53, mark sheppard wrote:
Hi Patrick,
if I understand the change correctly, you wish to eliminate the
IllegalArgumentException and return an InetSocketAddress
based on the current set values for address and port.
Yes, it is surprising to have it throw an undocumented IAE as
On 09/04/2020 12:26, Patrick Concannon wrote:
Hi,
Alan - I've gone through your comments and refactored the code
accordingly.
Just a few minor comments on the implementation changes.
DatagramSocket.java
- this version of the webrev has a block comment "A global switch ..."
that looks like
On 14/04/2020 10:20, Daniel Fuchs wrote:
That's where I disagree because it's a slight difference in behavior
between the old implementation and the new - so I believe it's worth
having a test for it (even if does test the presence of a bug in the
old impl). I like this test because it does s
501 - 600 of 1542 matches
Mail list logo
