On Mon, 5 Feb 2024 20:11:43 GMT, Mandy Chung wrote:
> Trivial fix. Call `PrintWriter::format` with null `Locale` to format with no
> localization.
>
> This PR also fixes JDK-8325262 to print `FindException` message without the
> stack trace to indicate clearer that the given module path is i
On Mon, 5 Feb 2024 20:11:43 GMT, Mandy Chung wrote:
> Trivial fix. Call `PrintWriter::format` with null `Locale` to format with no
> localization.
>
> This PR also fixes JDK-8325262 to print `FindException` message without the
> stack trace to indicate clearer that the given module path is i
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using `#impo
On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett wrote:
> I thought we didn't, because we were instead supposed to use INTPTR_FORMAT and
the (currently?) equivalent PTR_FORMAT. Those macros aren't legacy, they are
to provide consistent output across platforms. "%p" provides implementation
defined out
On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote:
> This update drops the "ea" from the version string.
>
> We also propagate the following fixes from the markdown sources to the troff
> manpage file:
>
> JDK-8322478: Update java manpage for multi-file source-code launcher
> JDK-8302233: HS
On Mon, 5 Feb 2024 21:58:23 GMT, Joe Darcy wrote:
>> This update drops the "ea" from the version string.
>>
>> We also propagate the following fixes from the markdown sources to the troff
>> manpage file:
>>
>> JDK-8322478: Update java manpage for multi-file source-code launcher
>> JDK-8302233
On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote:
> This update drops the "ea" from the version string.
>
> We also propagate the following fixes from the markdown sources to the troff
> manpage file:
>
> JDK-8322478: Update java manpage for multi-file source-code launcher
> JDK-8302233: HS
On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote:
> This update drops the "ea" from the version string.
>
> We also propagate the following fixes from the markdown sources to the troff
> manpage file:
>
> JDK-8322478: Update java manpage for multi-file source-code launcher
> JDK-8302233: HS
On Fri, 2 Feb 2024 20:09:57 GMT, Srinivas Vamsi Parasa wrote:
>> Hi Vamsi (@vamsi-parasa), Laurent(@bourgesl),
>>
>> The latest benchmarking compares compares the following versions:
>> jdk - direct call of Arrays.sort();
>> a15 - the current source of DualPivotQuicksort from the latest build (e
On Sun, 14 Jan 2024 15:32:12 GMT, Archie Cobbs wrote:
> Please consider this fix to ensure that going from `MessageFormat` to pattern
> string via `toPattern()` and then back via `new MessageFormat()` results in a
> format that is equivalent to the original.
>
> The quoting and escaping rules
On Wed, 18 Oct 2023 06:12:29 GMT, Xiaohong Gong wrote:
> Currently the vector floating-point math APIs like
> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
> which causes large performance gap on AArch64. Note that those APIs are
> optimized by C2 compiler on X86 p
On Wed, 31 Jan 2024 01:17:07 GMT, Brian Burkhalter wrote:
> Align the specification of `Unsafe.allocateMemory` with its implementation
> and with the specification of `Unsafe.reallocateMemory`.
This pull request has now been integrated.
Changeset: 209d87a8
Author:Brian Burkhalter
URL:
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
> which adds MessageFormat pattern support for the following subformats:
> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
> intended to provide pattern support for the more recently added JDK F
Trivial fix. Call `PrintWriter::format` with null `Locale` to format with no
localization.
This PR also fixes JDK-8325262 to print `FindException` message without the
stack trace to indicate clearer that the given module path is incorrect.
-
Commit messages:
- update copyright h
On Mon, 5 Feb 2024 16:19:59 GMT, Magnus Ihse Bursie wrote:
> Is there anything in this proposed PR that you gentlemen disagree with or
> object to? Or is this fine to push as a step in our ongoing pursuit of
> increasing the code quality, that can (and will) be followed by many more?
Yes. As
On Mon, 5 Feb 2024 17:23:54 GMT, Paul Sandoz wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> removed CodeBuilder::newObject methods
>
> src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 507:
>
>
On Mon, 5 Feb 2024 18:31:44 GMT, Adam Sotona wrote:
>> `java.lang.classfile.CodeBuilder` contains more than 230 API methods.
>> Existing ClassFile API use cases proved the concept one big CodeBuilder is
>> comfortable. However there are some redundancies, glitches in the naming
>> conventions,
On Mon, 8 Jan 2024 11:38:54 GMT, Adam Sotona wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains one commit:
>>
>> 8319463: ClassSignature should have superclass and superinterfaces as
>> ClassTypeSig
>
> The p
> `java.lang.classfile.CodeBuilder` contains more than 230 API methods.
> Existing ClassFile API use cases proved the concept one big CodeBuilder is
> comfortable. However there are some redundancies, glitches in the naming
> conventions, some frequently used methods are hard to find and some met
> `GZIPInputStream`, when looking for a concatenated stream, relies on what the
> underlying `InputStream` says is how many bytes are `available()`. But this
> is inappropriate because `InputStream.available()` is just an estimate and is
> allowed (for example) to always return zero.
>
> The fi
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using `#impo
On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy wrote:
> In its initial form, the changes are tested on Linux. Later on, I'll do
> cross-platform builds to make sure there aren't any, say, windows-specific
> changes that are needed as well.
>
> I can file a follow-up umbrella bug with the original
On Mon, 5 Feb 2024 16:38:59 GMT, Roger Riggs wrote:
>> Good catch. Your solution might be correct but I think `!contains(e)` is
>> redundant since that is how intern starts out.
>>
>>
>>static T intern(ReferencedKeyMap> setMap, T key,
>> UnaryOperator interner) {
>> T value = exi
On Mon, 5 Feb 2024 12:34:02 GMT, Jim Laskey wrote:
>> src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 151:
>>
>>> 149: @Override
>>> 150: public boolean add(T e) {
>>> 151: return intern(e) == null;
>>
>> This line is wrong, as `intern(…)` will never ret
On Fri, 5 Jan 2024 15:17:13 GMT, Adam Sotona wrote:
> `java.lang.classfile.CodeBuilder` contains more than 230 API methods.
> Existing ClassFile API use cases proved the concept one big CodeBuilder is
> comfortable. However there are some redundancies, glitches in the naming
> conventions, some
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using `#impo
On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of
> `StringUTF16::equals`. At the time I did some performance verification
> focused on x86 showing that simplifying and only using `StringLatin1::equals`
> was either neu
On Fri, 2 Feb 2024 13:54:46 GMT, Claes Redestad wrote:
> This patch streamlines and specializes various `String::indexOf` methods.
> Mainly avoids the need for clamping and doing checks that are redundant in
> almost all cases, moving the checks to the API boundary where they are
> needed.
>
On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of
> `StringUTF16::equals`. At the time I did some performance verification
> focused on x86 showing that simplifying and only using `StringLatin1::equals`
> was either neu
On Sat, 3 Feb 2024 14:36:14 GMT, Claes Redestad wrote:
>> This patch streamlines and specializes various `String::indexOf` methods.
>> Mainly avoids the need for clamping and doing checks that are redundant in
>> almost all cases, moving the checks to the API boundary where they are
>> needed.
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using `#impo
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using `#impo
On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken wrote:
> On some Windows machines we see sometimes OOM errors because of high resource
> (memory/swap) consumption. This is especially seen when the jtreg runs have
> higher concurrency. A solution is to put the java/lang/StringBuilder tests in
On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett wrote:
>>> I consider the "format '%p' expects argument of type 'void*" warnings to be
>>> not at all helpful. Fortunately we don't use '%p' in HotSpot,
>>
>> We do use it in hotspot. Not a huge amount as we have the legacy format
>> specifiers for
On Mon, 5 Feb 2024 06:15:08 GMT, David Holmes wrote:
> > I consider the "format '%p' expects argument of type 'void*" warnings to be
> > not at all helpful. Fortunately we don't use '%p' in HotSpot,
>
> We do use it in hotspot. Not a huge amount as we have the legacy format
> specifiers for PT
> On Feb 5, 2024, at 4:31 AM, Magnus Ihse Bursie wrote:
>
> On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett wrote:
>
>>> Inspired by (the later backed-out)
>>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>>> enable `-Wpedantic` for clang. This has already found some
On Sat, 3 Feb 2024 14:36:14 GMT, Claes Redestad wrote:
>> This patch streamlines and specializes various `String::indexOf` methods.
>> Mainly avoids the need for clamping and doing checks that are redundant in
>> almost all cases, moving the checks to the API boundary where they are
>> needed.
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using `#import` ins
On Mon, 5 Feb 2024 14:03:45 GMT, Magnus Ihse Bursie wrote:
> I hope finally the AIX part of this PR is done.
Thanks for the AIX related effort ; I put it again into our internal build/test
queue.
-
PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927105669
> 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:
Rede
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 Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using `#impo
On Mon, 5 Feb 2024 12:31:37 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 228 commits:
>>
>> - Merge branch 'master' into data-descriptor
>> - Update comment of expect64BitDataDescrip
On Mon, 5 Feb 2024 13:14:39 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data des
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using `#impo
On Mon, 5 Feb 2024 12:15:50 GMT, Magnus Ihse Bursie wrote:
> > Shouldn't this be -pedantic -Wpedantic, and wouldn't this be better
> > positioned at where HotSpot currently sets -permissive- for Microsoft
> > Visual C++ (In other words, TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK)?
> > The 2
On Mon, 5 Feb 2024 12:38:03 GMT, Magnus Ihse Bursie wrote:
> It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have
> not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef
> _ALLBSD_SOURCE`, which I presume is not defined on AIX.
>
> I recommend that
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 Sat, 3 Feb 2024 07:20:14 GMT, ExE Boss wrote:
>> Jim Laskey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 17 commits:
>>
>> - Merge branch 'master' into 8310913
>> - Update implNote for intern
>> - Merge branch 'master' in
On Fri, 26 Jan 2024 14:32:58 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Fri, 26 Jan 2024 14:32:58 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Mon, 5 Feb 2024 12:17:33 GMT, Joachim Kern wrote:
> Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on
> AIX to 32-Bit. _LARGE_FILES really does not help in this case!
Thanks for confirming. I think we do not want to fallback on AIX, so the <*>64
variant needs to
On Mon, 5 Feb 2024 10:49:07 GMT, Julian Waters wrote:
> The other concern I had was that there are a ton of disabled warnings added
> by this change, but I guess that's already been answered by that other reply
Just to be clear: these warnings have never been turned on. They are implicitly
tur
On Mon, 5 Feb 2024 12:07:45 GMT, Matthias Baesken wrote:
> Current commit compiles nicely on AIX. One issue we might still have
> statvfs/statvfs64 is not mentioned here in the table of functions/structs
> redefined on AIX
> https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-th
On Mon, 5 Feb 2024 10:49:07 GMT, Julian Waters wrote:
> Shouldn't this be -pedantic -Wpedantic, and wouldn't this be better
> positioned at where HotSpot currently sets -permissive- for Microsoft Visual
> C++ (In other words, TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK)? The 2
> options are
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 Mon, 5 Feb 2024 10:44:59 GMT, Magnus Ihse Bursie wrote:
> I am sorry, but all I can see is:
>
> > Just a few questions...
>
> and then your comment ends. And I can't find any other comment with a list of
> questions.
Eh? Aren't they in the code review section? But in any case:
> Shouldn't
> Inspired by (the later backed-out)
> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
> enable `-Wpedantic` for clang. This has already found some irregularities in
> the code, like mistakenly using `#import` instead of `#include`. In this
> patch, I disable warnings f
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote:
> Inspired by (the later backed-out)
> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
> enable `-Wpedantic` for clang. This has already found some irregularities in
> the code, like mistakenly using `#import`
On Mon, 5 Feb 2024 09:32:09 GMT, Magnus Ihse Bursie wrote:
> > at least not for a future version applying to gcc builds.
>
> @kimbarrett @TheShermanTanker Please do not drag gcc into this PR. This is
> just about clang. Unless gcc makes a serious effort to shape up their
> inferior warning han
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote:
> Inspired by (the later backed-out)
> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
> enable `-Wpedantic` for clang. This has already found some irregularities in
> the code, like mistakenly using `#import`
On Mon, 5 Feb 2024 03:07:43 GMT, Kim Barrett wrote:
> at least not for a future version applying to gcc builds.
@kimbarrett @TheShermanTanker Please do not drag gcc into this PR. This is just
about clang. Unless gcc makes a serious effort to shape up their inferior
warning handling, I don't th
On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using `#import` ins
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
> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for
> correct (Dekker scheme) synchronization with concurrent execution of
> [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java
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
71 matches
Mail list logo
