On Tue, 5 Mar 2024 14:19:14 GMT, Erik Joelsson wrote:
> Does the release note also looks ok?
Yes.
> Is there any process to formally review release notes?
No. Typically just add a comment to the RN sub-task indicating it is okay. My
comment, that I had made some minor changes was meant as an
> `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
On Fri, 15 Dec 2023 12:54:27 GMT, Adam Sotona wrote:
> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
>
> This patch converts it to use Classfile API.
>
> It is continuation of https://github.com/openjdk/jdk/pull/10991
>
> Any comments and suggestions are
On Mon, 2 Oct 2023 23:05:29 GMT, Shaojin Wen wrote:
> In the current version, FMT."v =%d{1}" will call the
> StringConcatHelper.prepend(long/byte[]/long) method, which should behave the
> same as STR."v ={1}". Call StringConcatHelper.prepend(long/byte[]/int),
> should not convert int to long
On Wed, 4 Oct 2023 22:30:42 GMT, Shaojin Wen wrote:
> # Goal
> Improve String Template FMT's processing performance of date types.
> Currently, FMT processes date types by toString and then calls
> j.u.Formatter#print. Because there is less parse processing than
> String.format, the
# Goal
Improve String Template FMT's processing performance of date types. Currently,
FMT processes date types by toString and then calls j.u.Formatter#print.
Because there is less parse processing than String.format, the performance is
improved, but it is still not good enough. There is an
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.
-
Commit messages:
- Merge remote-tracking branch 'upstream/master'
> On Mar 5, 2024, at 4:42 PM, Michael Hall wrote:
>
> What happens if Apple changes the file format and InstallJ isn’t actively
> supporting this anymore and doesn’t change their code. Your builds could stop
> working. Have you tried it to be sure it even works now?
If Apple changes the
On Wed, 6 Mar 2024 01:58:26 GMT, Ioi Lam wrote:
>> I meant the following. Just the last line #94 needs to be changed - shift
>> one space to the left after `bool`.
>>
>> static bool is_dumping_heap()
>> NOT_CDS_JAVA_HEAP_RETURN_(false);
>> static void
On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich wrote:
> The various Zip/Jar-file related Java APIs have some long-standing
> differences or peculiarities with respect to the ZIP-file specification or
> compared to other implementations which should be documented in the API-doc.
> This
On Tue, 5 Mar 2024 23:49:02 GMT, Calvin Cheung wrote:
>> Do you mean aligning like this:
>>
>>
>> static bool is_dumping_heap()
>> NOT_CDS_JAVA_HEAP_RETURN_(false);
>> static void stop_dumping_full_module_graph(const char* reason = nullptr)
>>
Fwiw screenshots
DMG with a customized background image (SceneBuilder demo)
http://mikehall.pairserver.com/custom_dmg.png
DMG with extra files. Default layout and background image.
http://mikehall.pairserver.com/additional_dmg.png
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 the
On Tue, 5 Mar 2024 16:13:14 GMT, Jan Lahoda wrote:
>> I see. I then misunderstood a part of the PR description.
>
> I believe we could technically reuse the list for boot/platform modules. But,
> the intent here is to provide more control over the modules with native
> access, not only being
> On Mar 5, 2024, at 4:31 PM, Michael Hall wrote:
>
> I’m not sure hacking the .DS_Store file would be Apple supported.
>
Is that what they are doing? I couldn’t tell from the web site.
> Is install4j still actively supporting this or is this something they used to
> do?
>
All I know
I’m not sure hacking the .DS_Store file would be Apple supported.
Is install4j still actively supporting this or is this something they used to
do?
What happens if they stop?
The result of my bug report included the icons being resized to fit better with
multiple files.
I think Alexander’s
Great, you can file a CR, publish a PR. I'll be happy to review it.
- Alexey
On 3/5/2024 7:19 PM, Alan Snyder wrote:
Yes, I do. The changes are very small.
On Mar 5, 2024, at 3:48 PM, Alexey Semenyuk wrote:
On 2/29/2024 2:22 PM, Alan Snyder wrote:
For anyone interested in building
On Tue, 5 Mar 2024 23:38:21 GMT, Ioi Lam wrote:
>> src/hotspot/share/cds/cdsConfig.hpp line 94:
>>
>>> 92: static bool is_dumping_full_module_graph() { return
>>> CDS_ONLY(_is_dumping_full_module_graph) NOT_CDS(false); }
>>> 93: static void
On 2/29/2024 2:22 PM, Alan Snyder wrote:
For anyone interested in building Java-based macOS universal
applications, it is possible to create a bundled application that
contains two Java runtimes, one for x86 and one for arm. A custom
launcher is required to select the appropriate runtime based
On Tue, 5 Mar 2024 20:39:10 GMT, Calvin Cheung 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
The vote for Viktor Klang [1] is now closed.
Yes: 9
Veto: 0
Abstain: 0
According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.
s'marks
[1] https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119401.html
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)
These deprecated methods were added to make jsr166.jar to run on
different JDK releases. I think it's time to remove these deprecated
xxxObject* methods as the renames have been done since JDK 12 for 5
years. I added a comment [1] to confirm with Doug and Martin.
Mandy
On Tue, 5 Mar 2024 18:43:44 GMT, Alan Bateman wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Apply suggestions from code review
>>
>> Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
>>
On Wed, 14 Feb 2024 22:29:07 GMT, Justin Lu wrote:
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756)
> which defines the behavior for creating ChoiceFormats with incorrect
> patterns. The wording is added to both the ChoiceFormat constructor and
>
Hi Alan,
jpackage does not use .DS_Store file directly. Script tells “Finder”
application to arrange DMG layout and once script is finished “Finder” will
create .DS_Store file to store layout.
If user wants to modify it, them generated DMG needs to be converted to
writable, mounted, layout
On Tue, 5 Mar 2024 21:27:09 GMT, Justin Lu wrote:
>> Please review this PR and corresponding CSR which prevents an
>> OutOfMemoryError by restricting the initial maximum fraction digits for an
>> empty pattern DecimalFormat.
>>
>> For an empty String pattern DecimalFormat, the maximum
> Please review this PR and corresponding CSR which prevents an
> OutOfMemoryError by restricting the initial maximum fraction digits for an
> empty pattern DecimalFormat.
>
> For an empty String pattern DecimalFormat, the maximum fraction digits is
> initialized to `Integer.MAX_VALUE`. When
On Tue, 5 Mar 2024 20:23:56 GMT, Jim Laskey wrote:
>> Currently, add is returning intern(e) == null which will always be false.
>> The correct test is intern(e) == e , that is, true when element is newly
>> added.
>
> Jim Laskey has updated the pull request incrementally with one additional
>
On Tue, 5 Mar 2024 21:23:48 GMT, Justin Lu wrote:
>> test/jdk/java/text/Format/DecimalFormat/ToPatternTest.java line 60:
>>
>>> 58: dFmt.setMinimumFractionDigits(minFrac);
>>> 59:
>>> 60: String[] patterns = dFmt.toPattern().split("\\.");
>>
>> Instead of assuming/hardcoding
On Tue, 5 Mar 2024 19:10:19 GMT, Naoto Sato wrote:
>> Justin Lu 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 commits
>>
> Please review this PR and corresponding CSR which prevents an
> OutOfMemoryError by restricting the initial maximum fraction digits for an
> empty pattern DecimalFormat.
>
> For an empty String pattern DecimalFormat, the maximum fraction digits is
> initialized to `Integer.MAX_VALUE`. When
On Tue, 5 Mar 2024 20:23:56 GMT, Jim Laskey wrote:
>> Currently, add is returning intern(e) == null which will always be false.
>> The correct test is intern(e) == e , that is, true when element is newly
>> added.
>
> Jim Laskey has updated the pull request incrementally with one additional
>
On Sat, 2 Mar 2024 01:18:06 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
>
On Tue, 5 Mar 2024 10:39:31 GMT, Aleksey Shipilev wrote:
> The change in jspawnhelper looks good.
>
> I think it would be simpler to have a separate
> `jdk/java/lang/ProcessBuilder/JspawnhelperMisuse.java` test that simply
> invokes the `jspawnhelper` and verifies the proper message is
On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson wrote:
> Executables and dynamic libraries on Linux can encode a search path that the
> dynamic linker will use when looking up library dependencies, generally
> referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to
> set
On Sun, 11 Feb 2024 17:41:14 GMT, ExE Boss wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update ReferencedKeyTest.java
>
> src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 151:
>
>> 149:
> Currently, add is returning intern(e) == null which will always be false. The
> correct test is intern(e) == e , that is, true when element is newly added.
Jim Laskey has updated the pull request incrementally with one additional
commit since the last revision:
Fix ReferencedKeySet::add
> This code change adds an alternative implementation of user-based
> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
> Depending on if the Security Manager is allowed, the methods store the
> current subject differently. See the spec change in the `Subject.java` file
On Tue, 5 Mar 2024 16:49:01 GMT, Kevin Walls wrote:
>> Do you know where the subject is set? If it's set by a `doAs` call then it
>> will co-operate with `current()` no matter if SM is allowed. I tried to
>> search in the whole module and cannot find a `doAs` call. If it is also
>> through
On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato wrote:
> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
> `COMPAT` locale data was introduced for applications' migratory purposes
> transitioning to `CLDR`. It is becoming a technical debt and now is the time
> to
On Tue, 5 Mar 2024 00:32:47 GMT, Justin Lu wrote:
>> Please review this PR and corresponding CSR which prevents an
>> OutOfMemoryError by restricting the initial maximum fraction digits for an
>> empty pattern DecimalFormat.
>>
>> For an empty String pattern DecimalFormat, the maximum
On Tue, 5 Mar 2024 17:56:21 GMT, Roger Riggs wrote:
> I'm curious why this test is requires `vm.debug`? That means it generally
> won't get run on release builds.
This is due to the tests of the crash scenarios that are guarded with #ifdef
DEBUG in jspawnhelper.
Moving the test in the
On Tue, 5 Mar 2024 12:44:10 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 Tue, 5 Mar 2024 17:26:11 GMT, Naoto Sato wrote:
>> Fixing test cases. For bad test cases, only the first case was run, and the
>> rest were ignored.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reflects review
On Tue, 5 Mar 2024 17:26:11 GMT, Naoto Sato wrote:
>> Fixing test cases. For bad test cases, only the first case was run, and the
>> rest were ignored.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reflects review
On Tue, 5 Mar 2024 17:26:11 GMT, Naoto Sato wrote:
>> Fixing test cases. For bad test cases, only the first case was run, and the
>> rest were ignored.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reflects review
On Tue, 5 Mar 2024 17:50:09 GMT, Naoto Sato wrote:
>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
>> `COMPAT` locale data was introduced for applications' migratory purposes
>> transitioning to `CLDR`. It is becoming a technical debt and now is the time
>> to
Hi,
Now that the JDK repo is the single source of truth for
java.util.concurrent [1], I'm wondering if time has come to remove the
deprecated *Object* methods introduced in JDK-8213043 [2]
These alias methods were introduced because jsr166 used them, but there no
longer seems to be any use
On Mon, 4 Mar 2024 23:54:38 GMT, Vladimir Petko wrote:
>> test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 111:
>>
>>> 109: if (p.exitValue() != 1)
>>> 110: System.exit(ERROR + 2);
>>> 111: System.exit(0);
>>
>> Its bad form to System.exit from not
On Mon, 4 Mar 2024 21:19:26 GMT, Elif Aslan wrote:
> 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
On Tue, 5 Mar 2024 06:44:52 GMT, Joe Wang wrote:
>> Naoto Sato 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 44 additional
>> commits since
On Tue, 5 Mar 2024 17:26:11 GMT, Naoto Sato wrote:
>> Fixing test cases. For bad test cases, only the first case was run, and the
>> rest were ignored.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reflects review
> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
> `COMPAT` locale data was introduced for applications' migratory purposes
> transitioning to `CLDR`. It is becoming a technical debt and now is the time
> to remove it (we've been emitting a warning at JVM startup
On Tue, 5 Mar 2024 00:51:33 GMT, Naoto Sato wrote:
> Fixing test cases. For bad test cases, only the first case was run, and the
> rest were ignored.
Thanks for the reviews. Updated as suggested
-
PR Comment: https://git.openjdk.org/jdk/pull/18113#issuecomment-1979271823
> Fixing test cases. For bad test cases, only the first case was run, and the
> rest were ignored.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Reflects review comments
-
Changes:
- all:
On Tue, 5 Mar 2024 14:44:29 GMT, Weijun Wang wrote:
>> Right, this does not depend on the SM. All we need to do is get the
>> Subject.
>> This method implements the basic monitor (readonly) and control (readwrite)
>> access.
>> accessMap maps identity String to Access, and the checkAccess()
I’m wondering whether some developers might prefer to arrange the DMG layout by
hand.
That would require jpackage to use a .DS_Store file provided by the developer
and not running the script.
The issue is whether a .DS_Store file created using a previous DMG would work
in a new DMG.
The
On Tue, 5 Mar 2024 14:14:15 GMT, Jaikiran Pai wrote:
>>> to make the intention clear as well as reduce the chances of missing some
>>> boot or platform module in this NATIVE_ACCESS_MODULES?
>>
>> The list to be be granted native access is a subset, it shouldn't be granted
>> all modules
On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote:
> Hi all,
>
> Please review this fix for jar tool not producing an archive if there is a
> missing file supplied.
> The current behaviour will recognise missing files as an error but continue
> processing,
> creating a temporary archive
> This code change adds an alternative implementation of user-based
> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
> Depending on if the Security Manager is allowed, the methods store the
> current subject differently. See the spec change in the `Subject.java` file
On Tue, 5 Mar 2024 11:36:53 GMT, Kevin Walls wrote:
>> I think we need @kevinjwalls or @dfuch to help advise on this.
>
> Right, this does not depend on the SM. All we need to do is get the Subject.
> This method implements the basic monitor (readonly) and control (readwrite)
> access.
>
On Mon, 4 Mar 2024 23:44:14 GMT, Erik Joelsson wrote:
>> Executables and dynamic libraries on Linux can encode a search path that the
>> dynamic linker will use when looking up library dependencies, generally
>> referred to as an "rpath". In the JDK we use this with the $ORIGIN feature
>> to
On Tue, 5 Mar 2024 07:16:10 GMT, David Holmes wrote:
> Thanks for the further explanation and adding the comment.
>
> LGTM.
Thanks! Does the release note also looks ok? I understand it needs to be
reviewed together with the PR.
-
PR Comment:
On Tue, 5 Mar 2024 00:51:33 GMT, Naoto Sato wrote:
> Fixing test cases. For bad test cases, only the first case was run, and the
> rest were ignored.
Looks good.
Only a trivial suggestion.
test/jdk/java/lang/Double/ParseDouble.java line 564:
> 562: check(input[i]);
> 563:
On Tue, 5 Mar 2024 14:01:55 GMT, Alan Bateman wrote:
>> make/conf/module-loader-map.conf line 95:
>>
>>> 93: #
>>> 94:
>>> 95: NATIVE_ACCESS_MODULES= \
>>
>> Hello Jan, does this make configuration allow for something like:
>>
>>
>> NATIVE_ACCESS_MODULES= ${BOOT_MODULES} \
>>
On Tue, 5 Mar 2024 12:44:10 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 Tue, 5 Mar 2024 13:42:32 GMT, Jaikiran Pai wrote:
> to make the intention clear as well as reduce the chances of missing some
> boot or platform module in this NATIVE_ACCESS_MODULES?
The list to be be granted native access is a subset, it shouldn't be granted
all modules mapped to the boot
On Tue, 5 Mar 2024 12:44:10 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 Mon, 26 Feb 2024 13:24:11 GMT, Jorn Vernee wrote:
> This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8,
> regardless of the underlying platform. This means that atomic access modes
> work on memory segments wrapping `long[]` or `double[]`, as they already do
> when
On Mon, 4 Mar 2024 17:27:26 GMT, Alan Bateman wrote:
> It's a bit unusual to have the final modifier on static methods, looks like
> it goes back to JDK 1.1 at least, not clear if it was intentional.
Right, I was asked by JCK folks to either file a CSR to have the change
recorded, or revert.
On Mon, 4 Mar 2024 13:55:15 GMT, Claes Redestad wrote:
> [JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally
> removed `final` from the `static final DataInputStream.readUTF` method. This
> has a minor compatibility impact (allows hiding the method in a subclass,
> while
> 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
On Tue, 5 Mar 2024 12:41:18 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 Mon, 4 Mar 2024 13:55:15 GMT, Claes Redestad wrote:
> [JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally
> removed `final` from the `static final DataInputStream.readUTF` method. This
> has a minor compatibility impact (allows hiding the method in a subclass,
> while
On Tue, 5 Mar 2024 00:15:10 GMT, Justin Lu wrote:
> For clarification, this is entirely a bug with DecimalFormat, not
> StringBuilder. An empty String pattern DecimalFormat sets the maximum
> fraction digits to Integer.MAX_VALUE. When toPattern() is invoked, the local
> StringBuilder will
On Mon, 4 Mar 2024 19:57:25 GMT, Sean Mullan wrote:
>> I was not exactly sure if we will support this functionality when there is
>> no SM. The class name has `AccessControler` and the method names use
>> `checkAccess`, but they actually do not always depend on security manager.
>
> I think we
On Mon, 4 Mar 2024 21:19:26 GMT, Elif Aslan wrote:
> 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
On Tue, 16 Jan 2024 10:19:44 GMT, Andrey Turbanov wrote:
> There are 3 methods in `java.util.TimeZone` which are `public static` and
> marked as `synchronized`:
> 1. getTimeZone(String)
> 2. getAvailableIDs(int)
> 3. getAvailableIDs()
>
> This means it is a bottle neck for the whole VM.
> I've
On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which suggests we remove the package-private,
> unused and deprecated method `java.util.jar.Manifest.make72Safe`.
>
> This method was marked deprecated after a cleanup/refactoring in
>
On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which suggests we remove the package-private,
> unused and deprecated method `java.util.jar.Manifest.make72Safe`.
>
> This method was marked deprecated after a cleanup/refactoring in
>
Hello Alexander,
I had forgotten or didn’t know that. I didn’t see it mentioned anywhere in this
list thread previously. But there is generally no reason to delete this file.
Unless you don’t want it included in a zip or a GitHub project. The icon
placement for multiple files with jpackage
82 matches
Mail list logo
