New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation #4574
Conversation
👋 Welcome back pconcannon! A progress list of the required criteria for merging this PR into |
/csr needed |
@pconcannon has indicated that a compatibility and specification (CSR) request is needed for this pull request. |
@pconcannon The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good cleanup, just a few nits in the changes to the NioSocketImpl impl, I didn't spot any other issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume DatagramSocket L1043-L1049 (declaration/init of USE_PLAINDATAGRAMSOCKET) can be removed too.
impl = DefaultDatagramSocketImplFactory.createDatagramSocketImpl(multicast); | ||
} | ||
DatagramSocketImpl impl = factory.createDatagramSocketImpl(); | ||
Objects.requireNonNull(impl); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this Objects.requireNonNull is not needed or maybe you want to detect a buggy factory rather than in the the constructor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - the constructor would throw NPE - but there's no need to call this constructor if impl
is null here - it's better to fail early.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably a case where the spec needs say that an error (maybe an unspecified error) is thrown if the custom factory's createDatagramSocketImpl returns null. We can create a separate issue for that as it's probably existed forever.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
protected DatagramSocket(DatagramSocketImpl impl)
throws NPE if impl
is null
.
(this is covered by the blanket statement for NPE)
Do we really need to specify anything else since the global setDatagramSocketImplFactory
method has been deprecated? I mean - though we still support it at the moment, using a DatagramSocketImplFactory
is not recommended, and hopefully only old legacy code would be using that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Creating an issue to update DatagramSocketImplFactory.createDatagramSocketImpl to say that returning null leads to undefined behavior or DatagramSocket constructors throwing an error is fine, I wasn't suggesting we have to fix it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've created an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8269288
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've created an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8269288
Thanks. So are you keeping the Objects.requireNonNull here? If so then it should probably be the 2-arg version so that the message is clear that the custom DatagramSocketFactory returned null, otherwise it will look like a DS bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AlanBateman Ah - good idea - something like "implementation returned by installed DatagramSocketFactoryImpl is null"?
Maybe we could add the name of the concrete DatagramSocketFactoryImpl class too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. I've added a message to the null check now. See 36bcee3
USE_PLAINDATAGRAMSOCKET removed as requested. See 49125e7 |
} | ||
DatagramSocketImpl impl = factory.createDatagramSocketImpl(); | ||
Objects.requireNonNull(impl, | ||
"Implementation returned by installed DatagramSocketFactoryImpl is null"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you mean "DatagramSocketImplFactory" instead of "DatagramSocketFactoryImpl" here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - good catch! I've been bitten by this before too :-)
https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/net/DatagramSocketImplFactory.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well spotted. Thanks Alan. Change made in commit 686b436
@pconcannon This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the ➡️ To integrate this PR with the above commit message to the |
/integrate |
Going to push as commit 326b2e1.
Your commit was automatically rebased without conflicts. |
@pconcannon Pushed as commit 326b2e1. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Hi,
Could someone please review my changes for the removal of the legacy
PlainSocketImpl
andPlainDatagramSocketImpl
implementations?In JDK 13, JEP 353 provided a drop in replacement for the legacy
PlainSocketImpl
implementation. Since JDK 13, thePlainSocketImpl
implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific propertyjdk.net.usePlainSocketImpl
allowing to switch back to the old implementation.Similarly, in JDK 15, JEP 373 provided a new implementation for
DatagramSocket
andMulticastSocket
, with a JDK-specific propertyjdk.net.usePlainDatagramSocketImpl
also allowing the user to switch back to the old implementation in case of compatibility issue.As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
Kind regards,
Patrick
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4574/head:pull/4574
$ git checkout pull/4574
Update a local copy of the PR:
$ git checkout pull/4574
$ git pull https://git.openjdk.java.net/jdk pull/4574/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 4574
View PR using the GUI difftool:
$ git pr show -t 4574
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4574.diff