Skip to content
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

Closed
wants to merge 7 commits into from

Conversation

pconcannon
Copy link
Contributor

@pconcannon pconcannon commented Jun 23, 2021

Hi,

Could someone please review my changes for the removal of the legacy PlainSocketImpl and PlainDatagramSocketImpl implementations?

In JDK 13, JEP 353 provided a drop in replacement for the legacy PlainSocketImpl implementation. Since JDK 13, the PlainSocketImpl implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property jdk.net.usePlainSocketImpl allowing to switch back to the old implementation.
Similarly, in JDK 15, JEP 373 provided a new implementation for DatagramSocket and MulticastSocket, with a JDK-specific property jdk.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

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation

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

@bridgekeeper
Copy link

bridgekeeper bot commented Jun 23, 2021

👋 Welcome back pconcannon! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@pconcannon
Copy link
Contributor Author

/csr needed

@openjdk openjdk bot added the rfr Pull request is ready for review label Jun 23, 2021
@openjdk
Copy link

openjdk bot commented Jun 23, 2021

@pconcannon has indicated that a compatibility and specification (CSR) request is needed for this pull request.
@pconcannon please create a CSR request for issue JDK-8253119. This pull request cannot be integrated until the CSR request is approved.

@openjdk openjdk bot added the csr Pull request needs approved CSR before integration label Jun 23, 2021
@openjdk
Copy link

openjdk bot commented Jun 23, 2021

@pconcannon The following labels will be automatically applied to this pull request:

  • net
  • nio
  • serviceability

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.

@openjdk openjdk bot added serviceability serviceability-dev@openjdk.org nio nio-dev@openjdk.org net net-dev@openjdk.org labels Jun 23, 2021
@mlbridge
Copy link

mlbridge bot commented Jun 23, 2021

Webrevs

Copy link
Contributor

@AlanBateman AlanBateman left a 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.

Copy link
Contributor

@AlanBateman AlanBateman left a 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);
Copy link
Contributor

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?

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Member

@dfuch dfuch Jun 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AlanBateman

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Member

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?

Copy link
Contributor Author

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

src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c Outdated Show resolved Hide resolved
@pconcannon
Copy link
Contributor Author

I assume DatagramSocket L1043-L1049 (declaration/init of USE_PLAINDATAGRAMSOCKET) can be removed too.

USE_PLAINDATAGRAMSOCKET removed as requested. See 49125e7

}
DatagramSocketImpl impl = factory.createDatagramSocketImpl();
Objects.requireNonNull(impl,
"Implementation returned by installed DatagramSocketFactoryImpl is null");
Copy link
Contributor

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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

@openjdk openjdk bot removed the csr Pull request needs approved CSR before integration label Jul 2, 2021
@openjdk
Copy link

openjdk bot commented Jul 2, 2021

@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:

8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation

Reviewed-by: alanb, dfuchs, chegar

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 master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jul 2, 2021
@pconcannon
Copy link
Contributor Author

/integrate

@openjdk
Copy link

openjdk bot commented Jul 6, 2021

Going to push as commit 326b2e1.
Since your change was applied there have been 3 commits pushed to the master branch:

  • f485171: 8269692: sun.net.httpserver.ServerImpl::createContext should throw IAE
  • 16aa8cb: 8269697: JNI_GetPrimitiveArrayCritical() should not accept object array
  • e47803a: 8266310: deadlock between System.loadLibrary and JNI FindClass loading another class

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Jul 6, 2021
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jul 6, 2021
@openjdk
Copy link

openjdk bot commented Jul 6, 2021

@pconcannon Pushed as commit 326b2e1.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated net net-dev@openjdk.org nio nio-dev@openjdk.org serviceability serviceability-dev@openjdk.org
4 participants