On Sat, 23 Nov 2024 13:41:24 GMT, Piotr Tarsa wrote:
> Could you add some code that disables the AVX512 version on Zen4, but keeps
> it enabled on Zen5 and future Zen architectures?
Or as you suggest
[here](https://github.com/intel/x86-simd-sort/issues/6#issuecomment-2506476505)
revert to AVX
> Can I please get a review of this change which proposes to address
> https://bugs.openjdk.org/browse/JDK-8341551?
>
> The primary work in this PR is the specification of the previously existing
> `sun.misc.URLClassPath.disableJarChecking` system property and how the
> internal implementation
On Tue, 3 Dec 2024 19:59:56 GMT, Henry Jen wrote:
> Improving option value handling to support passing argument value starts with
> "--".
>
> Before the fix, in following example, --add-modules will be considered as
> another option for JLink instead of argument value for --add-options.
> --ad
On Wed, 4 Dec 2024 10:21:57 GMT, Raffaello Giulietti
wrote:
>> `jdk.internal.math.FloatingDecimal` parsing is mostly exercised on inputs
>> produced by `Float.toString` and `Double.toString`, but should be extended
>> on more random inputs.
>
> Raffaello Giulietti has updated the pull request
On Thu, 5 Dec 2024 04:38:04 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8341551?
>>
>> The primary work in this PR is the specification of the previously existing
>> `sun.misc.URLClassPath.disableJarChec
On Wed, 4 Dec 2024 05:53:22 GMT, Tom Rodriguez wrote:
>> The notification that finalize is complete should be done after printing the
>> message because in Xcomp mode there might be a significant delay at the
>> println so the object hasn't actually been finalized yet.
>
> Tom Rodriguez has upd
On Tue, 29 Oct 2024 16:52:45 GMT, Tom Rodriguez wrote:
> The notification that finalize is complete should be done after printing the
> message because in Xcomp mode there might be a significant delay at the
> println so the object hasn't actually been finalized yet.
This pull request has now
This PR proposes to fix a performance regression (on x64 platforms) for
quad-string words introduced by
[JDK-8345120](https://bugs.openjdk.org/browse/JDK-8345120).
The PR also fixes a performance regression in the benchmarks caused by using
the wrong type for `MemorySegment`.
Regrettably, this
On Tue, 3 Dec 2024 06:12:13 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which removes usages of
>> SecurityManager related APIs and some leftover related to SecurityManager
>> changes?
>>
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these
>>
On Tue, 3 Dec 2024 09:03:20 GMT, Jaikiran Pai wrote:
> Although trivial, there are some changes to files from the serviceability
> area. So it would be good if someone from that area could review this too.
Yes, looks good. I will update https://github.com/openjdk/jdk/pull/22478 to
avoid the c
On Mon, 2 Dec 2024 12:13:57 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which removes usages of
> SecurityManager related APIs and some leftover related to SecurityManager
> changes?
>
> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these
> change
On Tue, 3 Dec 2024 06:12:13 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which removes usages of
>> SecurityManager related APIs and some leftover related to SecurityManager
>> changes?
>>
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these
>>
On Thu, 28 Nov 2024 18:22:24 GMT, Aleksey Shipilev wrote:
> Found this while cleaning up x86_32 code for removal.
>
> In our current code there is a block added by
> [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373):
> https://github.com/openjdk/jdk/blob/3b21a298c29d88720f6bfb2dc1f3305
On Wed, 4 Dec 2024 09:31:14 GMT, Emanuel Peter wrote:
> Nice, that was quick! Do we not need to restrict the IR rules? Or will that
> not fail on `IA32`?
`IA32` is on its way out, so I would be okay with the new test to pretend
`IA32` does not exist :)
-
PR Comment: https://git.o
> Found this while cleaning up x86_32 code for removal.
>
> In our current code there is a block added by
> [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373):
> https://github.com/openjdk/jdk/blob/3b21a298c29d88720f6bfb2dc1f3305b6a3db307/src/hotspot/share/compiler/compileBroker.cpp#L1451
> Found this while cleaning up x86_32 code for removal.
>
> In our current code there is a block added by
> [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373):
> https://github.com/openjdk/jdk/blob/3b21a298c29d88720f6bfb2dc1f3305b6a3db307/src/hotspot/share/compiler/compileBroker.cpp#L1451
> Please review this follow-up PR to improve `java`'s manpage section about
> wildcards in argument files: the confusing sentence is now removed.
>
> This is a cleanup of commit
> https://github.com/openjdk/jdk/commit/5cb0d438231383d491b2fcca455d09af7f2ee016
Christian Stein has updated the pull
On Wed, 4 Dec 2024 01:51:06 GMT, David Holmes wrote:
>> Christian Stein has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update java.md
>>
>> [skip ci]
>
> src/java.base/share/man/java.md line 3077:
>
>> 3075:
>> 3076: - The laun
> `jdk.internal.math.FloatingDecimal` parsing is mostly exercised on inputs
> produced by `Float.toString` and `Double.toString`, but should be extended on
> more random inputs.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
On Wed, 4 Dec 2024 10:04:17 GMT, Christian Stein wrote:
>> Please review this follow-up PR to improve `java`'s manpage section about
>> wildcards in argument files: the confusing sentence is now removed.
>>
>> This is a cleanup of commit
>> https://github.com/openjdk/jdk/commit/5cb0d438231383d
> `jdk.internal.math.FloatingDecimal` parsing is mostly exercised on inputs
> produced by `Float.toString` and `Double.toString`, but should be extended on
> more random inputs.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
On Wed, 4 Dec 2024 00:29:00 GMT, Chen Liang wrote:
>> `jdk.internal.math.FloatingDecimal` parsing is mostly exercised on inputs
>> produced by `Float.toString` and `Double.toString`, but should be extended
>> on more random inputs.
>
> test/jdk/jdk/internal/math/FloatingDecimal/TestRandomFloati
On Wed, 4 Dec 2024 07:17:55 GMT, Aleksey Shipilev wrote:
> > One question: Could we add an IR test that would show that no interpreter
> > stubs are emitted, but instead whatever it is now emitting?
>
> We could, but let's not do this in this PR. I already jumped the gun here a
> little with a
On Tue, 3 Dec 2024 07:31:14 GMT, Aleksey Shipilev wrote:
>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc
>> linked list with segmented list of arrays. Arrays are easy targets for GC.
>> There are possible improvements here, most glaring is parallelism that is
>>
On Tue, 12 Nov 2024 16:00:39 GMT, Aleksey Shipilev wrote:
> See the bug for more discussion and reproducer. This PR replaces the ad-hoc
> linked list with segmented list of arrays. Arrays are easy targets for GC.
> There are possible improvements here, most glaring is parallelism that is
> cur
On Wed, 13 Nov 2024 16:08:44 GMT, Christian Stein wrote:
>> Please review this change for the `jar` tool to gracefully handle the case
>> where `--release` is not specified as the last arguments.
>>
>> Prior to this commit, operation modes `-d --describe-module` and
>> `--validate` expected to
On Tue, 3 Dec 2024 23:42:34 GMT, Erik Gahlin wrote:
>> @egahlin The updated PR proposes two duration events: jdk.SocketConnect for
>> when a connection is established, and jdk.SocketConnectFailed for when a
>> connection cannot be established. Naming aside, it seems that would allow
>> the jfr
> Use the built-in file system provider rather than the custom file system
> provider.
> Add "public static FileSystemProvider create" method in
> DefaultFileSystemProvider which is from java8API to be compatible against
> runtime.
jyxzwd has updated the pull request with a new target base due
On Tue, 3 Dec 2024 14:38:59 GMT, Per Minborg wrote:
>> This PR proposes to correct errors in the `MemorySegment::getString`
>> documentation.
>>
>> There is a test in
>> https://github.com/openjdk/jdk/pull/22451/files#diff-13a3535a65f1e0664e98bd2584196eb9d9a0ada951fd2dabfac8a484263235d8R271
>>
On Wed, 4 Dec 2024 09:42:59 GMT, Aleksey Shipilev wrote:
>> Found this while cleaning up x86_32 code for removal.
>>
>> In our current code there is a block added by
>> [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373):
>> https://github.com/openjdk/jdk/blob/3b21a298c29d88720f6bfb2dc1f
On Tue, 3 Dec 2024 14:38:59 GMT, Per Minborg wrote:
>> This PR proposes to correct errors in the `MemorySegment::getString`
>> documentation.
>>
>> There is a test in
>> https://github.com/openjdk/jdk/pull/22451/files#diff-13a3535a65f1e0664e98bd2584196eb9d9a0ada951fd2dabfac8a484263235d8R271
>>
Accommodate compensations when checking for missed signals; add a better test
for this.
-
Commit messages:
- test starvation with monitors
- Accommodate uncompensates in deactivate
Changes: https://git.openjdk.org/jdk/pull/22543/files
Webrev: https://webrevs.openjdk.org/?repo=jd
On Mon, 2 Dec 2024 14:08:14 GMT, Per Minborg wrote:
> This PR proposes to correct errors in the `MemorySegment::getString`
> documentation.
>
> There is a test in
> https://github.com/openjdk/jdk/pull/22451/files#diff-13a3535a65f1e0664e98bd2584196eb9d9a0ada951fd2dabfac8a484263235d8R271
> that
On Wed, 4 Dec 2024 08:40:31 GMT, Per Minborg wrote:
> This PR proposes to fix a performance regression (on x64 platforms) for
> quad-string words introduced by
> [JDK-8345120](https://bugs.openjdk.org/browse/JDK-8345120).
>
> The PR also fixes a performance regression in the benchmarks caused
On Wed, 4 Dec 2024 14:14:10 GMT, Jorn Vernee wrote:
> What are 'quad-string words'? FWIW, the word 'word' is somewhat ambiguous
> (although most people seem to interpret it as the size of an address), so you
> might want to specify in terms of bits/bytes instead.
Agreed. I've updated to "32-bi
Can I please get a review of this change which proposes to address
https://bugs.openjdk.org/browse/JDK-8341551?
The primary work in this PR is the specification of the previously existing
`sun.misc.URLClassPath.disableJarChecking` system property and how the internal
implementation of `java.ne
Over the years there have been significant rounds of cleanup to try and keep
the classfile API as focussed and true to its underlying functional core as
possible. One of the side-effects of such cleanups was to move higher-level
functionalities from the root classfile API package `java.lang.clas
On Wed, 4 Dec 2024 14:23:07 GMT, Chen Liang wrote:
> Over the years there have been significant rounds of cleanup to try and keep
> the classfile API as focussed and true to its underlying functional core as
> possible. One of the side-effects of such cleanups was to move higher-level
> functi
Hi,
The OpenJDK includes many boolean flags in the form of system properties.
These toggle different behavior such as debug logging, verification,
caching, compatibility and conditional features.
A common interpretation is to evaluate a property as true if it is set and
either blank or equal to "
On Tue, 3 Dec 2024 03:10:51 GMT, Vladimir Kozlov wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disable IR tests on IA32
>
> This fix looks correct by looking on original changes.
>
> Yes, special Interprete
> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed
> up `BigDecimal.sqrt()` implementation. Here is how I made it.
>
> The main steps of the algorithm are as follows:
> first argument reduce the value to an integer using the following relations:
>
> x = y * 10 ^ exp
>
On Wed, 4 Dec 2024 14:06:38 GMT, Emanuel Peter wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disable IR tests on IA32
>
> test/hotspot/jtreg/compiler/c2/irTests/TestFPConversion.java line 33:
>
>> 31: * @su
> This PR proposes to fix a performance regression (on x64 platforms) for
> 32-bit strings introduced by
> [JDK-8345120](https://bugs.openjdk.org/browse/JDK-8345120).
>
> The PR also fixes a performance regression in the benchmarks caused by using
> the wrong type for `MemorySegment`.
>
> Regr
Hi all,
The file src/java.base/share/native/libjli/java.c generate false positive
compile warning by gcc14 with gcc options `-fsanitize=undefined -O2`, and make
jdk build error when configure with option `--enable-asan`. So I think it's
necessory to disable the false positive compile warning to
Hi Eirik,
Yes, its a long standing and inconsistent area of deferred maintenance.
Most of the individual cases are not used enough to warrant making the
(in many cases) incompatible change and breaking some
application/library somewhere.
Interesting, you did not mention Boolean.getBoolean(Str
On Wed, 4 Dec 2024 14:48:55 GMT, Aleksey Shipilev wrote:
>> test/hotspot/jtreg/compiler/c2/irTests/TestFPConversion.java line 33:
>>
>>> 31: * @summary Test that code generation for FP conversion works as
>>> intended
>>> 32: * @library /test/lib /
>>> 33: * @requires os.arch != "x86" & os.a
On Wed, 4 Dec 2024 14:03:58 GMT, Doug Lea wrote:
> Accommodate compensations when checking for missed signals; add a better test
> for this.
test/jdk/java/lang/Thread/virtual/Starvation.java line 1:
> 1: /* @test
Suggestion:
/*
* Copyright (c) 2024, Oracle and/or its affiliates. All rights
On Wed, 4 Dec 2024 14:57:22 GMT, SendaoYan wrote:
> Hi all,
> The file src/java.base/share/native/libjli/java.c generate false positive
> compile warning by gcc14 with gcc options `-fsanitize=undefined -O2`, and
> make jdk build error when configure with option `--enable-asan`. So I think
> i
The internal `ProtectionDomain.doIntersectionPrivilege` methods can be removed
as all dependencies have been removed in post JEP 486 cleanup issues.
-
Commit messages:
- Initial cleanup.
Changes: https://git.openjdk.org/jdk/pull/22548/files
Webrev: https://webrevs.openjdk.org/?re
> Can I please get a review of this change which proposes to address
> https://bugs.openjdk.org/browse/JDK-8341551?
>
> The primary work in this PR is the specification of the previously existing
> `sun.misc.URLClassPath.disableJarChecking` system property and how the
> internal implementation
On Wed, 4 Dec 2024 14:03:58 GMT, Doug Lea wrote:
> Accommodate compensations when checking for missed signals; add a better test
> for this.
Thanks for the fix, Doug, and thanks for the reproducer test, @AlanBateman!
Having a look at the patch now 👍
-
PR Comment: https://git.open
On Wed, 4 Dec 2024 15:40:21 GMT, Jaikiran Pai wrote:
> Hello @sendaoYan, what exact version of `gcc` is this?
Hi, the gcc version is gcc14.2.0
> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/yansendao/software/gcc/gcc-14.2.0-binary/bin/../libexec/gcc/x86_64-pc-linux-gn
On Wed, 4 Dec 2024 15:46:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8341551?
>>
>> The primary work in this PR is the specification of the previously existing
>> `sun.misc.URLClassPath.disableJarChec
On Wed, 4 Dec 2024 15:40:03 GMT, Sean Mullan wrote:
> The internal `ProtectionDomain.doIntersectionPrivilege` methods can be
> removed as all dependencies have been removed in post JEP 486 cleanup issues.
I see in `SharedSecrets` these 2 imports are useless. Not sure if you want to
take this c
On Wed, 4 Dec 2024 14:53:19 GMT, Daniel Fuchs wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> improve code comment
>
> test/jdk/jdk/internal/loader/URLClassPath/JarCheckTest.java line 60:
>
>> 58: * @run junit/ot
> The internal `ProtectionDomain.doIntersectionPrivilege` methods can be
> removed as all dependencies have been removed in post JEP 486 cleanup issues.
Sean Mullan has updated the pull request incrementally with one additional
commit since the last revision:
Remove unused imports.
-
On Wed, 4 Dec 2024 15:59:44 GMT, Sean Mullan wrote:
>> The internal `ProtectionDomain.doIntersectionPrivilege` methods can be
>> removed as all dependencies have been removed in post JEP 486 cleanup issues.
>
> Sean Mullan has updated the pull request incrementally with one additional
> commit
On Wed, 4 Dec 2024 15:53:37 GMT, Weijun Wang wrote:
> I see in `SharedSecrets` these 2 imports are useless. Not sure if you want to
> take this chance to remove them as well.
>
> ```
> import java.io.PrintStream;
> import java.io.PrintWriter;
> ```
Sure. Fixed.
-
PR Comment: http
On Wed, 4 Dec 2024 09:42:59 GMT, Aleksey Shipilev wrote:
>> Found this while cleaning up x86_32 code for removal.
>>
>> In our current code there is a block added by
>> [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373):
>> https://github.com/openjdk/jdk/blob/3b21a298c29d88720f6bfb2dc1f
On Wed, 4 Dec 2024 14:03:58 GMT, Doug Lea wrote:
> Accommodate compensations when checking for missed signals; add a better test
> for this.
src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2016:
> 2014: return awaitWork(w, p); // block, drop, or ex
> Hi all,
> The file src/java.base/share/native/libjli/java.c generate false positive
> compile warning by gcc14 with gcc options `-fsanitize=undefined -O2`, and
> make jdk build error when configure with option `--enable-asan`. So I think
> it's necessory to disable the false positive compile
On Wed, 4 Dec 2024 15:46:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8341551?
>>
>> The primary work in this PR is the specification of the previously existing
>> `sun.misc.URLClassPath.disableJarChec
On Wed, 4 Dec 2024 14:23:07 GMT, Chen Liang wrote:
> Over the years there have been significant rounds of cleanup to try and keep
> the classfile API as focussed and true to its underlying functional core as
> possible. One of the side-effects of such cleanups was to move higher-level
> functi
On Wed, 4 Dec 2024 15:58:41 GMT, Jaikiran Pai wrote:
>> test/jdk/jdk/internal/loader/URLClassPath/JarCheckTest.java line 60:
>>
>>> 58: * @run junit/othervm -Dsun.misc.URLClassPath.disableJarChecking
>>> JarCheckTest
>>> 59: * @run junit/othervm -Dsun.misc.URLClassPath.disableJarChecking=true
> The internal `ProtectionDomain.doIntersectionPrivilege` methods can be
> removed as all dependencies have been removed in post JEP 486 cleanup issues.
Sean Mullan has updated the pull request incrementally with one additional
commit since the last revision:
Add # to linkplain link.
---
On Wed, 4 Dec 2024 14:50:11 GMT, Aleksey Shipilev wrote:
>> This fix looks correct by looking on original changes.
>>
>> Yes, special Interpreter's code for these methods is only generated for
>> x86_32 in `templateInterpreterGenerator_x86_32.cpp`.
>
>> I just launched testing, I don't think @
> Can I please get a review of this change which proposes to address
> https://bugs.openjdk.org/browse/JDK-8341551?
>
> The primary work in this PR is the specification of the previously existing
> `sun.misc.URLClassPath.disableJarChecking` system property and how the
> internal implementation
On Wed, 4 Dec 2024 15:46:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8341551?
>>
>> The primary work in this PR is the specification of the previously existing
>> `sun.misc.URLClassPath.disableJarChec
On Wed, 4 Dec 2024 16:24:55 GMT, Sean Mullan wrote:
>> The internal `ProtectionDomain.doIntersectionPrivilege` methods can be
>> removed as all dependencies have been removed in post JEP 486 cleanup issues.
>
> Sean Mullan has updated the pull request incrementally with one additional
> commit
On Wed, 4 Dec 2024 16:12:39 GMT, Lance Andersen wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> improve code comment
>
> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 657:
>
>> 655:
On Wed, 4 Dec 2024 16:25:47 GMT, Eirik Bjørsnøs wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> improve code comment
>
> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 89:
>
>> 87:
On Wed, 4 Dec 2024 16:28:58 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8341551?
>>
>> The primary work in this PR is the specification of the previously existing
>> `sun.misc.URLClassPath.disableJarChec
On Wed, 4 Dec 2024 09:42:59 GMT, Aleksey Shipilev wrote:
>> Found this while cleaning up x86_32 code for removal.
>>
>> In our current code there is a block added by
>> [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373):
>> https://github.com/openjdk/jdk/blob/3b21a298c29d88720f6bfb2dc1f
On Thu, 28 Nov 2024 18:22:24 GMT, Aleksey Shipilev wrote:
> Found this while cleaning up x86_32 code for removal.
>
> In our current code there is a block added by
> [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373):
> https://github.com/openjdk/jdk/blob/3b21a298c29d88720f6bfb2dc1f3305
On Wed, 4 Dec 2024 05:14:55 GMT, Alexey Semenyuk wrote:
>> - Add missing resource keys to Windows property files;
>> - Fix the code to throw `ConfigException` if the service installer
>> executable is required but not available instead of throwing the exception
>> only when it is not found in
> Can I please get a review of this change which proposes to address
> https://bugs.openjdk.org/browse/JDK-8341551?
>
> The primary work in this PR is the specification of the previously existing
> `sun.misc.URLClassPath.disableJarChecking` system property and how the
> internal implementation
On Wed, 4 Dec 2024 16:35:19 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 89:
>>
>>> 87: // JAR check is disabled by default and will be enabled only if
>>> the "disable JAR check"
>>> 88: // system property has been set to "f
On Wed, 4 Dec 2024 16:35:09 GMT, Roger Riggs wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Lance's suggestion - better comment on the method
>
> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java l
On Wed, 4 Dec 2024 16:40:17 GMT, Naoto Sato wrote:
>> Alexey Semenyuk 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 two additional
>> commits
On Wed, 4 Dec 2024 16:40:42 GMT, Roger Riggs wrote:
>> Hello Eirik, I have received similar inputs in other places when discussing
>> this change. I myself had to think a few times on which naming to follow
>> here to make it easier to understand the code. I'll consider your and other
>> input
On Wed, 4 Dec 2024 16:46:13 GMT, Alexey Semenyuk wrote:
>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties
>> line 61:
>>
>>> 59: error.short-path-conv-fail=Failed to get short version of "{0}" path
>>> 60: error.missing-service-installer='service-
On Wed, 4 Dec 2024 16:46:17 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8341551?
>>
>> The primary work in this PR is the specification of the previously existing
>> `sun.misc.URLClassPath.disableJarChec
On Wed, 4 Dec 2024 16:46:14 GMT, Eirik Bjørsnøs wrote:
>> We're stuck with the property name for compatibility, and the usage within
>> the class is fairly limited.
>> Generally, it is easier to understand the behavior having a feature that is
>> enabled not a disable that is disabled.
>> $0.02
Hi Eirik,
Yes, the situation we're in is far from perfect. I've never been a big
fan of considering that an empty value means "true": if you're going
to pass a System property, you can go the extra mile and supply
its value too, which should make the intent uncontroversial. Note that
not passing
On Wed, 4 Dec 2024 14:23:07 GMT, Chen Liang wrote:
> Over the years there have been significant rounds of cleanup to try and keep
> the classfile API as focussed and true to its underlying functional core as
> possible. One of the side-effects of such cleanups was to move higher-level
> functi
>
> Practically, if we wanted to change such long standing behaviors
> in order to align on a new consistent handling for all the boolean
> properties.
>
There are at least three issues at play here:
a: Some flags use inconsistent, confusing, controversial or
less-than-perfect interpretations
b:
On Wed, 4 Dec 2024 09:31:14 GMT, Emanuel Peter wrote:
>> Found this while cleaning up x86_32 code for removal.
>>
>> In our current code there is a block added by
>> [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373):
>> https://github.com/openjdk/jdk/blob/3b21a298c29d88720f6bfb2dc1f330
> Prepare for JDK 25.
Pavel Rappo has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 14 commits:
- Merge branch 'master' into 8342979
- Update --release 24 symbol information for JDK 24 build 26
The macOS/AArch64 build 26 was ta
On Wed, 4 Dec 2024 14:23:07 GMT, Chen Liang wrote:
> Over the years there have been significant rounds of cleanup to try and keep
> the classfile API as focussed and true to its underlying functional core as
> possible. One of the side-effects of such cleanups was to move higher-level
> functi
> - Add missing resource keys to Windows property files;
> - Fix the code to throw `ConfigException` if the service installer
> executable is required but not available instead of throwing the exception
> only when it is not found in the resource directory;
> - Fix `JPackageStringBundle.getForm
On Wed, 4 Dec 2024 16:48:57 GMT, Naoto Sato wrote:
>> Should I revert changes in `WinResources_*.properties` files?
>
> Yes, please.
Done
-
PR Review Comment: https://git.openjdk.org/jdk/pull/22533#discussion_r1870021873
>
> There are at least three issues at play here:
>
> a: Some flags use inconsistent, confusing, controversial or
> less-than-perfect interpretations
> b: Some flags use identical interpretations, yet their evaluation happens
> in copy-pasted code spread across the code base
> c: Some flags use ide
On Wed, 4 Dec 2024 17:49:16 GMT, Pavel Rappo wrote:
>> Prepare for JDK 25.
>
> Pavel Rappo has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 14 commits:
>
> - Merge branch 'master' into 8342979
> - Update --release 24 symbol inform
On Wed, 4 Dec 2024 07:31:24 GMT, Henry Jen wrote:
>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor
>> and java.vendor.url.
>>
>> The jlink plugin will change the value in java.lang.VersionProps, which will
>> set those property values. The `java.vm.vendor` was init
On Wed, 4 Dec 2024 17:52:59 GMT, Alexey Semenyuk wrote:
>> - Add missing resource keys to Windows property files;
>> - Fix the code to throw `ConfigException` if the service installer
>> executable is required but not available instead of throwing the exception
>> only when it is not found in
On Wed, 4 Dec 2024 18:03:42 GMT, Mandy Chung wrote:
>> Henry Jen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Clean up adapting review comments
>
> make/autoconf/spec.gmk.template line 276:
>
>> 274:
>> 275: ifneq ($(COMPANY_NAME),
On Wed, 4 Dec 2024 07:31:24 GMT, Henry Jen wrote:
>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor
>> and java.vendor.url.
>>
>> The jlink plugin will change the value in java.lang.VersionProps, which will
>> set those property values. The `java.vm.vendor` was init
On Thu, 21 Nov 2024 10:24:28 GMT, Daniel Fuchs wrote:
>> This PR remove usage of SecurityManager, doPrivileges, etc... from
>> `java.logging` and `java.base/jdk.internal.logger`
>>
>> Only notable hack - Logger.checkPermission() no longer checks permissions,
>> but has been renamed into `ensur
On Wed, 4 Dec 2024 18:24:26 GMT, Mandy Chung wrote:
>> Henry Jen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Clean up adapting review comments
>
> src/java.base/share/classes/java/lang/VersionProps.java.template line 128:
>
>> 126:
> Improve the documentation for classfile instructions. Includes links to all
> opcodes, usage notes for instructions, and other various fixes.
>
> API Diff:
> https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
> Javadoc:
> https://cr.openjdk.org/~liach/javadoc/cf-inst
1 - 100 of 133 matches
Mail list logo
