stan/jdk-24
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

8295198: Update more openjdk.java.net => openjdk.org URLs

Browse Source 
Reviewed-by: erikj
This commit is contained in:
Magnus Ihse Bursie 2022-10-12 13:34:07 +00:00
parent c357b5908a
commit 8402260535
6 changed files with 14 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
ASSEMBLY_EXCEPTION
View File

@ -2,8 +2,8 @@
OPENJDK ASSEMBLY EXCEPTION
The OpenJDK source code made available by Oracle America, Inc. (Oracle) at
openjdk.java.net ("OpenJDK Code") is distributed under the terms of the GNU
General Public License <http://www.gnu.org/copyleft/gpl.html> version 2
openjdk.org ("OpenJDK Code") is distributed under the terms of the GNU
General Public License <https://www.gnu.org/copyleft/gpl.html> version 2
only ("GPL2"), with the following clarification and special exception.
Linking this OpenJDK Code statically or dynamically with other code
@ -12,7 +12,7 @@ only ("GPL2"), with the following clarification and special exception.
As a special exception, Oracle gives you permission to link this
OpenJDK Code with certain code licensed by Oracle as indicated at
http://openjdk.java.net/legal/exception-modules-2007-05-08.html
https://openjdk.org/legal/exception-modules-2007-05-08.html
("Designated Exception Modules") to produce an executable,
regardless of the license terms of the Designated Exception Modules,
and to copy and distribute the resulting executable under GPL2,

2
CONTRIBUTING.md
View File

@ -1,3 +1,3 @@
# Contributing to the JDK
Please see <https://openjdk.java.net/contribute/> for how to contribute.
Please see <https://openjdk.org/contribute> for how to contribute.

4
doc/hotspot-unit-tests.html
View File

