[GR-65034] Merge in tag jdk-25+23

PullRequest: labsjdk-ce/173

Author: OracleLabsAutomation

.editorconfig

@@ -1,5 +1,8 @@
 root = true
 
+[*]
+charset = utf-8
+
 [*.{cpp,hpp,c,h,java,cc,hh,m,mm,S,md,properties,gmk,m4,ac}]
 trim_trailing_whitespace = true
 

.gitattributes

@@ -1,4 +1,5 @@
 *	-text
+*	encoding=utf-8
 *.java	diff=java
 *.c	diff=cpp
 *.h	diff=cpp

doc/building.html

@@ -282,6 +282,11 @@ <h3 id="special-considerations">Special Considerations</h3>
 having slow disk access will significantly increase build times. If you
 need to use a network share for the source code, see below for
 suggestions on how to keep the build artifacts on a local disk.</p></li>
+<li><p>UTF-8 support is needed to compile the JDK. On Unix systems, this
+typically means that the <code>C.UTF-8</code> or
+<code>en_US.UTF-8</code> locale needs to be available. For Windows
+users, please see the section on <a href="#locale-requirements">Locale
+Requirements</a> below.</p></li>
 <li><p>On Windows, extra care must be taken to have a smooth building
 experience:</p>
 <ul>

doc/building.md

@@ -83,6 +83,11 @@ on where and how to check out the source code.
   for the source code, see below for suggestions on how to keep the build
   artifacts on a local disk.
 
+* UTF-8 support is needed to compile the JDK. On Unix systems, this typically
+  means that the `C.UTF-8` or `en_US.UTF-8` locale needs to be available. For
+  Windows users, please see the section on [Locale
+  Requirements](#locale-requirements) below.
+
 * On Windows, extra care must be taken to have a smooth building experience:
 
   * Make sure that all relevant paths have short names. Short names are used by

doc/hotspot-style.html

@@ -32,11 +32,12 @@ <h1 class="title">HotSpot Coding Style</h1>
 <ul>
 <li><a href="#introduction" id="toc-introduction">Introduction</a>
 <ul>
+<li><a href="#changing-this-document"
+id="toc-changing-this-document">Changing this Document</a></li>
 <li><a href="#why-care-about-style" id="toc-why-care-about-style">Why
 Care About Style?</a></li>
-<li><a href="#counterexamples-and-updates"
-id="toc-counterexamples-and-updates">Counterexamples and
-Updates</a></li>
+<li><a href="#counterexamples"
+id="toc-counterexamples">Counterexamples</a></li>
 </ul></li>
 <li><a href="#structure-and-formatting"
 id="toc-structure-and-formatting">Structure and Formatting</a>
@@ -99,6 +100,21 @@ <h2 id="introduction">Introduction</h2>
 existing HotSpot code, making it easier to read and maintain. Failure to
 follow these guidelines may lead to discussion during code reviews, if
 not outright rejection of a change.</p>
+<h3 id="changing-this-document">Changing this Document</h3>
+<p>Proposed changes should be discussed on the <a
+href="mailto:[email protected]">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>
 <h3 id="why-care-about-style">Why Care About Style?</h3>
 <p>Some programmers seem to have lexers and even C preprocessors
 installed directly behind their eyeballs. The rest of us require code
@@ -124,7 +140,7 @@ <h3 id="why-care-about-style">Why Care About Style?</h3>
 reformatting the whole thing. Also consider separating changes that make
 extensive stylistic updates from those which make functional
 changes.</p>
-<h3 id="counterexamples-and-updates">Counterexamples and Updates</h3>
+<h3 id="counterexamples">Counterexamples</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
@@ -137,20 +153,6 @@ <h3 id="counterexamples-and-updates">Counterexamples and Updates</h3>
 of course, is "When in Rome do as the Romans". 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:[email protected]">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>
 <ul>

doc/hotspot-style.md

@@ -8,6 +8,24 @@ HotSpot code, making it easier to read and maintain.  Failure to
 follow these guidelines may lead to discussion during code reviews, if
 not outright rejection of a change.
 
+### Changing this Document
+
+Proposed changes should be discussed on the
+[HotSpot Developers](mailto:[email protected]) 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.org/census#hotspot) Members.
+The Group Lead determines whether consensus has been reached.
+
+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.
+
 ### Why Care About Style?
 
 Some programmers seem to have lexers and even C preprocessors
@@ -38,7 +56,7 @@ reformatting the whole thing.  Also consider separating changes that
 make extensive stylistic updates from those which make functional
 changes.
 
-### Counterexamples and Updates
+### Counterexamples
 
 Many of the guidelines mentioned here have (sometimes widespread)
 counterexamples in the HotSpot code base. Finding a counterexample is
@@ -54,22 +72,6 @@ rule, of course, is "When in Rome do as the Romans". Sometimes in the
 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:[email protected]) 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.org/census#hotspot) Members.
-The Group Lead determines whether consensus has been reached.
-
-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.
-
 ## Structure and Formatting
 
 ### Factoring and Class Design

make/CompileInterimLangtools.gmk

@@ -95,14 +95,15 @@ define SetupInterimModule
       SRC := $(BUILDTOOLS_OUTPUTDIR)/gensrc/$1.interim \
           $$(wildcard $(SUPPORT_OUTPUTDIR)/gensrc/$1) \
           $(TOPDIR)/src/$1/share/classes, \
