On Wed, 19 Apr 2023 16:58:32 GMT, Chen Liang wrote:
> The jdk.internal.classfile.components package's interfaces have
> implementations in their nested classes, which are implicitly public and
> exported with the package. They are now moved to the impl package to avoid
> unwanted exposures. Fi
On Thu, 18 May 2023 06:40:30 GMT, Thomas Stuefe wrote:
>> s390x needs to be recognised as `S390`. After
>> [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913) during build I
>> was getting this PluginException:
>>
>> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No
On Thu, 18 May 2023 06:12:19 GMT, Amit Kumar wrote:
> s390x needs to be recognised as `S390`. After
> [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913) during build I was
> getting this PluginException:
>
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum
>
On Thu, 18 May 2023 06:12:19 GMT, Amit Kumar wrote:
> s390x needs to be recognised as `S390`. After
> [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913) during build I was
> getting this PluginException:
>
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum
>
s390x needs to be recognised as `S390`. After
[JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913) during build I was
getting this PluginException:
jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum
constant jdk.internal.util.Architecture.S390X
at
jdk.jli
> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndT
On Wed, 17 May 2023 15:36:40 GMT, Roger Riggs wrote:
> Hmm, most java bytecode (classfiles) aren't going to care about the
> endian-ness; in int is an int, etc.
> Runtime calls to extract int from byte[] is going to check a runtime flag;
> possibly static and optimization by HotSpot, etc.
> The
On Wed, 26 Apr 2023 15:04:50 GMT, Adam Sotona wrote:
> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `Cla
On Wed, 17 May 2023 13:42:32 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 34 commits:
>>
>> - Merge branch 'master' into JDK-8306842-perf-improvements
>>
>># Conflicts:
>># mak
On Wed, 17 May 2023 08:45:23 GMT, Boris Ulasevich
wrote:
> Build issue happens after https://git.openjdk.org/jdk/pull/13585:
>
> $ make bundles
> ...
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum
> constant jdk.internal.util.Architecture.ARM
> at
> jdk.jli
On Wed, 17 May 2023 08:45:23 GMT, Boris Ulasevich
wrote:
> Build issue happens after https://git.openjdk.org/jdk/pull/13585:
>
> $ make bundles
> ...
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum
> constant jdk.internal.util.Architecture.ARM
> at
> jdk.jli
On Wed, 17 May 2023 23:29:40 GMT, Naoto Sato wrote:
>You can import classes in `java.base/sun.nio.cs` with the wild card so that it
>would work on all platforms (`Big5` either in `java.base` or `jdk.charsets`)
Scratch that, you've already did it. Then you can remove these:
import sun.nio.cs.D
On Tue, 16 May 2023 17:13:02 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8308046: Move Solaris related Japanese charsets from java.base to
>> jdk.charsets module
>
> I now think it is bett
On Tue, 16 May 2023 15:14:03 GMT, Ichiroh Takiguchi
wrote:
>> According to "JDK 20 Internationalization Guide"
>> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
>> Following Solaris related Japanese charsets are in "contained in
>> jdk.charsets module" list.
>>
>> - PC
On Wed, 17 May 2023 22:41:16 GMT, Paul Sandoz wrote:
> So maybe this comes down to the linker supporting a subset ABI's data types,
> and that subset might increase over time, but never decrease? In this respect
> could we present a table for each supported linker ABI listing the ABI type
> an
On Wed, 17 May 2023 22:34:32 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/java/lang/foreign/Linker.java line 219:
>>
>>> 217: *
>>> 218: * the alignment constraint of {@code G} is set to its >> href="MemoryLayout.html#layout-align">natural alignment;
>>> 219: * the size of
On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore
wrote:
>> This patch adds an instance method on `Linker`, namely
>> `Linker::canonicalLayouts` which returns all the layouts known by the linker
>> as implementing some ABI type. For instance, if I call this on my machine
>> (Linux/x64) I
On Wed, 17 May 2023 22:08:57 GMT, Paul Sandoz wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Tweak javadoc
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 219:
>
>> 217: *
>> 218: * t
On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore
wrote:
>> This patch adds an instance method on `Linker`, namely
>> `Linker::canonicalLayouts` which returns all the layouts known by the linker
>> as implementing some ABI type. For instance, if I call this on my machine
>> (Linux/x64) I
On Tue, 16 May 2023 13:53:32 GMT, Maurizio Cimadamore
wrote:
> As explained in [1], memory layouts and memory segments describe sizes using
> different units. Memory layouts use bits, whereas memory segments use bytes.
> This is historical: memory layouts were designed after the Minimal LDL [2
On Tue, 16 May 2023 13:53:32 GMT, Maurizio Cimadamore
wrote:
> As explained in [1], memory layouts and memory segments describe sizes using
> different units. Memory layouts use bits, whereas memory segments use bytes.
> This is historical: memory layouts were designed after the Minimal LDL [2
On Wed, 17 May 2023 08:45:23 GMT, Boris Ulasevich
wrote:
> Build issue happens after https://git.openjdk.org/jdk/pull/13585:
>
> $ make bundles
> ...
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum
> constant jdk.internal.util.Architecture.ARM
> at
> jdk.jli
On Wed, 17 May 2023 11:15:11 GMT, Maurizio Cimadamore
wrote:
>> The FFM API exposes layout constants for Java primitives. Among those there
>> are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of
>> these layouts is set the same as their size (e.g. 8 bytes).
>>
>> This
> Replace `{@code ...}` patterns and the like with `{@snippet
> lang=java : ...}`.
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 sev
On Thu, 4 May 2023 20:17:11 GMT, Eric Caspole wrote:
> These micros were developed while investigating JDK-8305670 by myself and
> Sergey Kuksenko. The order of thread creation was important in that bug, so
> there are 2 JMH for creating sleepers before and after the worker threads.
This pull
On Wed, 17 May 2023 14:42:45 GMT, Roger Riggs wrote:
> > Should this issue have a CSR for any behavioral changes?
>
> Well, you can certainly argue that every bug fix is a behavioral changes,
> right :)
>
> But seriously, I don't see how this PR could require a CSR. The only
> behavioral chan
This change intends to interpret the BCP47 U extension wrt collation settings
in the given `Locale`, then applies them to the created instances in the 1-arg
factory method in `Collator`. A corresponding CSR has also been drafted.
-
Commit messages:
- 8308108: Support Unicode extens
On Wed, 17 May 2023 08:45:23 GMT, Boris Ulasevich
wrote:
> Build issue happens after https://git.openjdk.org/jdk/pull/13585:
>
> $ make bundles
> ...
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum
> constant jdk.internal.util.Architecture.ARM
> at
> jdk.jli
On Thu, 4 May 2023 13:36:22 GMT, Tobias Holenstein
wrote:
> At the moment `CompileCommand` and `CompileOnly` use different syntax for
> matching methods.
>
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Cla
> This patch adds an instance method on `Linker`, namely
> `Linker::canonicalLayouts` which returns all the layouts known by the linker
> as implementing some ABI type. For instance, if I call this on my machine
> (Linux/x64) I get this:
>
>
> jshell> import java.lang.foreign.*;
>
> jshell> L
On 17/05/2023 18:52, Maurizio Cimadamore wrote:
I believe that would be an experiment worth doing (if you can!), and
report back if you find any compilation problems.
Ah - I missed this critical last line:
P.S.: To be honest: I tried to pass "--release 21" when compiling
Lucene and it faile
On Wed, 17 May 2023 17:15:06 GMT, Maurizio Cimadamore
wrote:
> This patch adds an instance method on `Linker`, namely
> `Linker::canonicalLayouts` which returns all the layouts known by the linker
> as implementing some ABI type. For instance, if I call this on my machine
> (Linux/x64) I get
This patch adds an instance method on `Linker`, namely
`Linker::canonicalLayouts` which returns all the layouts known by the linker as
implementing some ABI type. For instance, if I call this on my machine
(Linux/x64) I get this:
jshell> import java.lang.foreign.*;
jshell> Linker.nativeLinker
On 17/05/2023 08:58, Uwe Schindler wrote:
If we would change to Java 21 as compilation target, we may need to
adapt our code.
I believe that would be an experiment worth doing (if you can!), and
report back if you find any compilation problems.
E.g. using --release 17 effectively shields L
Build issue happens after https://git.openjdk.org/jdk/pull/13585:
$ make bundles
...
jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum
constant jdk.internal.util.Architecture.ARM
at
jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuil
> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>
> A few implementation-detail methods in VarHandle are now documented with the
> implied constraints to avoid subtle problems in the future. Changed
> `IndirectVarHandle` to call `asDirect` lazily to accomodate the la
Hi,
Thanks for the report, I created a Jira issue to track the investigation.
https://bugs.openjdk.org/browse/JDK-8308302
Regards, Roger
On 5/13/23 2:43 PM, andr...@flueckiger.ch wrote:
Subject:
Leap second handling in Windows timestamps
From:
Date:
5/13/23, 2:43 PM
To:
Hello,
This is my
On Wed, 17 May 2023 16:00:23 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly sta
> Replace `{@code ...}` patterns and the like with `{@snippet
> lang=java : ...}`.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8308016: Reinstate @snippet for RandomAccessFile::readLong
-
Changes:
- all: https
On Thu, 4 May 2023 13:36:22 GMT, Tobias Holenstein
wrote:
> At the moment `CompileCommand` and `CompileOnly` use different syntax for
> matching methods.
>
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Cla
On Wed, 17 May 2023 16:05:58 GMT, Volker Simonis wrote:
>> src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 140:
>>
>>> 138: struct stat buf;
>>> 139: /* argv[0] contains the fd number to read all the child info */
>>> 140: int r, fdinr, fdinw, fdout;
>>
>> Since you are h
On Wed, 17 May 2023 14:42:45 GMT, Roger Riggs wrote:
> if parent process dies prematurely
@RogerRiggs , I've created a release note for the issue based on your
suggestions. Please feel free to proof-read and enhance it :)
-
PR Comment: https://git.openjdk.org/jdk/pull/13956#issuec
> These micros were developed while investigating JDK-8305670 by myself and
> Sergey Kuksenko. The order of thread creation was important in that bug, so
> there are 2 JMH for creating sleepers before and after the worker threads.
Eric Caspole has updated the pull request incrementally with one
On Wed, 17 May 2023 14:10:59 GMT, Thomas Stuefe wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added test case
>
> src/java.base/unix/native/libjava/ProcessImpl_md.c line 490:
>
>> 488: pid_t resultPid;
>>
On 5/17/2023 7:07 AM, Ethan McCue wrote:
> if they have setup their projects correctly.
Can you be more clear about what "setup their projects correctly"
means? If you are referring to usage of --release, you seem to be
making a pretty strong argument that this will not be the case.
Use of
On Wed, 17 May 2023 13:46:29 GMT, Thomas Stuefe wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added test case
>
> src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 140:
>
>> 138: struct stat buf;
> Since JDK13, executing commands in a sub-process defaults to the so called
> `POSIX_SPAWN` launching mechanism (i.e.
> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
> using `posix_spawn(3)` to firstly start a tiny helper program called
> `jspawnhelper` in a subproc
On Wed, 17 May 2023 14:55:00 GMT, Roger Riggs wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added test case
>
> src/java.base/unix/native/libjava/childproc.c line 408:
>
>> 406: * or the newly created jspawnh
On Sun, 14 May 2023 05:50:20 GMT, Tagir F. Valeev wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8308016: Remove ellipses ("...") from snippets
>
> src/java.base/share/classes/java/io/RandomAccessFile.java lin
On Wed, 17 May 2023 10:31:25 GMT, Alan Bateman wrote:
>> Yes, linux-ppc64 is big endian. The 2 flavors are completely incompatible.
>> linux-ppc64le is basically a new platform. Endianness should actually get
>> checked in addition to the archName.
>
>> Yes, linux-ppc64 is big endian. The 2 fla
On Tue, 16 May 2023 21:35:14 GMT, Joe Darcy wrote:
> Tightening up accessibility of a few nested classes. There is no practical
> impact on source compatibility -- source uses within the package still work,
> but by default the ability to reflectively call methods on these classes is
> disable
On Wed, 17 May 2023 15:05:53 GMT, Raffaello Giulietti
wrote:
>> When appropriate and useful, copies only the relevant portion of the
>> `CharSequence` to the match result.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
On Wed, 17 May 2023 07:16:17 GMT, Martin Doerr wrote:
> PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize
> the platform and throws a PluginException: ModuleTarget is malformed: No enum
> constant jdk.internal.util.Architecture.PPC64LE.
This pull request has now been
On Wed, 17 May 2023 12:40:58 GMT, Volker Simonis wrote:
> If we do a short read we will work with corrupted `ChildStuff` and
> `SpawnInfo` structures.
i would agree failing after readFully returns short reads is fine. It won’t
stop the method from retrying/completing endlessly in a pathologica
On Wed, 17 May 2023 09:19:10 GMT, Raffaello Giulietti
wrote:
>> When appropriate and useful, copies only the relevant portion of the
>> `CharSequence` to the match result.
>
> Raffaello Giulietti has updated the pull request with a new target base due
> to a merge or a rebase. The incremental
On Wed, 17 May 2023 14:42:52 GMT, Claes Redestad wrote:
>> Raffaello Giulietti 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
>> additiona
On Wed, 17 May 2023 09:42:58 GMT, Martin Doerr wrote:
>> PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize
>> the platform and throws a PluginException: ModuleTarget is malformed: No
>> enum constant jdk.internal.util.Architecture.PPC64LE.
>
> Martin Doerr has updated
On Wed, 17 May 2023 12:48:17 GMT, Volker Simonis wrote:
> > Should this issue have a CSR for any behavioral changes?
>
> Well, you can certainly argue that every bug fix is a behavioral changes,
> right :)
>
> But seriously, I don't see how this PR could require a CSR. The only
> behavioral c
> When appropriate and useful, copies only the relevant portion of the
> `CharSequence` to the match result.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Simplified text capturing.
-
Changes:
- all: https://
On Wed, 17 May 2023 12:33:48 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly sta
On Thu, 4 May 2023 13:36:22 GMT, Tobias Holenstein
wrote:
> At the moment `CompileCommand` and `CompileOnly` use different syntax for
> matching methods.
>
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Cla
At the moment `CompileCommand` and `CompileOnly` use different syntax for
matching methods.
### Old CompileOnly format
- matching a **method name** with **class name** and **package name**:
`-XX:CompileOnly=package/path/Class.method`
`-XX:CompileOnly=package/path/Class::method`
`-XX:CompileOnly=
On Wed, 17 May 2023 11:46:39 GMT, Per Minborg wrote:
> As the API has improved over the recent releases, not all `{@snippet ..}`
> sections have been kept in sync.
>
> This PR suggests all snippets used should be verified against real code that
> is placed in a new `snippet-files` folder and e
On Wed, 17 May 2023 12:33:48 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly sta
> if they have setup their projects correctly.
Can you be more clear about what "setup their projects correctly" means? If
you are referring to usage of --release, you seem to be making a pretty
strong argument that this will not be the case.
> We tested Apache Lucene and Apache Solr with Java 21
On Wed, 17 May 2023 10:41:57 GMT, Daniel Jeliński wrote:
>> Darragh Clarke has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Update
>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>>
>>Co-autho
> Updated instances of `toLowerCase` and `toUpperCase` in several net and io
> files to specify `Locale.ROOT` to ensure that case conversion issues don't
> occur,
>
> I didn't add any new tests but ran tier 1-3 with no issues
Darragh Clarke has updated the pull request incrementally with two ad
On Wed, 17 May 2023 13:41:16 GMT, Adam Sotona wrote:
>> Following improvements implemented:
>> - Switch over `String` replaced with switch single char
>> - Binary search for frames in `StackMapGenerator`
>> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
>> - `ClassEntry` is caching
On Wed, 17 May 2023 13:28:53 GMT, Adam Sotona wrote:
>> Good, I think it makes perfect sense for the MTD parameter list to be
>> immutable and shareable without copying.
>
> Thank you for the review.
> Yes, I'm looking forward to see it together with Constants API improvements
> in one benchama
> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndT
On Tue, 16 May 2023 22:00:18 GMT, Claes Redestad wrote:
>> I plan to share a backing list in #13186, with API additions so users can
>> avoid copying their input immutable parameter list as well. I see no reason
>> to use a direct array, for MTD is not passed to and used by the VM, unlike
>> M
On Tue, 16 May 2023 18:10:08 GMT, Chen Liang wrote:
>> The jdk.internal.classfile.components package's interfaces have
>> implementations in their nested classes, which are implicitly public and
>> exported with the package. They are now moved to the impl package to avoid
>> unwanted exposures
On Mon, 15 May 2023 19:55:45 GMT, Bernd wrote:
> Independent of the actual fix, it was mentioned that it can block listening
> sockets, aren’t those close on exec? Also should a write and read timeout be
> used in addition? At least to call the close descriptor code before retrying?
While the
On Tue, 9 May 2023 19:13:42 GMT, Eric Caspole wrote:
>> These micros were developed while investigating JDK-8305670 by myself and
>> Sergey Kuksenko. The order of thread creation was important in that bug, so
>> there are 2 JMH for creating sleepers before and after the worker threads.
>
> Eric
On Mon, 3 Apr 2023 16:58:15 GMT, Andrey Turbanov wrote:
> `Pattern.namedGroups` and `Matcher.namedGroups` contains only non-null
> values. It means instead of separate `containsKey`+`get` calls, we can use
> single `HashMap.get` call and then compare result with null.
> Result code is a bit sim
On Mon, 15 May 2023 20:00:28 GMT, Joe Darcy wrote:
> Should this issue have a CSR for any behavioral changes?
Well, you can certainly argue that every bug fix is a behavioral changes, right
:)
But seriously, I don't see how this PR could require a CSR. The only behavioral
change is really tha
On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona wrote:
> Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc`
> and `PackageDesc` become obsolete after
> [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729).
> All references to `jdk.internal.classfile.java.lang.const
On Mon, 15 May 2023 18:45:24 GMT, Roger Riggs wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly start
On Tue, 16 May 2023 12:32:44 GMT, Thomas Stuefe wrote:
> > > > I wonder if @Martin-Buchholz is able to look at this one?
> > > > My concern with changes like this is that they fix an issue but then
> > > > have unexpected side-effects themselves.
> > >
> > >
> > > Are there any specific concer
When using the clang compiler to build OpenJDk on Linux, we encounter various
"warnings as errors".
They can be fixed with small changes.
-
Commit messages:
- 8308286 Fix clang warnings in linux code
Changes: https://git.openjdk.org/jdk/pull/14033/files
Webrev: https://webrevs.ope
> Since JDK13, executing commands in a sub-process defaults to the so called
> `POSIX_SPAWN` launching mechanism (i.e.
> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
> using `posix_spawn(3)` to firstly start a tiny helper program called
> `jspawnhelper` in a subproc
As the API has improved over the recent releases, not all `{@snippet ..}`
sections have been kept in sync.
This PR suggests all snippets used should be verified against real code that is
placed in a new `snippet-files` folder and erroneous snippets are updated.
-
Commit messages:
On Wed, 17 May 2023 11:46:39 GMT, Per Minborg wrote:
> As the API has improved over the recent releases, not all `{@snippet ..}`
> sections have been kept in sync.
>
> This PR suggests all snippets used should be verified against real code that
> is placed in a new `snippet-files` folder and e
On Tue, 16 May 2023 17:13:02 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8308046: Move Solaris related Japanese charsets from java.base to
>> jdk.charsets module
>
> I now think it is bett
On Tue, 16 May 2023 13:53:32 GMT, Maurizio Cimadamore
wrote:
> As explained in [1], memory layouts and memory segments describe sizes using
> different units. Memory layouts use bits, whereas memory segments use bytes.
> This is historical: memory layouts were designed after the Minimal LDL [2
As explained in [1], memory layouts and memory segments describe sizes using
different units. Memory layouts use bits, whereas memory segments use bytes.
This is historical: memory layouts were designed after the Minimal LDL [2],
which allowed layout strings to be used to describe both memory *a
> The FFM API exposes layout constants for Java primitives. Among those there
> are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of
> these layouts is set the same as their size (e.g. 8 bytes).
>
> This is obviously correct on 64-bit platforms, but on 32-bit platform it
On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke wrote:
> Updated instances of `toLowerCase` and `toUpperCase` in several net and io
> files to specify `Locale.ROOT` to ensure that case conversion issues don't
> occur,
>
> I didn't add any new tests but ran tier 1-3 with no issues
src/java.ba
On Wed, 17 May 2023 09:07:03 GMT, Martin Doerr wrote:
> Yes, linux-ppc64 is big endian. The 2 flavors are completely incompatible.
> linux-ppc64le is basically a new platform. Endianness should actually get
> checked in addition to the archName.
Okay, I was only asking because the ModuleTarget
On Tue, 9 May 2023 19:13:42 GMT, Eric Caspole wrote:
>> These micros were developed while investigating JDK-8305670 by myself and
>> Sergey Kuksenko. The order of thread creation was important in that bug, so
>> there are 2 JMH for creating sleepers before and after the worker threads.
>
> Eric
On Wed, 17 May 2023 09:42:58 GMT, Martin Doerr wrote:
>> PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize
>> the platform and throws a PluginException: ModuleTarget is malformed: No
>> enum constant jdk.internal.util.Architecture.PPC64LE.
>
> Martin Doerr has updated
> In contrast the foreign memory API is very stable already since Java 19 and
> the changes were minimal in 21.
If you take a look at differences from Java 20 to Java 21 on Java
Almanac [1] for java.lang.foreign.
I wouldn't really call it minimal. Lots of classes and methods were
added and remove
On Tue, 16 May 2023 11:18:09 GMT, Maurizio Cimadamore
wrote:
> The FFM API exposes layout constants for Java primitives. Among those there
> are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of
> these layouts is set the same as their size (e.g. 8 bytes).
>
> This is o
On Tue, 16 May 2023 21:35:14 GMT, Joe Darcy wrote:
> Tightening up accessibility of a few nested classes. There is no practical
> impact on source compatibility -- source uses within the package still work,
> but by default the ability to reflectively call methods on these classes is
> disable
The FFM API exposes layout constants for Java primitives. Among those there are
constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these
layouts is set the same as their size (e.g. 8 bytes).
This is obviously correct on 64-bit platforms, but on 32-bit platform it is
not, a
> PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize
> the platform and throws a PluginException: ModuleTarget is malformed: No enum
> constant jdk.internal.util.Architecture.PPC64LE.
Martin Doerr has updated the pull request incrementally with one additional
commit si
On Wed, 17 May 2023 04:50:14 GMT, Stuart Marks wrote:
>> src/java.base/share/classes/java/util/regex/Matcher.java line 1381:
>>
>>> 1379:
>>> 1380: // Capture the input sequence as a string on first
>>> find
>>> 1381: textAsString = captureText();
>>
>> Is this
On Tue, 16 May 2023 13:29:26 GMT, Claes Redestad wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added some randomness in tests.
>
> src/java.base/share/classes/java/util/regex/Matcher.java line 359:
>
>> 3
On Wed, 17 May 2023 05:24:28 GMT, Stuart Marks wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added some randomness in tests.
>
> src/java.base/share/classes/java/util/regex/Matcher.java line 271:
>
>> 269
> When appropriate and useful, copies only the relevant portion of the
> `CharSequence` to the match result.
Raffaello Giulietti 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.
1 - 100 of 111 matches
Mail list logo
