On Thu, 7 Mar 2024 19:47:55 GMT, Roger Riggs wrote:
>> Elif Aslan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add args[0] back
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 29:
>
>> 27: * @test
>> 28: *
> To avoid the CDS dump error message, a fix is during dumping a classlist,
> check if an invoker can be archived.
> If not, don't write the invoker info into the classlist, i.e. don't call
> `logLambdaFormInvoker()`. While generating holder classes (in
> `generateHolderClasses()`), don't add
On Thu, 7 Mar 2024 21:07:12 GMT, Naoto Sato wrote:
> Thanks for the fix. Although setting `Locale.US` to acquire the formatter is
> correct, the reasoning is not. The real reason is that `Date.toString()` uses
> `Locale.US` explicitly for printing the time zone
>
>
On Fri, 8 Mar 2024 02:41:06 GMT, SendaoYan wrote:
>> Date.toString() uses Locale.US explicitly for printing the time zone, so
>> replace Locale.ROOT to Locale.US in this testcase for fix the test failure.
>>
>> This testcase fixed has been verified.
>>
>> Only change the testcase, risk is
RecordComponent class has _attributes_count field.
The only user of the field is JvmtiClassFileReconstituter. Incorrect value of
the field causes producing incorrect data for Record attribute.
Parsing Record attribute ClassFileParser skips unknown attributes and may skip
> The DATE_FORMAT_PATTERN is set to "EEE MMM dd HH:mm:ss zzz ", is the time
> format of US. So, creates a formatter should using Locale.US, rather than
> Locale.ROOT, which means empty.
SendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato wrote:
> A simple doc update to include a leap day example in the `Calendar` class.
Marked as reviewed by iris (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923843891
Please review this PR which is a trivial update to the IANA sub tag registry to
version 2024-03-07. Tests pass as expected after update.
Associated announcement ->
https://mm.icann.org/pipermail/ietf-languages-announcements/2024-March/90.html
-
Commit messages:
- init
On Wed, 6 Mar 2024 22:00:42 GMT, Ioi Lam wrote:
>> To avoid the CDS dump error message, a fix is during dumping a classlist,
>> check if an invoker can be archived.
>> If not, don't write the invoker info into the classlist, i.e. don't call
>> `logLambdaFormInvoker()`. While generating holder
On Thu, 7 Mar 2024 21:00:01 GMT, Ioi Lam wrote:
>> A few clean ups:
>>
>> 1. Rename functions like "`s_loading_full_module_graph()` to
>> `is_using_full_module_graph()`. The meaning of "loading" is not clear: it
>> might be interpreted as to cover only the period where the artifact is being
I’m only interested in macOS universal applications. I don’t see a need for
multi-OS applications.
The shared libraries do not need to be merged as the runtime is not itself
universal, only the launcher is.
The launcher finds the appropriate single-architecture runtime and launches it.
> On
Alan Snyder wrote on 7. Mar 2024 22:39 (GMT +01:00):
> That could be done, but it would require more work with no obvious
> benefit.
>
> Only the Java launcher needs to be universal from the perspective of the
> OS.
it’s however not only the exetables. You have also the shared libraries,
On Thu, 7 Mar 2024 09:30:41 GMT, Alan Bateman wrote:
>> Jan Lahoda has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/native-access-modules1' into
>> native-access-modules1
>> - Reflecting review
> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
> automatically granted the native access. I am working on an upgrade of JLine
> inside the `jdk.internal.le` module, and I would like to replace the current
> native bindings with FFM-based bindings (which are now
OK. I didn’t follow exactly what you’re doing. So I don’t know what would be
extra. I also assume it wouldn’t address any other architecture specific parts
of the jdk that you mentioned.
How are you planning on replacing the executables and getting valid signed
applications? I think it could
On Wed, 6 Mar 2024 21:16:25 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
That could be done, but it would require more work with no obvious benefit.
Only the Java launcher needs to be universal from the perspective of the OS.
> On Mar 7, 2024, at 1:24 PM, Michael Hall wrote:
>
> Not directly in response to your prior. But curious, are you doing something
> like
On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato wrote:
> A simple doc update to include a leap day example in the `Calendar` class.
Marked as reviewed by jlu (Committer).
-
PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923601796
Not directly in response to your prior. But curious, are you doing something
like described here?
https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary
If not why not?
It indicates
> For universal binaries, the system prefers to execute the slice that is
>
On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato wrote:
> A simple doc update to include a leap day example in the `Calendar` class.
Marked as reviewed by lancea (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923575615
On Sat, 3 Feb 2024 17:28:29 GMT, Eirik Bjørsnøs wrote:
>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes`
>> to `ZipEntry.externalAttributes`.
>>
>> This field was introduced in
>> [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under
>> the
On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato wrote:
> A simple doc update to include a leap day example in the `Calendar` class.
Marked as reviewed by joehw (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923559732
On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato wrote:
> A simple doc update to include a leap day example in the `Calendar` class.
Looks good.
-
Marked as reviewed by bpb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923550002
On Thu, 7 Mar 2024 16:47:01 GMT, SendaoYan wrote:
> The DATE_FORMAT_PATTERN is set to "EEE MMM dd HH:mm:ss zzz ", is the time
> format of US. So, creates a formatter should using Locale.US, rather than
> Locale.ROOT, which means empty.
Thanks for the fix. Although setting `Locale.US` to
On Thu, 7 Mar 2024 06:50:04 GMT, David Holmes wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> more alignment
>
> src/hotspot/share/cds/cdsConfig.cpp line 2:
>
>> 1: /*
>> 2: * Copyright (c) 2024, Oracle and/or its
> A few clean ups:
>
> 1. Rename functions like "`s_loading_full_module_graph()` to
> `is_using_full_module_graph()`. The meaning of "loading" is not clear: it
> might be interpreted as to cover only the period where the artifact is being
> loaded, but not the period after the artifact is
On Thu, Mar 7, 2024 at 2:20 PM Louis Bergelson wrote:
> >> `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
On Mon, 5 Feb 2024 23:53:06 GMT, Archie Cobbs wrote:
>> `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
On Thu, 7 Mar 2024 19:44:11 GMT, Roger Riggs wrote:
>> Elif Aslan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add args[0] back
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 56:
>
>> 54: public static void
On Thu, 7 Mar 2024 17:13:12 GMT, Elif Aslan wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
A simple doc update to include a leap day example in the `Calendar` class.
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/18158/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=18158=00
Issue: https://bugs.openjdk.org/browse/JDK-8327167
Stats:
On Tue, 5 Mar 2024 17:56:21 GMT, Roger Riggs wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
On Thu, 7 Mar 2024 17:13:12 GMT, Elif Aslan wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
As mentioned in a previous message, I am creating universal macOS bundled
applications by including two Java runtimes in the application bundle, one for
arm and one for x86. The primary disadvantage of universal applications is
their size. For Java applications, there is an obvious opportunity
On Tue, 5 Mar 2024 17:56:21 GMT, Roger Riggs wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
On Wed, 6 Mar 2024 14:42:09 GMT, Aleksei Efimov wrote:
>> Christoph Langer 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 10 additional
>>
On Mon, 4 Mar 2024 15:02:45 GMT, Aleksei Efimov wrote:
> > Thanks for exploring the possibility of improving tracebility of test
> > invocations to reported bugs.
> > >
>
> I've given this test change a second thought, maybe you can try to separate
> the test into two separate test classes?
On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Thu, 7 Mar 2024 17:13:12 GMT, Elif Aslan wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
> This change is intended to address the segmentation fault issue that occurs
> when jspawnhelper is called without arguments,.
> There is a new test added to verify the behavior in such cases.
>
> `[ec2-user@ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test
>
> This change is intended to address the segmentation fault issue that occurs
> when jspawnhelper is called without arguments,.
> There is a new test added to verify the behavior in such cases.
>
> `[ec2-user@ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test
>
The DATE_FORMAT_PATTERN is set to "EEE MMM dd HH:mm:ss zzz ", is the time
format of US. So, creates a formatter should using Locale.US, rather than
Locale.ROOT, which means empty.
-
Commit messages:
- 8327486: java/util/Properties/PropertiesStoreTest.java fails "Text 'xxx'
> This change is intended to address the segmentation fault issue that occurs
> when jspawnhelper is called without arguments,.
> There is a new test added to verify the behavior in such cases.
>
> `[ec2-user@ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test
>
On Thu, 7 Mar 2024 16:29:12 GMT, Elif Aslan wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
On Thu, 7 Mar 2024 16:33:11 GMT, Elif Aslan wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
> This change is intended to address the segmentation fault issue that occurs
> when jspawnhelper is called without arguments, and it includes an updated
> test to verify the behavior in such cases.
>
> Existing tests passes since it does not check behavior without args.
> After test update the
> This change is intended to address the segmentation fault issue that occurs
> when jspawnhelper is called without arguments, and it includes an updated
> test to verify the behavior in such cases.
>
> Existing tests passes since it does not check behavior without args.
> After test update the
> This change is intended to address the segmentation fault issue that occurs
> when jspawnhelper is called without arguments, and it includes an updated
> test to verify the behavior in such cases.
>
> Existing tests passes since it does not check behavior without args.
> After test update the
> `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
Further adding on, here is my final implementation. The folks on Code
Review also informed me, in no uncertain terms, that it was a very
problematic solution. And I agree with them. However, for all of its flaws,
at least it cannot leak due to user's forgetting a TWR.
On Tue, 3 Oct 2023 06:19:11 GMT, Shaojin Wen wrote:
> Currently FormatItem uses MethodHandler to handle latin1 and utf16, which is
> not readable. This PR uses direct calls instead of MethodHandler.
>
> Please review and don't hesitate to critique my approach and patch.
It’s `MethodHandle`,
On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Thu, 7 Mar 2024 10:15:51 GMT, Jaikiran Pai wrote:
>> As an intermediate fix to the test, switching to explicit usage of an
>> ExecutorService seems to do the trick to make this test reliably pass.
>>
>> With that said, this test (CHM::ToArray.java) seems to trigger an issue in
>>
On Thu, 7 Mar 2024 10:20:55 GMT, Viktor Klang wrote:
>> As an intermediate fix to the test, switching to explicit usage of an
>> ExecutorService seems to do the trick to make this test reliably pass.
>>
>> With that said, this test (CHM::ToArray.java) seems to trigger an issue in
>>
On Tue, 27 Feb 2024 10:30:44 GMT, Viktor Klang wrote:
> As an intermediate fix to the test, switching to explicit usage of an
> ExecutorService seems to do the trick to make this test reliably pass.
>
> With that said, this test (CHM::ToArray.java) seems to trigger an issue in
> ForkJoinPool,
> As an intermediate fix to the test, switching to explicit usage of an
> ExecutorService seems to do the trick to make this test reliably pass.
>
> With that said, this test (CHM::ToArray.java) seems to trigger an issue in
> ForkJoinPool, so that would need to be fixed separately.
>
> Tagging
On Thu, 7 Mar 2024 10:15:51 GMT, Jaikiran Pai wrote:
>> As an intermediate fix to the test, switching to explicit usage of an
>> ExecutorService seems to do the trick to make this test reliably pass.
>>
>> With that said, this test (CHM::ToArray.java) seems to trigger an issue in
>>
On Tue, 5 Mar 2024 19:53:46 GMT, Weijun Wang wrote:
>> Subject is stored in the RMIConnectionImpl:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>>
>> (That is complicated by SubjectDelegation, which we deprecated for removal.
>> I have the PR
On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Wed, 6 Mar 2024 22:58:54 GMT, Viktor Klang wrote:
> The common ForkJoinPool creating threads as a result of submitting tasks is
> preventing class unloading when the thread construction is initiated from a
> class loaded in a separate classloader. This fix avoids that when no
>
On Wed, 6 Mar 2024 21:16:25 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Wed, 6 Mar 2024 21:22:40 GMT, Jan Lahoda wrote:
>> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line
>> 812:
>>
>>> 810: }
>>> 811:
>>> 812: private static void addEnableNativeAccess(ModuleLayer layer,
>>> Set moduleNames, boolean shouldWarn) {
>>
>> The
On Thu, 7 Mar 2024 08:08:45 GMT, Alan Bateman wrote:
> Latest version looks good to me. As have been pointed out, there at least 2
> files where the copyright header was updated but there are no changes, I
> assume left over from previous iterations. I assume the RESTARTABLE-close in
>
On Wed, 6 Mar 2024 22:58:54 GMT, Viktor Klang wrote:
> The common ForkJoinPool creating threads as a result of submitting tasks is
> preventing class unloading when the thread construction is initiated from a
> class loaded in a separate classloader. This fix avoids that when no
>
On Wed, 6 Mar 2024 17:16:03 GMT, Christoph Langer wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust COPYRIGHT year info
>
> src/java.base/unix/native/libjava/childproc.h line 75:
>
>> 73: #define
> We define the RESTARTABLE macro again and again at a lot of places in the JDK
> native codebase. This could be centralized to avoid repeating it again and
> again !
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
adjust
On Wed, 6 Mar 2024 17:14:25 GMT, Christoph Langer wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Introduce windows jni_util_md.h
>
> src/java.base/share/native/libjava/jni_util.h line 30:
>
>> 28:
>> 29:
On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
68 matches
Mail list logo