-      EXCLUDES := sun javax/tools/snippet-files, \
+      EXCLUDES := sun, \
       EXCLUDE_FILES := $(TOPDIR)/src/$1/share/classes/module-info.java \
           $(TOPDIR)/src/$1/share/classes/javax/tools/ToolProvider.java \
           $(TOPDIR)/src/$1/share/classes/com/sun/tools/javac/launcher/Main.java \
           $(TOPDIR)/src/$1/share/classes/com/sun/tools/javac/launcher/MemoryContext.java \
           $(TOPDIR)/src/$1/share/classes/com/sun/tools/javac/launcher/MemoryModuleFinder.java \
           $(TOPDIR)/src/$1/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java \
           Standard.java, \
+      EXCLUDE_PATTERNS := -files, \
       EXTRA_FILES := $(BUILDTOOLS_OUTPUTDIR)/gensrc/$1.interim/module-info.java \
           $($1.interim_EXTRA_FILES), \
       COPY := .gif .png .xml .css .svg .js .js.template .txt .woff .woff2 javax.tools.JavaCompilerTool, \

make/CompileJavaModules.gmk

@@ -113,6 +113,7 @@ $(eval $(call SetupJavaCompilation, $(MODULE), \
     DISABLED_WARNINGS := $(DISABLED_WARNINGS_java), \
     EXCLUDES := $(EXCLUDES), \
     EXCLUDE_FILES := $(EXCLUDE_FILES), \
+    EXCLUDE_PATTERNS := -files, \
     KEEP_ALL_TRANSLATIONS := $(KEEP_ALL_TRANSLATIONS), \
     JAVAC_FLAGS := \
         $(DOCLINT) \

make/Docs.gmk

@@ -96,14 +96,14 @@ JAVADOC_DISABLED_DOCLINT_PACKAGES := org.w3c.* javax.smartcardio
 
 # The initial set of options for javadoc
 JAVADOC_OPTIONS := -use -keywords -notimestamp \
-    -serialwarn -encoding ISO-8859-1 -docencoding UTF-8 -breakiterator \
+    -serialwarn -encoding utf-8 -docencoding utf-8 -breakiterator \
     -splitIndex --system none -javafx --expand-requires transitive \
     --override-methods=summary --syntax-highlight
 
 # The reference options must stay stable to allow for comparisons across the
 # development cycle.
 REFERENCE_OPTIONS := -XDignore.symbol.file=true -use -keywords -notimestamp \
-    -serialwarn -encoding ISO-8859-1 -breakiterator -splitIndex --system none \
+    -serialwarn -encoding utf-8 -breakiterator -splitIndex --system none \
     -html5 -javafx --expand-requires transitive
 
 # Should we add DRAFT stamps to the generated javadoc?
@@ -262,7 +262,7 @@ define create_overview_file
   $$($1_OVERVIEW): $$($1_OVERVIEW_VARDEPS_FILE)
 	$$(call LogInfo, Creating overview.html for $1)
 	$$(call MakeDir, $$(@D))
-	$$(ECHO) -n '$$($1_OVERVIEW_TEXT)' > $$@
+	$$(PRINTF) "%s" '$$($1_OVERVIEW_TEXT)' > $$@
 endef
 
 ################################################################################

make/GenerateLinkOptData.gmk

@@ -76,17 +76,20 @@ $(CLASSLIST_FILE): $(INTERIM_IMAGE_DIR)/bin/java$(EXECUTABLE_SUFFIX) $(CLASSLIST
 	$(call LogInfo, Generating $(patsubst $(OUTPUTDIR)/%, %, $(JLI_TRACE_FILE)))
 	$(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java -XX:[email protected] \
 	    $(CLASSLIST_FILE_VM_OPTS) \
+	    -Xlog:cds=off \
 	    -cp $(SUPPORT_OUTPUTDIR)/classlist.jar \
 	    build.tools.classlist.HelloClasslist $(LOG_DEBUG)
 	$(GREP) -v HelloClasslist [email protected] > [email protected]
 	$(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java -Xshare:dump \
+	    -Xlog:cds=off \
 	    -XX:[email protected] -XX:[email protected] \
 	    -Xmx128M -Xms128M $(LOG_INFO)
 	$(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java -XX:[email protected] \
 	    -XX:[email protected] -XX:[email protected] \
 	    -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true \
 	    $(CLASSLIST_FILE_VM_OPTS) \
 	    --module-path $(SUPPORT_OUTPUTDIR)/classlist.jar \
+	    -Xlog:cds=off \
 	    -cp $(SUPPORT_OUTPUTDIR)/classlist.jar \
 	    build.tools.classlist.HelloClasslist \
 	    2> $(LINK_OPT_DIR)/stderr > $(JLI_TRACE_FILE) \
@@ -100,6 +103,7 @@ $(CLASSLIST_FILE): $(INTERIM_IMAGE_DIR)/bin/java$(EXECUTABLE_SUFFIX) $(CLASSLIST
 	$(GREP) -v HelloClasslist [email protected] > [email protected]
 	$(GREP) -v @cp [email protected] > [email protected]
 	$(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java \
+	    -Xlog:cds=off \
 	    -cp $(SUPPORT_OUTPUTDIR)/classlist.jar \
 	    build.tools.classlist.SortClasslist [email protected] > $@