Hi Philippe,
There is an ongoing effort about "Panamization" (that is, adapting it to
use FFM instead of JNI) of native code in the JDK in general. This is
discussed on the core-libs-dev mailing list. I've cc:ed them. I think it
would be beneficial if you coordinate your efforts with the Panam
On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie wrote:
> After we converted the source base to be fully UTF-8, we do not need to use
> unicode sequences (like \u0123) in string literals. Sometimes, that might
> still make sense, as for control characters, non-breaking space, etc
nt text in a language that needs
> non-ASCII parts of Unicode, this is not so. Instead, having the sequences
> makes the text just harder to read and edit. We have already removed several
> such sequences before, but some remains.
Magnus Ihse Bursie has updated the pull request incrementally w
On Mon, 9 Jun 2025 13:41:10 GMT, Magnus Ihse Bursie wrote:
>> After we converted the source base to be fully UTF-8, we do not need to use
>> unicode sequences (like \u0123) in string literals. Sometimes, that might
>> still make sense, as for control characters, non-breaki
On Tue, 27 May 2025 17:01:13 GMT, Naoto Sato wrote:
>> After we converted the source base to be fully UTF-8, we do not need to use
>> unicode sequences (like \u0123) in string literals. Sometimes, that might
>> still make sense, as for control characters, non-breaking space, etc. But
>> for st
nt text in a language that needs
> non-ASCII parts of Unicode, this is not so. Instead, having the sequences
> makes the text just harder to read and edit. We have already removed several
> such sequences before, but some remains.
Magnus Ihse Bursie has updated the pull request incrementally
On Tue, 27 May 2025 16:31:47 GMT, Justin Lu wrote:
>> @justin-curtis-lu Are these files handled by the translation team?
>
> @magicus The ones under java.xml and jdk.jdi are updated by the translation
> team, I think it'd be best to remove those files from this change.
I have now reverted the c
nt text in a language that needs
> non-ASCII parts of Unicode, this is not so. Instead, having the sequences
> makes the text just harder to read and edit. We have already removed several
> such sequences before, but some remains.
Magnus Ihse Bursie has updated the pull request with a new
On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie wrote:
> After we converted the source base to be fully UTF-8, we do not need to use
> unicode sequences (like \u0123) in string literals. Sometimes, that might
> still make sense, as for control characters, non-breaking space, etc
On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie wrote:
> After we converted the source base to be fully UTF-8, we do not need to use
> unicode sequences (like \u0123) in string literals. Sometimes, that might
> still make sense, as for control characters, non-breaking space, etc
On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag
> so no diff
On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag
> so no diff
After we converted the source base to be fully UTF-8, we do not need to use
unicode sequences (like \u0123) in string literals. Sometimes, that might still
make sense, as for control characters, non-breaking space, etc. But for strings
that is supposed to be a coherent text in a language that ne
On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote:
> A handful of html and xml files in the JDK source tree claims to have
> encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>
> While perhaps technically correct, this is misleading, and goes contra
On Tue, 13 May 2025 00:10:50 GMT, Sergey Bylokhov wrote:
>> A handful of html and xml files in the JDK source tree claims to have
>> encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>>
>> While perhaps technically correct, this is misleading, and goes contrary to
>> the
A handful of html and xml files in the JDK source tree claims to have encodings
like `ISO-8859-1`, when they are in fact pure US-ASCII files.
While perhaps technically correct, this is misleading, and goes contrary to the
efforts of turning the source code into UTF-8 proper.
I chose between mar
On Mon, 28 Apr 2025 09:15:28 GMT, Igor Veresov wrote:
>> Improve warm-up time by making profile data from a previous run of an
>> application instantly available, when the HotSpot Java Virtual Machine
>> starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483)
>> to store me
On Wed, 9 Apr 2025 21:26:15 GMT, Justin Lu wrote:
>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties
>> line 22:
>>
>>> 20: # Peter Smolik
>>> 21: Cp1250 WINDOWS-1250 0x00FF
>>> 22: # Patch attributed to hava...@underdusken.no (H�vard Wigtil)
>>
>> Th
On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote:
>> JDK .properties files still use ISO-8859-1 encoding with escape sequences.
>> It would improve readability to see the native characters instead of escape
>> sequences (especially for the L10n process). The majority of files changed
>> are l
On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag
> so no diff
On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag
> so no diff
On Thu, 10 Apr 2025 07:31:37 GMT, Magnus Ihse Bursie wrote:
>> Right, that `å` looks to have been incorrectly converted during the
>> ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion
>> as this change is from some time ago.)
>>
&g
On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote:
>> JDK .properties files still use ISO-8859-1 encoding with escape sequences.
>> It would improve readability to see the native characters instead of escape
>> sequences (especially for the L10n process). The majority of files changed
>> are l
On Thu, 10 Apr 2025 08:08:02 GMT, Eirik Bjørsnøs wrote:
>> If anything, I might be a bit worried that there are more incorrect
>> conversions stemming from this PR, that my automated tools and manual
>> scanning has not revealed.
>
> Some observations:
>
> 1: This PR seems to have been abondo
On Thu, 11 May 2023 20:21:57 GMT, Justin Lu wrote:
>> This PR converts Unicode sequences to UTF-8 native in .properties file.
>> (Excluding the Unicode space and tab sequence). The conversion was done
>> using native2ascii.
>>
>> In addition, the build logic is adjusted to support reading in t
On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag
> so no diff
On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag
> so no diff
On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag
> so no diff
On Mon, 17 Mar 2025 06:41:31 GMT, David Holmes wrote:
>> @magicus why can't we just use `-pthread` everywhere? My recollection is
>> that `-pthread` both sets compiler directives needed for pthread programming
>> and links to libpthread, so it seems to be what we should be using. ??
>
>> Anothe
On Mon, 17 Mar 2025 10:44:30 GMT, snake66 wrote:
>>> Another follow-up is if it would hurt to include $LIBPTHREAD for _all_
>>> Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything
>>> coming to mind directly that would make that infeasible, or is it just a
>>> matter of te
On Fri, 14 Mar 2025 10:06:32 GMT, Matthias Baesken wrote:
> We switched off unused-variable warnings for the file VMManagementImpl.c,
> this should be avoided.
> This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) ,
Build changes look good to me.
-
Marked as
On Thu, 13 Mar 2025 11:39:14 GMT, snake66 wrote:
>> Allows for future support for platforms that require different flags for
>> libiconv support.
>>
>> Sponsored-by: The FreeBSD Foundation
>
> snake66 has updated the pull request incrementally with one additional commit
> since the last revisi
On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken wrote:
>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that
>> are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit sin
On Tue, 11 Mar 2025 09:07:40 GMT, Matthias Baesken wrote:
>> My motivation was that the comment brings not much value because it just
>> states the obvious. But if you like I can bring back the comment.
>
> I brought back the comment, maybe it is better to keep it because of
> consistency.
Tha
On Wed, 12 Mar 2025 13:57:43 GMT, snake66 wrote:
>> Allows for future support for platforms that require different flags for
>> libiconv support.
>>
>> Sponsored-by: The FreeBSD Foundation
>
> snake66 has updated the pull request incrementally with one additional commit
> since the last revisi
On Tue, 11 Mar 2025 19:45:58 GMT, snake66 wrote:
> We could just do:
>
> ```
> CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) \
> $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS) $(LIBZ_CFLAGS) \
> $(ICONV_CFLAGS), \
> ```
>
> The reason I kept it separate for now is that it used
On Wed, 12 Mar 2025 12:12:37 GMT, Magnus Ihse Bursie wrote:
> Another way to phrase this is perhaps: "why don't we need iconv on linux?"
I googled this and can answer it myself: because `iconv()` is built into glibc.
So then I guess it makes sense to add ICONV variables globa
On Wed, 12 Mar 2025 11:15:02 GMT, Matthias Baesken wrote:
>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that
>> are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit sin
On Tue, 11 Mar 2025 13:18:55 GMT, Kevin Walls wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> do not handle the unused variables stuff in this change
>
> make/modules/java.management/Lib.gmk line 35:
>
>> 33:
On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes wrote:
>>> What is the intended way of using this? Do you run make with
>>> LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the
>>> specific way of linking to pthread?
>>
>> This is in preparation of the upcoming BSD port, which use
On Sat, 8 Mar 2025 13:39:44 GMT, snake66 wrote:
>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that
>> it's possible to parameterize this for platforms that use different flags
>> for enabling posix threads.
>>
>> This work is a continuation of the work done by Greg Lew
On Thu, 6 Mar 2025 13:27:15 GMT, snake66 wrote:
>> Abstracting this out seems reasonable to me, though I should say I thought
>> we already used `-pthread` rather than `-lpthread`.
>>
>> Needs build team approval before integrating.
>
>> Abstracting this out seems reasonable to me, though I sho
On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou wrote:
> Please review the test fix that removes `libVThreadEventTest` explicit
> dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in
> `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With
> the chang
On Mon, 3 Mar 2025 17:36:00 GMT, Jiangli Zhou wrote:
>> Please review the test fix that removes `libVThreadEventTest` explicit
>> dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in
>> `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With
>> the ch
On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes wrote:
>>> What is the intended way of using this? Do you run make with
>>> LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the
>>> specific way of linking to pthread?
>>
>> This is in preparation of the upcoming BSD port, which use
On Thu, 6 Mar 2025 17:28:10 GMT, snake66 wrote:
>> make/autoconf/libraries.m4 line 142:
>>
>>> 140: # Threading library
>>> 141: if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS"
>>> = xaix; then
>>> 142: BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
>>
>> If you sp
On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro wrote:
>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that
>> it's possible to parameterize this for platforms that use different flags
>> for enabling posix threads.
>>
>> This work is a continuation of the work done by G
On Thu, 6 Mar 2025 10:39:27 GMT, snake66 wrote:
> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's
> possible to parameterize this for platforms that use different flags for
> enabling posix threads.
>
> This work is a continuation of the work done by Greg Lewis in
On Thu, 6 Mar 2025 14:21:08 GMT, Erik Joelsson wrote:
> What is the intended way of using this? Do you run make with
> LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific
> way of linking to pthread?
This is in preparation of the upcoming BSD port, which uses `-pthread
On Wed, 26 Feb 2025 13:24:57 GMT, Matthias Baesken wrote:
>> I think it might be worth trying to take a more structured approach to the
>> optimizations used. Maybe setup a wiki page with all native libraries, what
>> current optimization levels they use, and what the difference in size would
On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag
> so no diff
On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag
> so no diff
On Wed, 29 Jan 2025 16:03:38 GMT, Nizar Benalla wrote:
> Two groups of broken links appeared in the latest JDK docs, broken links to
> man pages and broken ietf links.
>
> - The windows tools markdown files were not being converted to HTML because
> they were placed under `windows/man` rather
On Tue, 17 Dec 2024 11:10:01 GMT, Magnus Ihse Bursie wrote:
> To be able to properly support static builds on Windows in
> [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use
> `DllMain`, for two reasons:
>
> 1) This is not called for statically linked lib
protocol-specific
> helper DLLs being unloaded. As a result, the WSACleanup function should not
> be called from the DllMain function in a application DLL. This can
> potentially cause deadlocks. "
Magnus Ihse Bursie has updated the pull request incrementally with one
additiona
On Tue, 17 Dec 2024 11:10:01 GMT, Magnus Ihse Bursie wrote:
> To be able to properly support static builds on Windows in
> [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use
> `DllMain`, for two reasons:
>
> 1) This is not called for statically linked lib
On Tue, 17 Dec 2024 11:10:01 GMT, Magnus Ihse Bursie wrote:
> To be able to properly support static builds on Windows in
> [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use
> `DllMain`, for two reasons:
>
> 1) This is not called for statically linked lib
ption.
>
> This is a huge and autogenerated, but content-wise trivial, PR, and I know
> such are hard to review. I recommend looking at the entire diff file instead
> of checking this file-by-file in the Github web GUI. (That's bound to be a
> painful experience)
Magnus Ihse Bursie h
To be able to properly support static builds on Windows in
[JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use
`DllMain`, for two reasons:
1) This is not called for statically linked libraries, and
2) There are multiple `DllMain` definitions throughout the JDK native
libra
On Tue, 17 Dec 2024 11:10:01 GMT, Magnus Ihse Bursie wrote:
> To be able to properly support static builds on Windows in
> [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use
> `DllMain`, for two reasons:
>
> 1) This is not called for statically linked lib
On Mon, 9 Dec 2024 12:30:19 GMT, Magnus Ihse Bursie wrote:
> Some files have been modified in 2024, but the copyright year has not been
> properly updated. This should be fixed.
>
> I have located these modified files using:
>
> git log --since="Jan 1" --name-onl
On Tue, 10 Dec 2024 09:31:21 GMT, Prasanta Sadhukhan
wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert changes to binary files
>
> not sure why client label is added,
On Mon, 9 Dec 2024 12:47:29 GMT, Magnus Ihse Bursie wrote:
> Some files have been modified in 2024, but the copyright year has not been
> properly updated. This should be fixed.
>
> I have located these modified files using:
>
> git log --since="Jan 1" --name-onl
On Mon, 9 Dec 2024 12:11:11 GMT, Magnus Ihse Bursie wrote:
> Some files have been modified in 2024, but the copyright year has not been
> properly updated. This should be fixed.
>
> I have located these modified files using:
>
> git log --since="Jan 1" --name-onl
On Mon, 9 Dec 2024 21:09:41 GMT, Magnus Ihse Bursie wrote:
>> Some files have been modified in 2024, but the copyright year has not been
>> properly updated. This should be fixed.
>>
>> I have located these modified files using:
>>
>> git log --since
; and then run a script to update the copyright year to 2024 on these files.
>
> I have made a manual sampling of files in the list to verify that they have
> indeed been modified in 2024.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last
On Mon, 9 Dec 2024 15:16:10 GMT, Roger Riggs wrote:
> That git query isn't correct for all the files in the repo. In particular,
> the copyrights on third party files are NOT updated uniformly when new
> versions are applied. In particular, XML files are NOT updated.
I'm not sure I understand
On Mon, 9 Dec 2024 15:26:00 GMT, Kevin Walls wrote:
> I also meant to note that there are updates to binaries,
> src/java.base/share/classes/jdk/internal/icu/impl/data/icudt76b/... which
> maybe isn't intentional, or I just don't understand?
That was certainly not intentional! I'm not sure how
; and then run a script to update the copyright year to 2024 on these files.
>
> I have made a manual sampling of files in the list to verify that they have
> indeed been modified in 2024.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the la
; and then run a script to update the copyright year to 2024 on these files.
>
> I have made a manual sampling of files in the list to verify that they have
> indeed been modified in 2024.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since
Some files have been modified in 2024, but the copyright year has not been
properly updated. This should be fixed.
I have located these modified files using:
git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
and then run a script to update the copyright year to 2024 on
; and then run a script to update the copyright year to 2024 on these files.
>
> I have made a manual sampling of files in the list to verify that they have
> indeed been modified in 2024.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit sinc
On Mon, 9 Dec 2024 12:41:45 GMT, Magnus Ihse Bursie wrote:
>> Some files have been modified in 2024, but the copyright year has not been
>> properly updated. This should be fixed.
>>
>> I have located these modified files using:
>>
>> git log --since
Some files have been modified in 2024, but the copyright year has not been
properly updated. This should be fixed.
I have located these modified files using:
git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
and then run a script to update the copyright year to 2024 on
Some files have been modified in 2024, but the copyright year has not been
properly updated. This should be fixed.
I have located these modified files using:
git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
and then run a script to update the copyright year to 2024 on
On Tue, 19 Nov 2024 16:27:54 GMT, Eirik Bjørsnøs wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> It's somewhat nicer to use \\s instead of space character in regex
>
> Is
On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote:
> Currently, the man pages are stored as troff (a text format) in the open
> repo, and a content-wise identical copy is stored as markdown (another text
> format) in the closed repo.
>
> Since markdown is preferred to
On Fri, 15 Nov 2024 04:49:51 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 107 commits:
>>
>> - Merge branch 'master' into JDK-8305895-v4
>> - Merge tag 'jdk-25+23' into JDK-8305895-v4
On Fri, 15 Nov 2024 16:38:20 GMT, Ioi Lam wrote:
>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://openjdk.org/jeps/483).
>>
>>
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https
On Fri, 15 Nov 2024 15:00:39 GMT, Christian Stein wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix regexes in CheckManPageOptions
>
> test/langtools/jdk/javadoc/tool/Che
On Fri, 15 Nov 2024 01:25:43 GMT, David Holmes wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Fix CheckManPageOptions test
>> - Remove classpath exception
>
>> >
> any of the reviewers knows about the process) whenever an Oracle engineer
> updates a man page. If a community contributor changes the behavior of a
> tool, an Oracle engineer needs to change the documentation for them, since
> they cannot do it themselves.
Magnus Ihse Bursie
On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote:
>> Currently, the man pages are stored as troff (a text format) in the open
>> repo, and a content-wise identical copy is stored as markdown (another text
>> format) in the closed repo.
>>
>> Since mar
> any of the reviewers knows about the process) whenever an Oracle engineer
> updates a man page. If a community contributor changes the behavior of a
> tool, an Oracle engineer needs to change the documentation for them, since
> they cannot do it themselves.
Magnus Ihse Bursie
On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> previ
On Thu, 14 Nov 2024 15:23:35 GMT, Jonathan Gibbons wrote:
> The policy has long been to use Classpath Exception in the src and make
> directories, but not in the test directories. If you're changing the policy,
> you might want to check and update any documentation where the policy might
> be
On Thu, 14 Nov 2024 12:29:38 GMT, Christian Stein wrote:
> Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail
> (bad).
*sigh*
> A candidate for an ignore list as fixing it is out of scope of this PR?
Let me have a look at it first. It seems the test has the indention t
In several (most? all?) of the build system files, the copyright header
includes the classpath exception. This makes no sense, and should be removed.
I have removed the classpath exception from makefiles, autoconf, shell scripts,
properties files, configuration files, IDE support files, build t
On Wed, 13 Nov 2024 21:55:53 GMT, Iris Clark wrote:
>> src/java.base/share/man/java.md line 9:
>>
>>> 7: # published by the Free Software Foundation. Oracle designates this
>>> 8: # particular file as subject to the "Classpath" exception as provided
>>> 9: # by Oracle in the LICENSE file that a
> any of the reviewers knows about the process) whenever an Oracle engineer
> updates a man page. If a community contributor changes the behavior of a
> tool, an Oracle engineer needs to change the documentation for them, since
> they cannot do it themselves.
Magnus Ihse Bursie
Currently, the man pages are stored as troff (a text format) in the open repo,
and a content-wise identical copy is stored as markdown (another text format)
in the closed repo.
Since markdown is preferred to troff in terms of editing, we make changes to
the man pages in markdown and then conver
On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie wrote:
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit
On Wed, 6 Nov 2024 21:24:14 GMT, Kim Barrett wrote:
>> @kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You
>> are not as explicit here as the other places you commented that it is okay
>> to do as a follow-up, but I'll assume that was what you meant. If not, let
>> me
val in JDK
>> 21](https://openjdk.org/jeps/449) with the express intent to remove it in a
>> future release.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Inline buildJniFunctionName
-
Changes:
- all: ht
val in JDK
>> 21](https://openjdk.org/jeps/449) with the express intent to remove it in a
>> future release.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 37 commits:
- Merge branch 'master' into
On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cde
On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cde
On Tue, 5 Nov 2024 08:58:00 GMT, Kim Barrett wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix: jvm_md.h was included, but not jvm.h...
>
> src/hotspot/os/windows/os_win
On Tue, 5 Nov 2024 16:28:04 GMT, Kim Barrett wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix: jvm_md.h was included, but not jvm.h...
>
> src/hotspot/os/windows/os_win
val in JDK
>> 21](https://openjdk.org/jeps/449) with the express intent to remove it in a
>> future release.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Remove FIXME
-
Changes:
- all: https://git.open
1 - 100 of 330 matches
Mail list logo
