On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote:
> C11 has been stable for a long time on all platforms, so native code can use
> the standard alignas operator for alignment requirements
I'm not sure what you mean by hotspot requiring a special review, but
serviceability code does
On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote:
> C11 has been stable for a long time on all platforms, so native code can use
> the standard alignas operator for alignment requirements
globalDefinitions_visCPP.hpp (and the corresponding globalDefinitions file for
gcc based compilers)
On Fri, 3 Feb 2023 19:49:44 GMT, Justin King wrote:
> Avoid using `lseek` + `read` in favor of `pread`. For Windows, we can do the
> same thing by using `OVERLAPPED`, as we are in synchronous mode we can use
> `Offset` and `OffsetHigh` to achieve the same thing.
>
> Additionally I updated
On Sat, 1 Apr 2023 07:44:25 GMT, Quan Anh Mai wrote:
>> `Vector::slice` is a method at the top-level class of the Vector API that
>> concatenates the 2 inputs into an intermediate composite and extracts a
>> window equal to the size of the inputs into the result. It is used in vector
>>
On Mon, 3 Apr 2023 22:58:30 GMT, Naoto Sato wrote:
> Introducing new regex constructs that match those 6 new Unicode Emoji
> properties implemented in the `Character` class
> (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been
> drafted.
Associated CSR also Reviewed.
On Tue, 4 Apr 2023 00:56:09 GMT, Quan Anh Mai wrote:
> Thanks, may I integrate the changes now?
You might need another HotSpot reviewer? @vnkozlov is that correct?
-
PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1495198225
On Fri, 31 Mar 2023 12:25:16 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch reimplements `VectorShuffle` implementations to be a vector of
>> the bit type. Currently, VectorShuffle is stored as a byte array, and would
>> be expanded upon usage. This poses several drawbacks:
>>
>> 1.
On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons wrote:
> Please review a change to add `@spec` tags (and remove some equivalent `@see`
> tags) to the main "core-libs" packages in `java.base` module.
>
> This is similar to, and a subset of, PR #11073. That PR was withdrawn, and
> based on
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an
> Pleases review this PR.
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in
> 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)). To work
> around the the limitation of JSR 310 compiler, where the time
> Pleases review this PR.
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in
> 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)). To work
> around the the limitation of JSR 310 compiler, where the time
On Fri, 31 Mar 2023 22:06:34 GMT, Sergey Bylokhov wrote:
>> Pleases review this PR.
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in
>> 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)). To work
On Fri, 31 Mar 2023 22:05:01 GMT, Sergey Bylokhov wrote:
>> Pleases review this PR.
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in
>> 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)). To work
On Fri, 31 Mar 2023 16:44:52 GMT, Naoto Sato wrote:
>> Pleases review this PR.
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in
>> 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)). To work
>>
Introducing new regex constructs that match those 6 new Unicode Emoji
properties implemented in the `Character` class
(https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been
drafted.
-
Commit messages:
- 8305107: Emoji related binary properties in RegEx
On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes wrote:
>> We have the strange situation where calling `t.isAlive()` on a
>> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
>> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
>> its `JavaThread`
> We have the strange situation where calling `t.isAlive()` on a
> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
> its `JavaThread` pointer and compare it to null. We can simply read `eetop`
>
> This implements a shared utility to dump generated classes defined as
> normal/hidden classes via `Lookup` API. This replaces the implementation in
> `LambdaMetaFactory` and method handle implementation that dumps the hidden
> class bytes on disk for debugging.
>
> For classes defined
> This implements a shared utility to dump generated classes defined as
> normal/hidden classes via `Lookup` API. This replaces the implementation in
> `LambdaMetaFactory` and method handle implementation that dumps the hidden
> class bytes on disk for debugging.
>
> For classes defined
On Mon, 3 Apr 2023 21:05:07 GMT, Rémi Forax wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> comments from Jorn Vernee
>
> src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 199:
>
>> 197:
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an
On Mon, 3 Apr 2023 20:24:56 GMT, Mandy Chung wrote:
>> This implements a shared utility to dump generated classes defined as
>> normal/hidden classes via `Lookup` API. This replaces the implementation
>> in `LambdaMetaFactory` and method handle implementation that dumps the
>> hidden class
On Mon, 3 Apr 2023 20:24:56 GMT, Mandy Chung wrote:
>> This implements a shared utility to dump generated classes defined as
>> normal/hidden classes via `Lookup` API. This replaces the implementation
>> in `LambdaMetaFactory` and method handle implementation that dumps the
>> hidden class
On Mon, 3 Apr 2023 19:41:28 GMT, Jorn Vernee wrote:
>> I see your point. If it were a static counter for all dumpers,
>> multiple`.failed-xxx` dumped by a single dumper may not be in sequence if
>> other dumpers have `.failed-xxx` class files.
>
> If the counter has to be per dumper, maybe
> This implements a shared utility to dump generated classes defined as
> normal/hidden classes via `Lookup` API. This replaces the implementation in
> `LambdaMetaFactory` and method handle implementation that dumps the hidden
> class bytes on disk for debugging.
>
> For classes defined
On Mon, 3 Apr 2023 19:56:03 GMT, Alan Bateman wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replaced "Java Runtime Environment" with "JDK Reference Implementation"
>
>
On Mon, 3 Apr 2023 18:11:03 GMT, Naoto Sato wrote:
>> This is a precursor to the future removal of the `COMPAT` locale data
>> provider. Before the actual removal of the provider, warn the users who
>> explicitly specify `COMPAT` at the command line in order for their smooth
>> migration to
On Thu, 23 Feb 2023 15:36:48 GMT, Viktor Klang wrote:
> Clarifies the distinction between expiration of the head of DelayQueue and
> how it relates to `poll`, `take`, and `peek`. See discussion on
> https://bugs.openjdk.org/browse/JDK-8297605
>
> @DougLea If possible, please weigh in on
On Fri, 24 Feb 2023 16:08:57 GMT, Viktor Klang wrote:
>> Clarifies the distinction between expiration of the head of DelayQueue and
>> how it relates to `poll`, `take`, and `peek`. See discussion on
>> https://bugs.openjdk.org/browse/JDK-8297605
>>
>> @DougLea If possible, please weigh in on
On Mon, 3 Apr 2023 19:26:13 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2536:
>>
>>> 2534: }
>>> 2535: } else {
>>> 2536: name += ".failed-" +
>>>
On Mon, 3 Apr 2023 19:21:00 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 115:
>>
>>> 113: if (dumper.isEnabled() && !path.equals(dumper.dumpPath())) {
>>> 114: throw new IllegalArgumentException("mismatched dump path
>>>
On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote:
> C11 has been stable for a long time on all platforms, so native code can use
> the standard alignas operator for alignment requirements
> I don't think I can touch the freetype code since I think it's an external
> library that was
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an
On Mon, 3 Apr 2023 18:13:54 GMT, Jorn Vernee wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> set -D or -D=true will enable dumping
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2536:
>
On Mon, 3 Apr 2023 18:07:52 GMT, Jorn Vernee wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> set -D or -D=true will enable dumping
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
On Thu, 30 Mar 2023 18:46:25 GMT, Mandy Chung wrote:
>> This implements a shared utility to dump generated classes defined as
>> normal/hidden classes via `Lookup` API. This replaces the implementation
>> in `LambdaMetaFactory` and method handle implementation that dumps the
>> hidden class
Hi,
This patch adds `VectorMask.xor` to the public interface of `VectorMask`. This
method has already been existed in each concrete mask classes. Also, this patch
renames `VectorMask.eq` to `VectorMask::xorNot`, which is more consistent with
other logical operations in the same interface.
On Mon, 3 Apr 2023 17:25:57 GMT, Alan Bateman wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replaced "Java Runtime Environment" with "JDK Reference Implementation"
>
>
> This is a precursor to the future removal of the `COMPAT` locale data
> provider. Before the actual removal of the provider, warn the users who
> explicitly specify `COMPAT` at the command line in order for their smooth
> migration to CLDR. A CSR has also been drafted.
Naoto Sato has updated
On Mon, 3 Apr 2023 17:43:55 GMT, Raffaello Giulietti
wrote:
> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in
> addition to the substrings returned by current `split()` variants, also
> return the delimiters matching the regular expression.
Also see
Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in
addition to the substrings returned by current `split()` variants, also return
the delimiters matching the regular expression.
-
Commit messages:
- 8305486: Add split() variants that keep the delimiters to
On Mon, 3 Apr 2023 16:47:40 GMT, Naoto Sato wrote:
> This is a precursor to the future removal of the `COMPAT` locale data
> provider. Before the actual removal of the provider, warn the users who
> explicitly specify `COMPAT` at the command line in order for their smooth
> migration to CLDR.
On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy wrote:
> The StringBuilder and StringBuffer classes are Appendable by virtue of from
> subclasses their non-public superclass AbstractStringBuilder.
>
> It is slightly clearer to declare StringBuilder and StringBuffer to directly
> implement
On Sun, 2 Apr 2023 07:45:23 GMT, Sergey Tsypanov wrote:
>> The StringBuilder and StringBuffer classes are Appendable by virtue of from
>> subclasses their non-public superclass AbstractStringBuilder.
>>
>> It is slightly clearer to declare StringBuilder and StringBuffer to directly
>>
On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy wrote:
> The StringBuilder and StringBuffer classes are Appendable by virtue of from
> subclasses their non-public superclass AbstractStringBuilder.
>
> It is slightly clearer to declare StringBuilder and StringBuffer to directly
> implement
This is a precursor to the future removal of the `COMPAT` locale data provider.
Before the actual removal of the provider, warn the users who explicitly
specify `COMPAT` at the command line in order for their smooth migration to
CLDR. A CSR has also been drafted.
-
Commit
On Wed, 29 Mar 2023 18:05:46 GMT, Brian Burkhalter wrote:
>> Modify the `Space` instances used for size comparison to be created with
>> total number of bytes derived from the Windows `diskFree` utility instead of
>> Cygwin’s `df`.
>
> Brian Burkhalter has updated the pull request
On Sat, 1 Apr 2023 07:44:25 GMT, Quan Anh Mai wrote:
>> `Vector::slice` is a method at the top-level class of the Vector API that
>> concatenates the 2 inputs into an intermediate composite and extracts a
>> window equal to the size of the inputs into the result. It is used in vector
>>
On Tue, 14 Feb 2023 17:46:21 GMT, Eirik Bjorsnos wrote:
> CorruptedZipFiles could benefit from some spring cleaning and a conversion to
> junit:
>
> - The actual tests are moved into their own `@Test` methods, given more
> meaningful names and a Javadoc comment explaining the constraint being
On Wed, 29 Mar 2023 16:10:34 GMT, Roger Riggs wrote:
>> Brian Burkhalter 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 five additional
>>
On Tue, 28 Feb 2023 21:26:55 GMT, Brian Burkhalter wrote:
>> Spawning `df` and `diskFree` processes have been replaced with native calls.
>> For a reason as yet undetermined, the Windows function
>> `GetDiskSpaceInformationW` fails to load on Windows Server 2016 so it is
>> loaded dynamically
On Thu, 23 Feb 2023 13:13:43 GMT, Jim Laskey wrote:
> Add the ability to repeatedly append char and CharSequence data to
> StringBuilder/StringBuffer.
This pull request has now been integrated.
Changeset: 9b9b5a7a
Author:Jim Laskey
URL:
On Fri, 31 Mar 2023 12:25:16 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch reimplements `VectorShuffle` implementations to be a vector of
>> the bit type. Currently, VectorShuffle is stored as a byte array, and would
>> be expanded upon usage. This poses several drawbacks:
>>
>> 1.
On Fri, 31 Mar 2023 12:25:16 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch reimplements `VectorShuffle` implementations to be a vector of
>> the bit type. Currently, VectorShuffle is stored as a byte array, and would
>> be expanded upon usage. This poses several drawbacks:
>>
>> 1.
On Tue, 21 Mar 2023 17:51:26 GMT, Martin Buchholz wrote:
>> Inviting @DougLea and @viktorklang-ora to review.
>>
>> As usual, I couldn't resist more fiddling.
>> - Added missing tests for take, remove(), remove(Object).
>> - Improved DelayQueueTest's testing infrastructure
>> - added more
On Mon, 3 Apr 2023 12:32:35 GMT, David Holmes wrote:
> > This looks interesting. I think it is time to rename eetop to
> > javaThreadAddr ...
>
> Feel free to file a RFE but not as part of this PR. :)
Well, when this thing is considered in isolation, it changes the clear
`isAlive0()` call to
On Fri, 31 Mar 2023 19:59:10 GMT, Eirik Bjorsnos wrote:
>> CorruptedZipFiles could benefit from some spring cleaning and a conversion
>> to junit:
>>
>> - The actual tests are moved into their own `@Test` methods, given more
>> meaningful names and a Javadoc comment explaining the constraint
> CorruptedZipFiles could benefit from some spring cleaning and a conversion to
> junit:
>
> - The actual tests are moved into their own `@Test` methods, given more
> meaningful names and a Javadoc comment explaining the constraint being
> verified
> - The setup code is moved to a `@Before`
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an
On 3/04/2023 9:27 pm, Simon Roberts wrote:
Agreed, I believe there should be an hb relationship with this, if the
target is not alive.
You are both right - I did not recall the hb relationship between the
last action of a thread and a call to isAlive that returns false. The
existing code
On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes wrote:
>> We have the strange situation where calling `t.isAlive()` on a
>> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
>> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
>> its `JavaThread`
On Mon, 3 Apr 2023 11:39:43 GMT, Aleksey Shipilev wrote:
> This looks interesting. I think it is time to rename eetop to javaThreadAddr
> ...
Feel free to file a RFE but not as part of this PR. :)
-
PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1494240185
On Mon, 3 Apr 2023 10:47:55 GMT, Quan Anh Mai wrote:
> May I ask if we need some form of memory order here? Maybe an aquiring load
> is necessary?
What is it that you think needs ordering?
-
PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1494238641
On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes wrote:
>> We have the strange situation where calling `t.isAlive()` on a
>> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
>> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
>> its `JavaThread`
Agreed, I believe there should be an hb relationship with this, if the
target is not alive.
On Mon, Apr 3, 2023, 04:50 Quan Anh Mai wrote:
> On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes wrote:
>
> >> We have the strange situation where calling `t.isAlive()` on a
> `java.lang.Thread` `t`, will
On Mon, 3 Apr 2023 10:58:35 GMT, Tingjun Yuan wrote:
> So we don't have to change these classes.
They are just examples where the superclass is not-public.
> But in this issue, all public supertypes of `String{Builder,Buffer}`
> (`Serializable`, `Comparable`, `CharSequence` and `Object`) do
On Mon, 3 Apr 2023 10:23:03 GMT, Alan Bateman wrote:
> > Are there more places where we "accidentally" expose interfaces via
> > non-public (or even public) super classes?
>
> Appendable was added as part of the scanning/formatting update in Java 5.
> It's intentional that SB implements
On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes wrote:
>> We have the strange situation where calling `t.isAlive()` on a
>> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
>> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
>> its `JavaThread`
On Mon, 3 Apr 2023 07:57:56 GMT, Per Minborg wrote:
> Are there more places where we "accidentally" expose interfaces via
> non-public (or even public) super classes?
Appendable was added as part of the scanning/formatting update in Java 5. It's
intentional that SB implements Appendable but
> We have the strange situation where calling `t.isAlive()` on a
> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
> its `JavaThread` pointer and compare it to null. We can simply read `eetop`
>
On Mon, 3 Apr 2023 07:53:00 GMT, Alan Bateman wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Comment from AlanB
>
> src/java.base/share/classes/java/lang/Thread.java line 231:
>
>> 229: /* Reserved for
On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy wrote:
> The StringBuilder and StringBuffer classes are Appendable by virtue of from
> subclasses their non-public superclass AbstractStringBuilder.
>
> It is slightly clearer to declare StringBuilder and StringBuffer to directly
> implement
On Mon, 3 Apr 2023 07:17:59 GMT, David Holmes wrote:
> We have the strange situation where calling `t.isAlive()` on a
> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
> its `JavaThread` pointer
We have the strange situation where calling `t.isAlive()` on a
`java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`)
where the VM then examines the `eetop` field of `t` to extract its `JavaThread`
pointer and compare it to null. We can simply read `eetop` directly in
On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy wrote:
> The StringBuilder and StringBuffer classes are Appendable by virtue of from
> subclasses their non-public superclass AbstractStringBuilder.
>
> It is slightly clearer to declare StringBuilder and StringBuffer to directly
> implement
On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote:
> C11 has been stable for a long time on all platforms, so native code can use
> the standard alignas operator for alignment requirements
Just checked, the pragmas in the freetype code now seems to be pointless since
there is no alignment
On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy wrote:
> The StringBuilder and StringBuffer classes are Appendable by virtue of from
> subclasses their non-public superclass AbstractStringBuilder.
>
> It is slightly clearer to declare StringBuilder and StringBuffer to directly
> implement
The StringBuilder and StringBuffer classes are Appendable by virtue of from
subclasses their non-public superclass AbstractStringBuilder.
It is slightly clearer to declare StringBuilder and StringBuffer to directly
implement Appendable, as they already directly implement the CharSequence
On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote:
> C11 has been stable for a long time on all platforms, so native code can use
> the standard alignas operator for alignment requirements
I don't think I can touch the freetype code since I think it's an external
library that was
On Thu, 30 Mar 2023 11:28:25 GMT, Per Minborg wrote:
>> API changes for the FFM API (third preview)
>>
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>>
>> Javadoc:
>>
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an
On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy wrote:
> The StringBuilder and StringBuffer classes are Appendable by virtue of from
> subclasses their non-public superclass AbstractStringBuilder.
>
> It is slightly clearer to declare StringBuilder and StringBuffer to directly
> implement
On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu wrote:
> Please review the ISO 4217 amendment 175 update.
>
> There are no meaningful code changes, but the version number should be
> updated accordingly to be in sync.
Marked as reviewed by m4ximumpi...@github.com (no known OpenJDK username).
On Fri, 31 Mar 2023 12:25:16 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch reimplements `VectorShuffle` implementations to be a vector of
>> the bit type. Currently, VectorShuffle is stored as a byte array, and would
>> be expanded upon usage. This poses several drawbacks:
>>
>> 1.
On Fri, 31 Mar 2023 19:59:10 GMT, Eirik Bjorsnos wrote:
>> CorruptedZipFiles could benefit from some spring cleaning and a conversion
>> to junit:
>>
>> - The actual tests are moved into their own `@Test` methods, given more
>> meaningful names and a Javadoc comment explaining the constraint
On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy wrote:
> The StringBuilder and StringBuffer classes are Appendable by virtue of from
> subclasses their non-public superclass AbstractStringBuilder.
>
> It is slightly clearer to declare StringBuilder and StringBuffer to directly
> implement
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an
On Fri, 31 Mar 2023 19:58:24 GMT, Eirik Bjorsnos wrote:
>> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 192:
>>
>>> 190: /*
>>> 191: * Validate that a ZipException is thrown when the 'End of Central
>>> Directory'
>>> 192: * (END) header has a CEN offset incoherent
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an
> `Vector::slice` is a method at the top-level class of the Vector API that
> concatenates the 2 inputs into an intermediate composite and extracts a
> window equal to the size of the inputs into the result. It is used in vector
> conversion methods where the part number is not 0 to slice the
This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
JDK-8302801 was that it neglected (mea culpa) to include a Java implementation
of IEEEremainder before the FDLIBM C implementation was deleted. Such an
implementation has been successfully provided under JDK-8304028:
Hi Stuart,
First, thanks for you detailed reply.
On 25/03/2023 00:16, Stuart Marks wrote:
...
Yes, this has come up before, but it's been mostly theoretical. That is,
people worry about this when they hear of the idea of randomized
iteration order, but I've never heard any followup. This is
On Sun, 2 Apr 2023 06:45:30 GMT, Alan Bateman wrote:
> Right now, the javadoc for SB lists Appendable in the "All Implemented
> Interfaces" list. With this change it will be shown in the class declaration
> in the list of "implements" list. Make sense.
Correct; after the change, the
93 matches
Mail list logo
