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
https://mail.openjdk.java.net/pipermail/hotspot-d
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 p
> 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
> hashC
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 libsyslookup.
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 mod
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 mass-canoni
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
i
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 testi
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` inter
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 "In
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: https:
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 l
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
> looke
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: https
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 l
> 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 printing
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 longe
> 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 printing
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 whethe
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
> performan
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 l
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 printing
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 exam
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 PrintStream.
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: https://git.openjd
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 l
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
https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/
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
https://mail.openjdk.java.net/pipermail/hotspot-de
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 request
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 given
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 l
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 t
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&pr=6135&ran
> 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 printing
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 t
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 prop
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 fo
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 l
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 white
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 place
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] - https://openjdk
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 = valueBD.di
> 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 prop
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)`
> [here](https://github.com/openjdk/jdk/blob/579b2c017f24f2266abefd
> 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 printing
> 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 request
> 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 printing
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 t
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 printing
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
>
> src/java.base/share/classes/java/time/format/DateTimeFo
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
>
> src/java.base/share/classes/java/time/format/DateTimeFo
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 l
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 request
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 c
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 place
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
68 matches
Mail list logo
