Hi,
I've updated the fix for JDK-8230946
<https://bugs.openjdk.java.net/browse/JDK-8230946>with the feedback
received here and from the CSR (JDK-8231305
<https://bugs.openjdk.java.net/browse/JDK-8231305>). The new webrev can
be found below:
http://cr.openjdk.java.net/~pconcannon/8230946/webrevs/webrev.04/
Kind regards,
Patrick
On 30/09/2019 16:45, Chris Hegarty wrote:
On 30/09/2019 15:27, Alan Bateman wrote:
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 as an
implicit bind by connect is not observed by the SM. It will not be
wrong for the binding in connect to go through the SM too.
One could reasonably write a test that connects an unbound channel,
and expect that SM::checkListen is invoked.
My intention was to use 8231570, in part, to examine the` @throws
SecurityException` for receive. ( as well as what was mentioned above )
The related issue that we touched on here is that
DatagramChannel.receive does not specify that it discards datagrams
when denied by the SM. I think we will need to adjust the wording for
the SecurityException.
DatagramChannel::receive has the following @throws:
* @throws SecurityException
* If a security manager has been installed
* and it does not permit datagrams to be accepted
* from the datagram's sender
This is incorrect.
The specification should say that denied datagram packets will be
discarded **.
The only possible "fix" here, ignoring implicit bind since that will
be handled by 8231570, is to remove the @throws ( as well as adding
some spec verbiage, which is already implicit through the link to
DatagramSocket ). But it might be prudent to not remove @throws yet,
given 8231570 is still unresolved. 8231570 can be used to "fix" the
@throws, to either 1) remove it, or 2) modify it to say that the bind
may throw.
I don't have a strong opinion either way which JIRA issue is used for
which parts of the change, just that the changes happen without
removing and re-adding an @throws
-Chris.
** If registered with a selector for OP_READ, after waking up that
selector then discarding the datagram.
