8294618: Update openjdk.java.net => openjdk.org

Reviewed-by: mikael, iris, joehw, prr, ihse

README.md

@@ -1,11 +1,11 @@
 # Welcome to the JDK!
 
 For build instructions please see the
-[online documentation](https://openjdk.java.net/groups/build/doc/building.html),
+[online documentation](https://openjdk.org/groups/build/doc/building.html),
 or either of these files:
 
 - [doc/building.html](doc/building.html) (html version)
 - [doc/building.md](doc/building.md) (markdown version)
 
-See <https://openjdk.java.net/> for more information about
+See <https://openjdk.org/> for more information about
 the OpenJDK Community and the JDK.

doc/building.md

@@ -7,7 +7,7 @@ the time. They assume that you have installed Git (and Cygwin if running
 on Windows) and cloned the top-level JDK repository that you want to build.
 
  1. [Get the complete source code](#getting-the-source-code): \
-    `git clone https://git.openjdk.java.net/jdk/`
+    `git clone https://git.openjdk.org/jdk/`
 
  2. [Run configure](#running-configure): \
     `bash configure`
@@ -40,14 +40,14 @@ reasonably powerful hardware.
 
 If you just want to use the JDK and not build it yourself, this document is not
 for you. See for instance [OpenJDK installation](
-http://openjdk.java.net/install) for some methods of installing a prebuilt
+http://openjdk.org/install) for some methods of installing a prebuilt
 JDK.
 
 ## Getting the Source Code
 
 Make sure you are getting the correct version. As of JDK 10, the source is no
 longer split into separate repositories so you only need to clone one single
-repository. At the [OpenJDK Git site](https://git.openjdk.java.net/) you
+repository. At the [OpenJDK Git site](https://git.openjdk.org/) you
 can see a list of all available repositories. If you want to build an older version,
 e.g. JDK 11, it is recommended that you get the `jdk11u` repo, which contains
 incremental updates, instead of the `jdk11` repo, which was frozen at JDK 11 GA.
@@ -96,7 +96,7 @@ on where and how to check out the source code.
           Cygwin paths (which are used throughout the JDK build system).
           However, it does not currently work well with the Skara CLI tooling.
           Please see the [Skara wiki on Git clients](
-          https://wiki.openjdk.java.net/display/SKARA/Skara#Skara-Git) for
+          https://wiki.openjdk.org/display/SKARA/Skara#Skara-Git) for
           up-to-date information about the Skara git client support.
 
         * The [Git for Windows](https://gitforwindows.org) client has issues
@@ -173,7 +173,7 @@ used at Oracle, where header files and external libraries from an older version
 are used when building on a more modern version of the OS.
 
 The Build Group has a wiki page with [Supported Build Platforms](
-https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms). From
+https://wiki.openjdk.org/display/Build/Supported+Build+Platforms). From
 time to time, this is updated by contributors to list successes or failures of
 building on different platforms.
 
@@ -303,7 +303,7 @@ sudo apk add build-base bash grep zip
 ### AIX
 
 Please consult the AIX section of the [Supported Build Platforms](
-https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) OpenJDK
+https://wiki.openjdk.org/display/Build/Supported+Build+Platforms) OpenJDK
 Build Wiki page for details about which versions of AIX are supported.
 
 ## Native Compiler (Toolchain) Requirements
@@ -397,7 +397,7 @@ be because of [spaces in path](#spaces-in-path).
 ### IBM XL C/C++
 
 Please consult the AIX section of the [Supported Build Platforms](
-https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) OpenJDK
+https://wiki.openjdk.org/display/Build/Supported+Build+Platforms) OpenJDK
 Build Wiki page for details about which versions of XLC are supported.
 
 
@@ -848,14 +848,14 @@ Suggestions for Advanced Users](#hints-and-suggestions-for-advanced-users) and
 
 ## Running Tests
 
-Most of the JDK tests are using the [JTReg](http://openjdk.java.net/jtreg)
+Most of the JDK tests are using the [JTReg](http://openjdk.org/jtreg)
 test framework. Make sure that your configuration knows where to find your
 installation of JTReg. If this is not picked up automatically, use the
 `--with-jtreg=<path to jtreg home>` option to point to the JTReg framework.
 Note that this option should point to the JTReg home, i.e. the top directory,
 containing `lib/jtreg.jar` etc.
 
-The [Adoption Group](https://wiki.openjdk.java.net/display/Adoption) provides
+The [Adoption Group](https://wiki.openjdk.org/display/Adoption) provides
 recent builds of jtreg [here](
 https://ci.adoptopenjdk.net/view/Dependencies/job/dependency_pipeline/lastSuccessfulBuild/artifact/jtreg/).
 Download the latest `.tar.gz` file, unpack it, and point `--with-jtreg` to the
@@ -1548,7 +1548,7 @@ You can run `fsutil file setshortname` in `cmd` on certain directories, such as
 
 If none of the suggestions in this document helps you, or if you find what you
 believe is a bug in the build system, please contact the Build Group by sending
-a mail to [build-dev@openjdk.java.net](mailto:build-dev@openjdk.java.net).
+a mail to [build-dev@openjdk.org](mailto:build-dev@openjdk.org).
 Please include the relevant parts of the configure and/or build log.
 
 If you need general help or advice about developing for the JDK, you can also
@@ -1958,7 +1958,7 @@ To analyze build performance, run with `LOG=trace` and check `$BUILD/build-trace
 Use `JOBS=1` to avoid parallelism.
 
 Please check that you adhere to the [Code Conventions for the Build System](
-http://openjdk.java.net/groups/build/doc/code-conventions.html) before
+http://openjdk.org/groups/build/doc/code-conventions.html) before
 submitting patches.
 
 ## Contributing to the JDK
@@ -1971,19 +1971,19 @@ However, please bear in mind that the JDK is a massive project, and we must ask
 you to follow our rules and guidelines to be able to accept your contribution.
 
 The official place to start is the ['How to contribute' page](
-http://openjdk.java.net/contribute/). There is also an official (but somewhat
+http://openjdk.org/contribute/). There is also an official (but somewhat
 outdated and skimpy on details) [Developer's Guide](
-http://openjdk.java.net/guide/).
+http://openjdk.org/guide/).
 
 If this seems overwhelming to you, the Adoption Group is there to help you! A
 good place to start is their ['New Contributor' page](
-https://wiki.openjdk.java.net/display/Adoption/New+Contributor), or start
+https://wiki.openjdk.org/display/Adoption/New+Contributor), or start
 reading the comprehensive [Getting Started Kit](
 https://adoptopenjdk.gitbooks.io/adoptopenjdk-getting-started-kit/en/). The
 Adoption Group will also happily answer any questions you have about
 contributing. Contact them by [mail](
-http://mail.openjdk.java.net/mailman/listinfo/adoption-discuss) or [IRC](
-http://openjdk.java.net/irc/).
+http://mail.openjdk.org/mailman/listinfo/adoption-discuss) or [IRC](
+http://openjdk.org/irc/).
 
 ## Editing this document
 

doc/hotspot-style.html

@@ -68,8 +68,8 @@ <h3 id="why-care-about-style">Why Care About Style?</h3>
 <h3 id="counterexamples-and-updates">Counterexamples and Updates</h3>
 <p>Many of the guidelines mentioned here have (sometimes widespread) counterexamples in the HotSpot code base. Finding a counterexample is not sufficient justification for new code to follow the counterexample as a precedent, since readers of your code will rightfully expect your code to follow the greater bulk of precedents documented here.</p>
 <p>Occasionally a guideline mentioned here may be just out of synch with the actual HotSpot code base. If you find that a guideline is consistently contradicted by a large number of counterexamples, please bring it up for discussion and possible change. The architectural rule, of course, is &quot;When in Rome do as the Romans&quot;. Sometimes in the suburbs of Rome the rules are a little different; these differences can be pointed out here.</p>
-<p>Proposed changes should be discussed on the <a href="mailto:hotspot-dev@openjdk.java.net">HotSpot Developers</a> mailing list. Changes are likely to be cautious and incremental, since HotSpot coders have been using these guidelines for years.</p>
-<p>Substantive changes are approved by <a href="https://www.rfc-editor.org/rfc/rfc7282.html">rough consensus</a> of the <a href="https://openjdk.java.net/census#hotspot">HotSpot Group</a> Members. The Group Lead determines whether consensus has been reached.</p>
+<p>Proposed changes should be discussed on the <a href="mailto:hotspot-dev@openjdk.org">HotSpot Developers</a> mailing list. Changes are likely to be cautious and incremental, since HotSpot coders have been using these guidelines for years.</p>
+<p>Substantive changes are approved by <a href="https://www.rfc-editor.org/rfc/rfc7282.html">rough consensus</a> of the <a href="https://openjdk.org/census#hotspot">HotSpot Group</a> Members. The Group Lead determines whether consensus has been reached.</p>
 <p>Editorial changes (changes that only affect the description of HotSpot style, not its substance) do not require the full consensus gathering process. The normal HotSpot pull request process may be used for editorial changes, with the additional requirement that the requisite reviewers are also HotSpot Group Members.</p>
 <h2 id="structure-and-formatting">Structure and Formatting</h2>
 <h3 id="factoring-and-class-design">Factoring and Class Design</h3>
@@ -238,7 +238,7 @@ <h3 id="c-standard-library">C++ Standard Library</h3>
 <p>Some reasons for this include</p>
 <ul>
 <li><p>Exceptions. Perhaps the largest core issue with adopting the use of Standard Library facilities is exceptions. HotSpot does not use exceptions and, for platforms which allow doing so, builds with them turned off. Many Standard Library facilities implicitly or explicitly use exceptions.</p></li>
-<li><p><code>assert</code>. An issue that is quickly encountered is the <code>assert</code> macro name collision (<a href="https://bugs.openjdk.java.net/browse/JDK-8007770">JDK-8007770</a>). Some mechanism for addressing this would be needed before much of the Standard Library could be used. (Not all Standard Library implementations use assert in header files, but some do.)</p></li>
+<li><p><code>assert</code>. An issue that is quickly encountered is the <code>assert</code> macro name collision (<a href="https://bugs.openjdk.org/browse/JDK-8007770">JDK-8007770</a>). Some mechanism for addressing this would be needed before much of the Standard Library could be used. (Not all Standard Library implementations use assert in header files, but some do.)</p></li>
 <li><p>Memory allocation. HotSpot requires explicit control over where allocations occur. The C++98/03 <code>std::allocator</code> class is too limited to support our usage. (Changes in more recent Standards may remove this limitation.)</p></li>
 <li><p>Implementation vagaries. Bugs, or simply different implementation choices, can lead to different behaviors among the various Standard Libraries we need to deal with.</p></li>
 <li><p>Inconsistent naming conventions. HotSpot and the C++ Standard use different naming conventions. The coexistence of those different conventions might appear jarring and reduce readability.</p></li>
@@ -272,7 +272,7 @@ <h3 id="enum">enum</h3>
 <p>Due to bugs in certain (very old) compilers, there is widespread use of enums and avoidance of in-class initialization of static integral constant members. Compilers having such bugs are no longer supported. Except where an enum is semantically appropriate, new code should use integral constants.</p>
 <h3 id="thread_local">thread_local</h3>
 <p>Avoid use of <code>thread_local</code> (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2659.htm">n2659</a>); and instead, use the HotSpot macro <code>THREAD_LOCAL</code>, for which the initializer must be a constant expression. When <code>thread_local</code> must be used, use the Hotspot macro <code>APPROVED_CPP_THREAD_LOCAL</code> to indicate that the use has been given appropriate consideration.</p>
-<p>As was discussed in the review for <a href="https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039487.html">JDK-8230877</a>, <code>thread_local</code> allows dynamic initialization and destruction semantics. However, that support requires a run-time penalty for references to non-function-local <code>thread_local</code> variables defined in a different translation unit, even if they don't need dynamic initialization. Dynamic initialization and destruction of non-local <code>thread_local</code> variables also has the same ordering problems as for ordinary non-local variables. So we avoid use of <code>thread_local</code> in general, limiting its use to only those cases where dynamic initialization or destruction are essential. See <a href="https://bugs.openjdk.java.net/browse/JDK-8282469">JDK-8282469</a> for further discussion.</p>
+<p>As was discussed in the review for <a href="https://mail.openjdk.org/pipermail/hotspot-dev/2019-September/039487.html">JDK-8230877</a>, <code>thread_local</code> allows dynamic initialization and destruction semantics. However, that support requires a run-time penalty for references to non-function-local <code>thread_local</code> variables defined in a different translation unit, even if they don't need dynamic initialization. Dynamic initialization and destruction of non-local <code>thread_local</code> variables also has the same ordering problems as for ordinary non-local variables. So we avoid use of <code>thread_local</code> in general, limiting its use to only those cases where dynamic initialization or destruction are essential. See <a href="https://bugs.openjdk.org/browse/JDK-8282469">JDK-8282469</a> for further discussion.</p>
 <h3 id="nullptr">nullptr</h3>
 <p>Prefer <code>nullptr</code> (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">n2431</a>) to <code>NULL</code>. Don't use (constexpr or literal) 0 for pointers.</p>
 <p>For historical reasons there are widespread uses of both <code>NULL</code> and of integer 0 as a pointer value.</p>

doc/hotspot-style.md

@@ -55,13 +55,13 @@ suburbs of Rome the rules are a little different; these differences
 can be pointed out here.
 
 Proposed changes should be discussed on the
-[HotSpot Developers](mailto:hotspot-dev@openjdk.java.net) mailing
+[HotSpot Developers](mailto:hotspot-dev@openjdk.org) mailing
 list.  Changes are likely to be cautious and incremental, since HotSpot
 coders have been using these guidelines for years.
 
 Substantive changes are approved by
 [rough consensus](https://www.rfc-editor.org/rfc/rfc7282.html) of
-the [HotSpot Group](https://openjdk.java.net/census#hotspot) Members.
+the [HotSpot Group](https://openjdk.org/census#hotspot) Members.
 The Group Lead determines whether consensus has been reached.
 
 Editorial changes (changes that only affect the description of HotSpot
@@ -550,7 +550,7 @@ turned off.  Many Standard Library facilities implicitly or explicitly
 use exceptions.
 
 * `assert`.  An issue that is quickly encountered is the `assert` macro name
-collision ([JDK-8007770](https://bugs.openjdk.java.net/browse/JDK-8007770)).
+collision ([JDK-8007770](https://bugs.openjdk.org/browse/JDK-8007770)).
 Some mechanism for addressing this would be needed before much of the
 Standard Library could be used.  (Not all Standard Library implementations
 use assert in header files, but some do.)
@@ -661,7 +661,7 @@ be a constant expression. When `thread_local` must be used, use the Hotspot macr
 consideration.
 
 As was discussed in the review for
-[JDK-8230877](https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039487.html),
+[JDK-8230877](https://mail.openjdk.org/pipermail/hotspot-dev/2019-September/039487.html),
 `thread_local` allows dynamic initialization and destruction
 semantics.  However, that support requires a run-time penalty for
 references to non-function-local `thread_local` variables defined in a
@@ -671,7 +671,7 @@ non-local `thread_local` variables also has the same ordering
 problems as for ordinary non-local variables. So we avoid use of
 `thread_local` in general, limiting its use to only those cases where dynamic
 initialization or destruction are essential. See
-[JDK-8282469](https://bugs.openjdk.java.net/browse/JDK-8282469)
+[JDK-8282469](https://bugs.openjdk.org/browse/JDK-8282469)
 for further discussion.
 
 ### nullptr

make/Doctor.gmk

@@ -134,7 +134,7 @@ epilogue: check-bad-file-names
 	$(ECHO) '* The build README (doc/building.md) is a great source of information,'
 	$(ECHO) 'especially the chapter "Fixing Unexpected Build Failures". Check it out!'
 	$(ECHO)
-	$(ECHO) '* If you still need assistance please contact build-dev@openjdk.java.net.'
+	$(ECHO) '* If you still need assistance please contact build-dev@openjdk.org.'
 	$(ECHO)
 
 TARGETS += epilogue

make/autoconf/configure.ac

@@ -31,7 +31,7 @@
 
 
 AC_PREREQ([2.69])
-AC_INIT(OpenJDK, openjdk, build-dev@openjdk.java.net,,http://openjdk.java.net)
+AC_INIT(OpenJDK, openjdk, build-dev@openjdk.org,,https://openjdk.org)
 
 AC_CONFIG_AUX_DIR([$TOPDIR/make/autoconf/build-aux])
 m4_include([build-aux/pkg.m4])

make/conf/branding.conf

@@ -1,5 +1,5 @@
 #
-# Copyright (c) 2011, 2020, Oracle and/or its affiliates. All rights reserved.
+# Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved.
 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 #
 # This code is free software; you can redistribute it and/or modify it
@@ -29,7 +29,7 @@ PRODUCT_SUFFIX="Runtime Environment"
 JDK_RC_PLATFORM_NAME=Platform
 COMPANY_NAME=N/A
 HOTSPOT_VM_DISTRO="OpenJDK"
-VENDOR_URL=https://openjdk.java.net/
+VENDOR_URL=https://openjdk.org/
 VENDOR_URL_BUG=https://bugreport.java.com/bugreport/
 VENDOR_URL_VM_BUG=https://bugreport.java.com/bugreport/crash.jsp
 

make/jdk/src/classes/build/tools/taglet/Incubating.java

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2017, 2022, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -56,7 +56,7 @@ public String getName() {
     }
 
     private static final String MESSAGE =
-        "<BR><b><a href=\"http://openjdk.java.net/jeps/11\">Incubating Feature.</a>"
+        "<BR><b><a href=\"https://openjdk.org/jeps/11\">Incubating Feature.</a>"
                 + " Will be removed in a future release.</b>";
 
     @Override

src/demo/share/jfc/J2Ddemo/README.txt

@@ -86,7 +86,7 @@ the methods in the CustomControlsContext interface.
 
 Here are some resources for learning about and using the Java2D(TM)
 
-OpenJDK group page: http://openjdk.java.net/groups/2d/
+OpenJDK group page: https://openjdk.org/groups/2d/
 
 Learning Java 2D: http://www.oracle.com/technetwork/articles/java/java2dpart1-137217.html
 

src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp

@@ -94,7 +94,7 @@
 // of its Requests objects.
 //
 // For additional information on string deduplication, please see JEP 192,
-// http://openjdk.java.net/jeps/192
+// https://openjdk.org/jeps/192
 
 #include "memory/allocation.hpp"
 #include "memory/allStatic.hpp"

src/java.base/share/classes/java/lang/Object.java

@@ -568,7 +568,7 @@ public final void wait(long timeoutMillis, int nanos) throws InterruptedExceptio
      * @deprecated Finalization is deprecated and subject to removal in a future
      * release. The use of finalization can lead to problems with security,
      * performance, and reliability.
-     * See <a href="https://openjdk.java.net/jeps/421">JEP 421</a> for
+     * See <a href="https://openjdk.org/jeps/421">JEP 421</a> for
      * discussion and alternatives.
      * <p>
      * Subclasses that override {@code finalize} to perform cleanup should use

src/java.base/share/classes/java/lang/SecurityManager.java

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1995, 2021, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1995, 2022, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -310,7 +310,7 @@
  * @since   1.0
  * @deprecated The Security Manager is deprecated and subject to removal in a
  *       future release. There is no replacement for the Security Manager.
- *       See <a href="https://openjdk.java.net/jeps/411">JEP 411</a> for
+ *       See <a href="https://openjdk.org/jeps/411">JEP 411</a> for
  *       discussion and alternatives.
  */
 @Deprecated(since="17", forRemoval=true)