On Thu, 1 Feb 2024 22:19:26 GMT, Joe Darcy wrote:
>> The restricted javac warning is disabled for java.base, but could be enabled
>> by suppressing the warning in a handful of files.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Thu, 1 Feb 2024 15:54:40 GMT, Matthias Baesken wrote:
>>> @MBaesken So my fix in
>>> [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386)
>>> did not help? Maybe then it is some other system library that drags in
>>> `fcntl.h`; I assumed it w
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Add
On Fri, 2 Feb 2024 06:35:26 GMT, Sam James wrote:
>> This fixes building with GCC 14:
>> * Cherry-pick a fix from Harfbuzz upstream
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>>
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
>>
On Thu, 1 Feb 2024 22:19:26 GMT, Joe Darcy wrote:
>> The restricted javac warning is disabled for java.base, but could be enabled
>> by suppressing the warning in a handful of files.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Please review a patch to add support for Markdown syntax in documentation
> comments, as described in the associated JEP.
>
> Notable features:
>
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java`
> libra
On Tue, 30 Jan 2024 23:07:46 GMT, Jonathan Gibbons wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java
>> line 572:
>>
>>> 570: }
>>> 571:
>>> 572: case TEXT -> {
>>
>> I haven't looked at `SentenceBreaker` in det
On Thu, 1 Feb 2024 22:01:49 GMT, Jorn Vernee wrote:
> This looks good to me. It will be easier to find where we are doing
> restricted operations like this.
Right; follows the recommended approach of minimizing the scope of the
SuppressWarnings annotations too. Thanks.
-
PR Comme
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Add comment highlighting restricted method calls.
--
On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote:
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
This looks good to me. It will be easier to find where we are doing restricted
operations like this.
---
On Thu, 1 Feb 2024 01:12:52 GMT, Jonathan Gibbons wrote:
>> Please review a patch to add support for Markdown syntax in documentation
>> comments, as described in the associated JEP.
>>
>> Notable features:
>>
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jd
> Please review a patch to add support for Markdown syntax in documentation
> comments, as described in the associated JEP.
>
> Notable features:
>
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java`
> libra
On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote:
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
Marked as reviewed by erikj (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/17677#pullrequ
The restricted javac warning is disabled for java.base, but could be enabled by
suppressing the warning in a handful of files.
-
Commit messages:
- JDK-8325148: Enable restricted javac warning in java.base
Changes: https://git.openjdk.org/jdk/pull/17677/files
Webrev: https://webre
On Fri, 4 Aug 2023 16:17:04 GMT, Thomas Stuefe wrote:
> See [JDK-8288719](https://bugs.openjdk.org/browse/JDK-8288719) and subsequent
> [discussion](https://mail.openjdk.org/pipermail/build-dev/2022-May/034635.html)
> back in 2022.
>
> On Arm, we can generate either arm- or thumb-code (`-marm`
On Thu, 1 Feb 2024 12:13:08 GMT, Alan Bateman wrote:
> Can you confirm that you've run tier1-4 at least? Some of the library code
> that is changed here is not tested in the lower tiers.
I have run tier1-4 now, and it passes (bar the tests that are currently failing
in mainline). However, this
On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote:
>> After adding this additional patch I fully build fastdebug on AIX (hav to
>> admit it does not look very nice).
>>
>>
>> diff --git
>> a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>> b/src/java.desktop/sh
On Thu, 1 Feb 2024 13:53:56 GMT, Magnus Ihse Bursie wrote:
>> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
>> their encoding of choice when they see this locale, but use an arbitrarily
>> encoding, which might not properly handle all UTF-8 characters. Since in
>> pr
On Thu, 1 Feb 2024 13:53:56 GMT, Magnus Ihse Bursie wrote:
>> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
>> their encoding of choice when they see this locale, but use an arbitrarily
>> encoding, which might not properly handle all UTF-8 characters. Since in
>> pr
On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote:
>> After adding this additional patch I fully build fastdebug on AIX (hav to
>> admit it does not look very nice).
>>
>>
>> diff --git
>> a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>> b/src/java.desktop/sh
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull request now c
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Remo
On Thu, 1 Feb 2024 13:53:56 GMT, Magnus Ihse Bursie wrote:
>> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
>> their encoding of choice when they see this locale, but use an arbitrarily
>> encoding, which might not properly handle all UTF-8 characters. Since in
>> pr
On 2/1/24 04:47, Julian Waters wrote:
Hi all,
Quick question: Which JDK in the build directory is the one that is
officially shipped by Oracle? Is it the one in "jdk" that is directly
in the build directory, or the one in "images/jdk"?
The one in images/jdk is the one we base the distribution
On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains seven
>> additio
On Tue, 5 Dec 2023 10:35:05 GMT, Magnus Ihse Bursie wrote:
> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
> their encoding of choice when they see this locale, but use an arbitrarily
> encoding, which might not properly handle all UTF-8 characters. Since in
> practi
> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
> their encoding of choice when they see this locale, but use an arbitrarily
> encoding, which might not properly handle all UTF-8 characters. Since in
> practice, all our encoding is utf8, we should tell our tools this a
The vote for Christoph Langer [1] is now closed.
Yes: 5
Veto: 0
Abstain: 0
According to the Bylaws definition of Lazy Consensus voting, this is sufficient
to approve the nomination.
[1] https://mail.openjdk.org/pipermail/build-dev/2024-January/042845.html
Best regards, Matthias
>I hereby no
On Mon, 29 Jan 2024 11:44:34 GMT, Magnus Ihse Bursie wrote:
> In the same spirit as
> [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt
> the AIX-specific code in hotspot so it uses the well-defined posix ``
> functions, instead of `64`. By setting the define _LARGE_F
Hi all,
Quick question: Which JDK in the build directory is the one that is
officially shipped by Oracle? Is it the one in "jdk" that is directly
in the build directory, or the one in "images/jdk"?
best regards,
Julian
On Thu, 1 Feb 2024 09:04:47 GMT, Magnus Ihse Bursie wrote:
> I added a compile-time check that hotspot on AIX is indeed compiled with
> _LARGE_FILES.
>
> @MBaesken Are you happy with this PR now?
Thanks for adding this, I approved the PR .
-
PR Comment: https://git.openjdk.org/jd
On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request with a
On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains seven
>> additio
On Tue, 30 Jan 2024 12:25:47 GMT, Magnus Ihse Bursie wrote:
>> In the same spirit as
>> [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt
>> the AIX-specific code in hotspot so it uses the well-defined posix ``
>> functions, instead of `64`. By setting the define _LAR
On Tue, 30 Jan 2024 12:25:47 GMT, Magnus Ihse Bursie wrote:
>> In the same spirit as
>> [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt
>> the AIX-specific code in hotspot so it uses the well-defined posix ``
>> functions, instead of `64`. By setting the define _LAR
> In the same spirit as
> [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt
> the AIX-specific code in hotspot so it uses the well-defined posix ``
> functions, instead of `64`. By setting the define _LARGE_FILES, this
> will make `` behave as `64`, just as _FILE_OFFSE
On Tue, 30 Jan 2024 10:34:40 GMT, Aleksey Shipilev wrote:
> See the description in the bug. This mitigates the issue by splitting out the
> only test job that has two test suites in it.
This pull request has now been integrated.
Changeset: 1aba78f2
Author:Aleksey Shipilev
URL:
http
40 matches
Mail list logo