@ -115,7 +115,7 @@
<p>However in some cases, default information is not enough, a commonly used example is an assert inside a loop, GoogleTest will not print iteration values (unless it is an assert's parameter). Other demonstrative examples are printing error code and a corresponding error message; printing internal states which might have an impact on results. One should add this information to assert message using <code>&lt;&lt;</code> operator.</p>
<h3 id="uncluttered-output">Uncluttered output</h3>
<p>Print information only if it is needed.</p>
<p>Too verbose tests which print all information even if they pass are very bad practice. They just pollute output, so it becomes harder to find useful information. In order not print information till it is really needed, one should consider saving it to a temporary buffer and pass to an assert. <a href="https://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp" class="uri">https://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp</a> has a good example how to do that.</p>
<p>Too verbose tests which print all information even if they pass are very bad practice. They just pollute output, so it becomes harder to find useful information. In order not print information till it is really needed, one should consider saving it to a temporary buffer and pass to an assert. <a href="https://git.openjdk.org/jdk/blob/master/test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp" class="uri">https://git.openjdk.org/jdk/blob/master/test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp</a> has a good example how to do that.</p>
<h3 id="failures-propagation">Failures propagation</h3>
<p>Wrap a subroutine call into <code>EXPECT_NO_FATAL_FAILURE</code> macro to propagate failures.</p>
<p><code>ASSERT</code> and <code>FAIL</code> abort only the current function, so if you have them in a subroutine, a test will not be aborted after the subroutine even if <code>ASSERT</code> or <code>FAIL</code> fails. You should call such subroutines in <code>ASSERT_NO_FATAL_FAILURE</code> macro to propagate fatal failures and abort a test. <code>(EXPECT|ASSERT)_NO_FATAL_FAILURE</code> can also be used to provide more information.</p>
@ -171,7 +171,7 @@
<h3 id="test-specific-flags">Test-specific flags</h3>
<p>Passing flags to a tested JVM in <code>TEST_OTHER_VM</code> and <code>TEST_VM_ASSERT*</code> should be possible, but is not implemented yet.</p>
<p>Facility to pass test-specific flags is needed for system, regression or other types of tests which require a fully initialized JVM in some particular configuration, e.g. with Serial GC selected. There is no support for such tests now, however, there is a plan to add that in upcoming releases.</p>
<p>For now, if a test depends on flags values, it should have <code>if (!&lt;flag&gt;) { return }</code> guards in the very beginning and <code>@requires</code> comment similar to jtreg <code>@requires</code> directive right before test macros. <a href="https://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/gtest/gc/g1/test_g1IHOPControl.cpp" class="uri">https://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/gtest/gc/g1/test_g1IHOPControl.cpp</a> ha an example of this temporary workaround. It is important to follow that pattern as it allows us to easily find all such tests and update them as soon as there is an implementation of flag passing facility.</p>
<p>For now, if a test depends on flags values, it should have <code>if (!&lt;flag&gt;) { return }</code> guards in the very beginning and <code>@requires</code> comment similar to jtreg <code>@requires</code> directive right before test macros. <a href="https://git.openjdk.org/jdk/blob/master/test/hotspot/gtest/gc/g1/test_g1IHOPControl.cpp" class="uri">https://git.openjdk.org/jdk/blob/master/test/hotspot/gtest/gc/g1/test_g1IHOPControl.cpp</a> ha an example of this temporary workaround. It is important to follow that pattern as it allows us to easily find all such tests and update them as soon as there is an implementation of flag passing facility.</p>
<p>In long-term, we expect jtreg to support GoogleTest tests as first class citizens, that is to say, jtreg will parse <span class="citation" data-cites="requires">@requires</span> comments and filter out inapplicable tests.</p>
<h3 id="flag-restoring">Flag restoring</h3>
<p>Restore changed flags.</p>

4
doc/hotspot-unit-tests.md
View File

@ -194,7 +194,7 @@ very bad practice. They just pollute output, so it becomes harder to
find useful information. In order not print information till it is
really needed, one should consider saving it to a temporary buffer and
pass to an assert.
<https://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp>
<https://git.openjdk.org/jdk/blob/master/test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp>
has a good example how to do that.
### Failures propagation
@ -383,7 +383,7 @@ upcoming releases.
For now, if a test depends on flags values, it should have `if
(!<flag>) { return }` guards in the very beginning and `@requires`
comment similar to jtreg `@requires` directive right before test macros.
<https://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/gtest/gc/g1/test_g1IHOPControl.cpp>
<https://git.openjdk.org/jdk/blob/master/test/hotspot/gtest/gc/g1/test_g1IHOPControl.cpp>
ha an example of this temporary workaround. It is important to follow
that pattern as it allows us to easily find all such tests and update
them as soon as there is an implementation of flag passing facility.

2
make/common/ProcessMarkdown.gmk
View File

@ -57,7 +57,7 @@ define ProcessMarkdown
endif
ifneq ($$($1_CSS), )
ifneq ($$(findstring http:/, $$($1_CSS)), )
ifneq ($$(findstring https:/, $$($1_CSS)), )
$1_$2_CSS_OPTION := --css '$$($1_CSS)'
else
$1_$2_CSS := $$(strip $$(call RelativePath, $$($1_CSS), $$($1_$2_TARGET_DIR)))

11
src/java.base/share/man/java.1
View File

@ -300,7 +300,7 @@ It is an error if there is a class on the application class path whose
name is the same as that of the class to be executed.
.PP
See \f[B]JEP 330: Launch Single\-File Source\-Code Programs\f[R]
[http://openjdk.java.net/jeps/330] for complete details.
[https://openjdk.org/jeps/330] for complete details.
.SH USING THE JDK_JAVA_OPTIONS LAUNCHER ENVIRONMENT VARIABLE
.PP
\f[CB]JDK_JAVA_OPTIONS\f[R] prepends its content to the options parsed
@ -4111,11 +4111,10 @@ warning is issued when they\[aq]re used.
.TP
.B \f[CB]\-\-illegal\-access=\f[R]\f[I]parameter\f[R]
Controlled \f[I]relaxed strong encapsulation\f[R], as defined in \f[B]JEP
261\f[R]
[https://openjdk.java.net/jeps/261#Relaxed\-strong\-encapsulation].
261\f[R] [https://openjdk.org/jeps/261#Relaxed\-strong\-encapsulation].
This option was deprecated in JDK 16 by \f[B]JEP 396\f[R]
[https://openjdk.java.net/jeps/396] and made obsolete in JDK 17 by
\f[B]JEP 403\f[R] [https://openjdk.java.net/jeps/403].
[https://openjdk.org/jeps/396] and made obsolete in JDK 17 by \f[B]JEP
403\f[R] [https://openjdk.org/jeps/403].
.RS
.RE
.TP
@ -4392,7 +4391,7 @@ start the VM with the command line option:
.RE
.PP
See \f[B]CodeHeap State Analytics (OpenJDK)\f[R]
[https://bugs.openjdk.java.net/secure/attachment/75649/JVM_CodeHeap_StateAnalytics_V2.pdf]
[https://bugs.openjdk.org/secure/attachment/75649/JVM_CodeHeap_StateAnalytics_V2.pdf]
for a detailed description of the code heap state analytics feature, the
supported functions, and the granularity options.
.SH ENABLE LOGGING WITH THE JVM UNIFIED LOGGING FRAMEWORK