On Fri, 27 Jan 2023 06:52:31 GMT, Joe Darcy wrote:
> Restarting the port of FDLIBM to Java with the log10 method.
>
> There are two port, the first a near-transliteration from C port to use as a
> test reference in
>
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
>
> and a more idiomatic
Restarting the port of FDLIBM to Java with the log10 method.
There are two port, the first a near-transliteration from C port to use as a
test reference in
test/jdk/java/lang/StrictMath/FdlibmTranslit.java
and a more idiomatic Java port in
src/java.base/share/classes/java/lang/FdLibm.java
Fi
> On Jan 26, 2023, at 9:52 PM, Xuelei Fan wrote:
>
>
>
>> On Jan 26, 2023, at 9:27 PM, Glavo wrote:
>>
>> They only need to use "str".toLowerCase(Locale.ROOT).
>
> Sorry, with a workaround I meant to have toLowerCase() work without modifying
> the existing source code to use toLowerCase(L
> On Jan 26, 2023, at 9:27 PM, Glavo wrote:
>
> They only need to use "str".toLowerCase(Locale.ROOT).
Sorry, with a workaround I meant to have toLowerCase() work without modifying
the existing source code to use toLowerCase(Locale.ROOT).
Xuelei
>
> On Fri, Jan 27, 2023 at 1:18 PM Xuelei Fa
I analyzed the usage of toLowerCase and toUpperCase in OpenJDK more
carefully,
and found that none of the use cases really expected locale-sensitive
behavior, **all** use cases were misused without exception.
I think more third-party libraries and applications should be investigated
to determine
They only need to use "str".toLowerCase(Locale.ROOT).
On Fri, Jan 27, 2023 at 1:18 PM Xuelei Fan wrote:
> Just curious, this is a known issue for many years, how those areas like
> Turkish survive? Is there a workaround for those areas or the use of the
> methods is not common any longer?
>
> X
Just curious, this is a known issue for many years, how those areas like
Turkish survive? Is there a workaround for those areas or the use of the
methods is not common any longer?
Xuelei
> On Jan 26, 2023, at 4:35 AM, Glavo wrote:
>
> At present, the no-parameter toLowerCase and toUpperCase
On Fri, 27 Jan 2023 02:02:34 GMT, Naoto Sato wrote:
> The fix itself looks good. Add the bug id to `LocaleDataTest.java`
Added BugID to the list of BugID's in `LocaleDataTest.java`
-
PR: https://git.openjdk.org/jdk20/pull/118
> Localization update didn't include an update to LocaleData file. This PR
> addresses this by updating the file with the newly translated values. The
> LocaleDataTest now passes. This should address the recent related failures to
> LocaleData.
Damon Nguyen has updated the pull request incremen
On Fri, 27 Jan 2023 01:43:11 GMT, Damon Nguyen wrote:
> Localization update didn't include an update to LocaleData file. This PR
> addresses this by updating the file with the newly translated values. The
> LocaleDataTest now passes. This should address the recent related failures to
> LocaleD
Localization update didn't include an update to LocaleData file. This PR
addresses this by updating the file with the newly translated values. The
LocaleDataTest now passes. This should address the recent related failures to
LocaleData.
-
Commit messages:
- Update LocaleData
Chan
On Thu, 26 Jan 2023 21:56:22 GMT, Glavo wrote:
> When the default Locale is tr, the letter `i` will be converted to `İ`
> (U+0130) by `toUpperCase()`. This causes the assertion to fail.
This pull request has now been integrated.
Changeset: c3ff1514
Author:Glavo
Committer: Paul Sandoz
URL
On Fri, 27 Jan 2023 00:19:49 GMT, Stuart Marks wrote:
>> Tagir F. Valeev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert cast removal
>
> src/java.base/share/classes/java/util/Collections.java line 1068:
>
>> 1066:
>> 1067:
On Wed, 25 Jan 2023 22:23:26 GMT, Tagir F. Valeev wrote:
>> number of minor cleanups could be done in Arrays and Collections utility
>> classes.
>> In Arrays:
>> - Redundant import jdk.internal.misc.Unsafe;
>> - C-style array declaration is used in public static boolean equals(short[]
>> a, sho
On Wed, 25 Jan 2023 22:23:26 GMT, Tagir F. Valeev wrote:
>> number of minor cleanups could be done in Arrays and Collections utility
>> classes.
>> In Arrays:
>> - Redundant import jdk.internal.misc.Unsafe;
>> - C-style array declaration is used in public static boolean equals(short[]
>> a, sho
On Thu, 26 Jan 2023 21:56:22 GMT, Glavo wrote:
> When the default Locale is tr, the letter `i` will be converted to `İ`
> (U+0130) by `toUpperCase()`. This causes the assertion to fail.
Looks good. I am grateful the assert was in place.
-
Marked as reviewed by psandoz (Reviewer).
On Thu, 26 Jan 2023 23:03:56 GMT, Paul Sandoz wrote:
> Looks good. All changes seem informational explaining the existing behavior
> so no CSR?
Since that's not spec change, no CSR is my take.
-
PR: https://git.openjdk.org/jdk/pull/12236
On Thu, 26 Jan 2023 22:27:36 GMT, Mandy Chung wrote:
>> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a
>> class in the runtime package of the Lookup's lookup class via
>> `Lookup::defineClass`. The classes that are injected have the same access
>> as other members
On Thu, 26 Jan 2023 21:46:04 GMT, Paul Sandoz wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review feedback
>
> src/java.base/share/classes/java/lang/Module.java line 607:
>
>> 605: * {@link java.lang.invoke
On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen wrote:
> Open l10n drop. Files have been updated with translated versions. Whitespace
> tool has been ran on files.
> All tests passed
This pull request has now been integrated.
Changeset: a67b1e77
Author:Damon Nguyen
Committer: Naoto Sato
U
On Wed, 25 Jan 2023 20:21:11 GMT, Justin Lu wrote:
>> When their input is null, the following methods in java.util.TimeZone throw
>> a NullPointerException:
>>
>> _TimeZone.getTimeZone(String ID)
>> TimeZone.setID(String ID)
>> TimeZone.inDaylightTime(Date date)_
>>
>> For example,
>>
>>
>>
> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a
> class in the runtime package of the Lookup's lookup class via
> `Lookup::defineClass`. The classes that are injected have the same access
> as other members in the module and can access private members of all types
When the default Locale is tr, the letter `i` will be converted to `İ` (U+0130)
by `toUpperCase()`. This causes the assertion to fail.
-
Commit messages:
- 8301190: [vectorapi] The typeChar of LaneType is incorrect when default
locale is tr
Changes: https://git.openjdk.org/jdk/pul
On Thu, 26 Jan 2023 21:03:59 GMT, Mandy Chung wrote:
> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a
> class in the runtime package of the Lookup's lookup class via
> `Lookup::defineClass`. The classes that are injected have the same access
> as other members in
> This issue was found during the review of this PR:
> https://github.com/openjdk/jdk/pull/12132 where `Charset` class was
> loaded/initialized at the phase 1 of the startup process. Since `Charset`
> depends on `StaticProperty`, loading of `Charset` class should be delayed. I
> basically moved
On Thu, 26 Jan 2023 12:07:20 GMT, Alan Bateman wrote:
> Thanks for the updates/iterations, I think you've got this to a good place.
>
> One thing to think about is having System.initPhase3 read file.encoding and
> if not UTF-8, it could call Charset.defaultCharset and if not the expected
> val
Currently, a `Lookup` object with `PACKAGE` access can be used to inject a
class in the runtime package of the Lookup's lookup class via
`Lookup::defineClass`. The classes that are injected have the same access as
other members in the module and can access private members of all types in the
On Tue, 24 Jan 2023 18:19:22 GMT, Mandy Chung wrote:
> A simple fix in core reflection to check if the number of actual and formal
> parameters differ before invoking the method or the constructor regardless of
> whether it's a specialized case or not.
LGTM
-
Marked as reviewed b
On Thu, 26 Jan 2023 19:18:52 GMT, Oliver Kopp wrote:
>> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567):
>> "MethodTooLargeException thrown while creating a jlink image".
>>
>> Java still has a 64kb limit: A method may not be longer than 64kb. The idea
>> of the fix is to sp
> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567):
> "MethodTooLargeException thrown while creating a jlink image".
>
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea
> of the fix is to split up the generated methods in several smaller methods
Oli
> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567):
> "MethodTooLargeException thrown while creating a jlink image".
>
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea
> of the fix is to split up the generated methods in several smaller methods
Oli
Hi,
This PR updates the test TestTooManyEntries to not create gigabytes of
ZIP files, allowing the test to run fast and non-manual:
https://github.com/openjdk/jdk/pull/12231
May I please get some help with filing a JBS for this PR?
Thanks,
Eirik.
On Wed, 4 Jan 2023 14:41:20 GMT, Viktor Klang wrote:
> Currently Set.copyOf allocates both a HashSet and a new empty array when the
> input collection is empty.
>
> This patch avoids allocating anything for the case where the parameter
> collection's isEmpty returns true.
This pull request ha
On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg wrote:
> This PR suggests improving performance by using the newly introduced class
> `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
>
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for
> little en
On Thu, 26 Jan 2023 14:10:47 GMT, Hannes Greule wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> merged JAVAC_FLAGS and EXCLUDES in Java.gmk
>
> (not a reviewer) From a quick look at it, I noticed two things:
>
> 1.
> This is root pull request with Classfile API implementation, tests and
> benchmarks initial drop into JDK.
>
> Following pull requests consolidating JDK class files parsing, generating,
> and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957))
> will chain to this one.
>
On Fri, 20 Jan 2023 15:53:09 GMT, Severin Gehwolf wrote:
> Please review this fix to
> [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the
> same handling for swap values exceeding what's possible in the non-container
> case. I.e. treats it as unlimited and fixes the repo
On Wed, 25 Jan 2023 13:45:28 GMT, Severin Gehwolf wrote:
>> Please review this fix to
>> [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the
>> same handling for swap values exceeding what's possible in the non-container
>> case. I.e. treats it as unlimited and fixes the
The reason why I want to modify their behavior is that a large number of
programs have misused this method.
By modifying the behavior, we can fix them without modifying their source
code.
However, it may be a better choice to mark it as deprecated.
After deprecating them, we can provide new API m
On Wed, 25 Jan 2023 13:14:43 GMT, Adam Sotona wrote:
>> This is root pull request with Classfile API implementation, tests and
>> benchmarks initial drop into JDK.
>>
>> Following pull requests consolidating JDK class files parsing, generating,
>> and transforming
>> ([JDK-8294957](https://bu
> From: "Glavo"
> To: "core-libs-dev"
> Sent: Thursday, January 26, 2023 1:35:06 PM
> Subject: [Proposal] Make toLowerCase and toUpperCase based on Locale.ROOT by
> default
> At present, the no-parameter toLowerCase and toUpperCase methods of String are
> based on the default locale.
> I checke
At present, the no-parameter toLowerCase and toUpperCase methods of String
are based on the default locale.
I checked all the uses of this method in OpenJDK, and found that most of
the use cases are suspicious, and even there are some hidden bugs.
For example, I just found that jdk.incubator.vecto
On Thu, 26 Jan 2023 00:19:45 GMT, Naoto Sato wrote:
>> This issue was found during the review of this PR:
>> https://github.com/openjdk/jdk/pull/12132 where `Charset` class was
>> loaded/initialized at the phase 1 of the startup process. Since `Charset`
>> depends on `StaticProperty`, loading
Hello!
Not sure if this should be considered as a problem that requires
attention but there's an initialization loop between
java.util.Collections$UnmodifiableNavigableMap and
java.util.Collections$UnmodifiableNavigableMap$EmptyNavigableMap
classes. E.g., the following program may stuck in a class
On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg wrote:
> This PR suggests improving performance by using the newly introduced class
> `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
>
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for
> little en
On Thu, 19 Jan 2023 23:37:17 GMT, Mandy Chung wrote:
>> `VarHandles.getStaticFieldFromBaseAndOffset` maps a base/offset/fieldType to
>> a static `Field`. It's fragile to assume that the location of a static
>> field returned by `Unsafe.staticFieldBase` is a Class object.This
>> changes t
On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg wrote:
> This PR suggests improving performance by using the newly introduced class
> `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
>
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for
> little en
On Thu, 26 Jan 2023 02:37:57 GMT, Ichiroh Takiguchi
wrote:
> Could you explain about fragile scenario ?
Charset.defaultCharset does the lookup on the first usage. Since JDK 18, that
first usage is in initPhase1 so it will always find the default charset in
java.base. In JDK 9-17, the first us
48 matches
Mail list logo
