RFR: 8342807: Update links in java.base to use https:// [v5]

[Roger Riggs]

On Tue, 21 Jan 2025 13:56:30 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http.
>> 
>> Links in `java.security` and `share/data/tzdata` are excluded from this PR.
>> 
>> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. 
>> 
>> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`).
>> 
>> Changes beyond the obvious  are as follows:
>> 
>> `linux/native/libsimdsort/xss-common-qsort.h`:
>> The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170
>> 
>> `share/man/keytool.1`:
>> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well?
>> 
>> `unix/classes/sun/net/PortConfig.java`
>> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports.
>> 
>> `unix/native/libjava/*`,
>>  Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs
>> 
>> `unix/native/libjava/ProcessImpl_md.c`
>> A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to.
>
> Eirik Bjørsnøs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright headers for 2025 for Oracle files

The current implementation reaps exit status of subprocesses using wait() in a dedicated OS thread. 
>From time to time, we conjecture that using a signal handler to capture the exit status might be preferred.
However, with Hotspot handling signals and other native code might also want to handle signals, there is less risk using the current mechanism to get the exit status.
So for the purposes of reaping status, setting the handler to SIG_DFL to ignore the signals is fine as is.
I agree doing (in this PR) anything more than fix the link is out of scope.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2605194543