On Thu, 4 Nov 2021 03:18:40 GMT, Jaikiran Pai wrote:
> > So I decided to stick with using the ordinal modifiers in the hashCode()
> > computation. However, I'm not an expert on the performance aspects of the
> > Collections and how much using the modifiers for hashCode() will improve
> > the
> Can I please get a review for this change which fixes the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8275509?
>
> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
> components to compute the final hash code. While doing so it ends up calling
>
The lack of anything to compile in `syslookup.c` is leading to a number of
issues in our tooling, on some architectures more than others (s390x seems to
be the most problematic). They expect to be able to retrieve debuginfo and
compiler flags from generated .so files and fail with
Hello Alan,
On 04/11/21 1:21 am, Alan Bateman wrote:
On Wed, 3 Nov 2021 03:22:40 GMT, Jaikiran Pai wrote:
So I decided to stick with using the ordinal modifiers in the hashCode()
computation. However, I'm not an expert on the performance aspects of the
Collections and how much using the
On 4/11/2021 12:14 am, Pavel Rappo wrote:
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
This PR follows up one of the recent PRs, where I used a non-canonical modifier
order. Since the problem was noticed [^1], why not to address it en masse?
As far as I remember, the first
On Fri, 29 Oct 2021 10:38:41 GMT, Ivan Šipka wrote:
>> cc @ctornqvi
>
> Ivan Šipka has updated the pull request incrementally with one additional
> commit since the last revision:
>
> removed file added by accident
Thanks for the clarification, David. I guess my recollection of jtreg code
On Thu, 4 Nov 2021 01:34:01 GMT, Igor Ignatyev wrote:
>>> That doesn’t seem right as jtreg expects `-` not
>>> ``
>>
>> It has been tested, details in ticket comment.
>
> I’m sorry @frkator but there is nothing in the ticket.
@iignatev the comment is confidential as it refers to internal
On Mon, 1 Nov 2021 07:36:53 GMT, Aleksey Shipilev wrote:
>> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
>> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed
>> (useless?) to call to runtime for a single memory barrier. We can simplify
>> the native `Unsafe`
On Wed, 27 Oct 2021 09:57:43 GMT, swati sharma wrote:
> 8276048: Error in javadoc regarding Long method public static Long
> valueOf(String s)
> Fix: Changing integer to {@code Long}
I agree with Joe there is nothing to fix here - "integer" is general
mathematical term. If it were "int" or
On Wed, 3 Nov 2021 23:11:36 GMT, Ivan Šipka wrote:
>> That doesn’t seem right as jtreg expects `-` not ``
>
>> That doesn’t seem right as jtreg expects `-` not ``
>
> It has been tested, details in ticket comment.
I’m sorry @frkator but there is nothing in the ticket.
-
PR:
On Wed, 3 Nov 2021 22:12:29 GMT, Igor Ignatyev wrote:
> That doesn’t seem right as jtreg expects `-` not ``
It has been tested, details in ticket comment.
-
PR: https://git.openjdk.java.net/jdk/pull/6025
On Wed, 3 Nov 2021 21:57:44 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
On Mon, 1 Nov 2021 13:04:20 GMT, Claes Redestad wrote:
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
>
On Fri, 29 Oct 2021 10:38:41 GMT, Ivan Šipka wrote:
>> cc @ctornqvi
>
> Ivan Šipka has updated the pull request incrementally with one additional
> commit since the last revision:
>
> removed file added by accident
That doesn’t seem right as jtreg expects `-` not ``
-
PR:
On Wed, 3 Nov 2021 21:57:44 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When
This change applies the minimal fix suggested in
https://bugs.openjdk.java.net/browse/JDK-8231490.
The bug text suggests possibilities for reworking, but notes that
this change is enough to fix the data race.
Adding a regression test is probaby not feasible but we do observe
that Java TSAN no
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When
On Tue, 2 Nov 2021 20:09:21 GMT, Mandy Chung wrote:
> I reviewed the change. It is reasonable to fix the parsing of the pre-release
> version and the build version be consistent with parsing of the version
> number which currently skips consecutive delimiters.
>
> The spec is unclear on
On Wed, 3 Nov 2021 03:22:40 GMT, Jaikiran Pai wrote:
> So I decided to stick with using the ordinal modifiers in the hashCode()
> computation. However, I'm not an expert on the performance aspects of the
> Collections and how much using the modifiers for hashCode() will improve the
>
On Wed, 3 Nov 2021 19:44:35 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
On Wed, 3 Nov 2021 18:17:38 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Minor cleanup
>
> test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java line
> 80:
>
>> 78:
>> 79:
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When
On Wed, 27 Oct 2021 09:57:43 GMT, swati sharma wrote:
> 8276048: Error in javadoc regarding Long method public static Long
> valueOf(String s)
> Fix: Changing integer to {@code Long}
Strictly speaking I do not view the current text as erroneous. At time
"integer" is used an adjective; for
On Wed, 20 Oct 2021 00:04:08 GMT, Ivan Šipka wrote:
> cc @ctornqvi
This pull request has now been integrated.
Changeset: 32895ac6
Author:Ivan Šipka
Committer: Mark Sheppard
URL:
https://git.openjdk.java.net/jdk/commit/32895ac60949ccceb0a3d25c73ec5e3a00c29593
Stats: 1 line in 2
On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi
wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with
On Tue, 2 Nov 2021 19:06:09 GMT, Anirvan Sarkar wrote:
> This fixes Properties.loadFromXML/storeToXML so that it works correctly for
> supplementary characters.
Looks good to me. Thanks Anirvan for fixing the issue.
-
Marked as reviewed by joehw (Reviewer).
PR:
On Wed, 3 Nov 2021 17:23:51 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
The issue for the XSLTC was raised at
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-October/082767.html
:
The code in compile(InputSource input, String name) at
On Wed, 3 Nov 2021 17:33:36 GMT, Naoto Sato wrote:
> Looks good. I'd create a new test case class out of
> `TestFractionPrinterParser`, as you introduced the new `NanosPrinterParser`.
It was only indirectly a test of `FractionPrinterParser`; it's really a test of
`PrinterParsers` built using
Hi There,
Hotspot developers already identified a bug in verification (failure to
capture an invalid package name "die/verwandlung/" existing in the constant
pool of bytecode) at https://bugs.openjdk.java.net/browse/JDK-8276241 as I
raised via
On Tue, 2 Nov 2021 06:25:33 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers: we can
>> match
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull
On Wed, 27 Oct 2021 09:57:43 GMT, swati sharma wrote:
> 8276048: Error in javadoc regarding Long method public static Long
> valueOf(String s)
> Fix: Changing integer to {@code Long}
src/java.base/share/classes/java/lang/Long.java line 1141:
> 1139: * exactly as if the argument were
On Wed, 3 Nov 2021 17:23:51 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
On Fri, 29 Oct 2021 15:35:50 GMT, Roger Riggs wrote:
>> The ObjectInputStream.GetField method `get(String name, Object val)` should
>> have been throwing
>> a ClassNotFoundException if the class was not found. Instead the
>> implementation was returning null.
>> A design error does not allow
8276048: Error in javadoc regarding Long method public static Long
valueOf(String s)
Fix: Changing integer to {@code Long}
-
Commit messages:
- Update Long.java
Changes: https://git.openjdk.java.net/jdk/pull/6135/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6135=00
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When
On Fri, 29 Oct 2021 15:35:50 GMT, Roger Riggs wrote:
>> The ObjectInputStream.GetField method `get(String name, Object val)` should
>> have been throwing
>> a ClassNotFoundException if the class was not found. Instead the
>> implementation was returning null.
>> A design error does not allow
On Wed, 3 Nov 2021 11:58:42 GMT, Pavel Rappo wrote:
> This PR fixes two sentences which conflate a string with its length, and also
> makes the "equivalency wording" consistent.
>
> There are many ways to fix "the resulting String may be a different length
> than the original String". The
On Wed, 3 Nov 2021 14:24:28 GMT, Stephen Colebourne
wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add test verifying OOB values throw exception
>
> Thanks for adding the new tests, and finding that fraction
On Wed, 3 Nov 2021 13:14:42 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
The three `java.lang.Runtime.exec` methods that tokenize a command line to
produce an array of string arguments are easily misused, sometimes with
erroneous results. For example, on some operating systems, spaces are supported
in filenames and are in common use.
The tokenization uses only
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it en
> masse?
>
> As far as I remember, the first mass-canonicalization of modifiers took
On Wed, 3 Nov 2021 13:08:55 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Wed, 3 Nov 2021 12:17:09 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 3544:
>>
>>> 3542: BigDecimal valueBD =
>>> BigDecimal.valueOf(value).subtract(minBD);
>>> 3543: BigDecimal fraction =
> This change implements a new service provider interface for host name and
> address resolution, so that java.net.InetAddress API can make use of
> resolvers other than the platform's built-in resolver.
>
> The following API classes are added to `java.net.spi` package to facilitate
> this:
>
On Wed, 3 Nov 2021 11:58:42 GMT, Pavel Rappo wrote:
> This PR fixes two sentences which conflate a string with its length, and also
> makes the "equivalency wording" consistent.
>
> There are many ways to fix "the resulting String may be a different length
> than the original String". The
On Wed, 3 Nov 2021 12:44:39 GMT, Claes Redestad wrote:
>> I'll see to it.
>
> When adding a test for this I discovered that
> `FractionPrinterParser::format` will end up calling
> `field.range().checkValidValue(value, field)`
>
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When
Update this core file--
null
On 3/11/2021 9:26 pm, Pavel Rappo wrote:
On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz wrote:
Pragmatically, fix the script to ignore those keywords on comment lines. Learn
Perl, its just a regular expression pattern match and replace expression.
I understand in principle how to modify
Submit this core file--
null
On Wed, 3 Nov 2021 12:21:00 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 3266:
>>
>>> 3264: if (!field.range().isValidIntValue(value)) {
>>> 3265: if (fallback == null) {
>>> 3266:
> This change implements a new service provider interface for host name and
> address resolution, so that java.net.InetAddress API can make use of
> resolvers other than the platform's built-in resolver.
>
> The following API classes are added to `java.net.spi` package to facilitate
> this:
>
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When
On Wed, 3 Nov 2021 11:53:52 GMT, Stephen Colebourne
wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add fallback for values outside the allowable range
>
>
On Wed, 3 Nov 2021 12:04:10 GMT, Stephen Colebourne
wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add fallback for values outside the allowable range
>
>
On Tue, 2 Nov 2021 11:03:02 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
This PR fixes two sentences which conflate a string with its length, and also
makes the "equivalency wording" consistent.
There are many ways to fix "the resulting String may be a different length than
the original String". The proposed way might be one of the most lightweight
ways to do that.
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull
On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz wrote:
>>> Pragmatically, fix the script to ignore those keywords on comment lines.
>>> Learn Perl, its just a regular expression pattern match and replace
>>> expression.
>>
>> I understand in principle how to modify that script to ignore doc
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it en
> masse?
>
> As far as I remember, the first mass-canonicalization of modifiers took
On Tue, 2 Nov 2021 06:25:33 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers: we can
>> match
On Tue, 2 Nov 2021 06:25:33 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers: we can
>> match
67 matches
Mail list logo
