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
8302659: Modernize Windows native code for NetworkInterface #12593
Conversation
👋 Welcome back rdicroce! A progress list of the required criteria for merging this PR into |
FWIW - there is a perl script located in |
Webrevs
|
/label remove core-libs |
@AlanBateman |
Would it be possible to re-format the changes to src/java.base/windows/native/libnet/NetworkInterface.c to avoid the overly long lines - some of the new lines are 150-200 characters long so it will make impossible to look at side-by-side diffs in the future. |
Sure. What do you want the max line length to be? 80 chars? 100? |
Something between 80 and 100 is usually a good limit. We typically avoid to go above that. So no hard limit at 80 but avoid having lines which are too long. If it displays correctly without wrapping using side diff in webrev / github side diff file view on a regular (for instance, laptop) screen it's a good sign. |
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.
Build changes look fine.
/reviewers 2
@rdicroce 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 505 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@magicus, @djelinski, @AlanBateman, @Michael-Mc-Mahon) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
Maximum line length reduced to 80-ish characters. |
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.
Overall the changes look good. A few comments below.
what versions of Windows has this been tested on ? Just wondering if the deletion of the old dual stack winXP based code could have on the older windows OS platforms? some of these may be retired for LTS JDK21, but for the moment they are in the mix. Also we will have to arrange some IPv6 only test runs for this prior to any integration -- that takes a bit of time to arrange the resources to be setup and to schedule the runs. |
@msheppar I tested this on Windows 10 and 11. I don't have access to any older systems. But I tried to be careful about which APIs I used. I'm pretty sure I checked the MS docs for all of them, and they all exist since Vista/Server 2008. So this should work on all the versions you listed. |
I don't think the NetworkInterface.h file should be dropped. |
Overall I think this is a very contribution. It's good to modernize this code and remove the cruft that dates from before many of the new APIs were added. I suspect we will need a release document any behaviour changes that may be observed when upgrading the JDK. In particular, the network interface names will look different. The synthesized names were names like "lo" and "eth0" whereas the new names come from Windows (names like "lookup_0" and "ethernet_0"). I haven't found tools that show the names that ConvertInterfaceLuidToNameW returns but if there are then the RN could mention it. On other platforms, it would be was easy for configuration to name the interface to be used for multicasting, it doesn't seem easy to do the same on Windows and application might have to resort to configuration by IP address. I'm not too concerned that interfaces without IP addresses are enumerated. They aren't useful for multicasting applications but maybe they are useful for informational purposes, e.g. programs that collect system environment. I'm also not too concern about the ordering of the IP addresses. I'll defer to @djelinski on whether some JDK tests or test infra needs to be updated in advance to ensure that tests that choose interfaces will continue to work. |
Ok then, let's keep the filter interfaces as they are; we can always revisit the issue later if there's demand. |
I've updated the PR to address all of the various comments. @AlanBateman Regarding tools that return the new interface names, I'm not aware of any either. But it's not too hard to hack together a PowerShell script to call if_indextoname which does exactly what the name implies. |
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.
Network interface changes LGTM now. I'm not sure about the change to ResolverConfiguration, see below.
src/java.base/windows/native/libnet/ResolverConfigurationImpl.c
Outdated
Show resolved
Hide resolved
Thanks for that! I'll start working on a CSR and a release note. /csr needed |
@djelinski only the pull request author and Reviewers are allowed to use the |
CSR approved, release note ready. I think we're good to go. @rdicroce you can integrate the changes now. |
Thanks @djelinski! /integrate |
I think the change looks good. We might need to put some more work into examining all details of behavior changes. For example, I noticed that previously the InetAddresses for each interface are returned IPv4 first, whereas now they are returned IPv6 first (on Windows 10 at least). |
/sponsor |
Going to push as commit 35a2969.
Your commit was automatically rebased without conflicts. |
@djelinski @rdicroce Pushed as commit 35a2969. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Improves performance and correctness, as discussed on the net-dev mailing list.
Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/12593/head:pull/12593
$ git checkout pull/12593
Update a local copy of the PR:
$ git checkout pull/12593
$ git pull https://git.openjdk.org/jdk pull/12593/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 12593
View PR using the GUI difftool:
$ git pr show -t 12593
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/12593.diff