On Mon, 4 Oct 2021 16:24:18 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8274544: Langtools command's usage were garbled on Japanese Windows
>
>
> 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.
Ichiroh Takiguchi has updated the pull request incrementally
This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c
level. Note that the tz data is "as is", as released by IANA. No `merged links`
are retracted.
The PR also fixes two issues along with the 2021c upgrade.
-
Commit messages:
- Fix for Asia/Amman test case
On Mon, 4 Oct 2021 07:13:37 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 Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti
wrote:
>> Hello,
>>
>> here's a PR for a patch submitted on March 2020
>> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was
>> a thing.
>>
>> The patch has been edited to adhere to OpenJDK code conventions about
On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti
wrote:
>> Hello,
>>
>> here's a PR for a patch submitted on March 2020
>> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was
>> a thing.
>>
>> The patch has been edited to adhere to OpenJDK code conventions about
On Tue, 5 Oct 2021 17:51:31 GMT, Сергей Цыпанов
wrote:
>> Originally was proposed by Zheka Kozlov here:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html
>>
>> Just a tiny optimization: we can use for-i loop instead of
>> `Iterable.forEach()` which is relying
On Thu, 11 Feb 2021 13:28:49 GMT, Сергей Цыпанов
wrote:
> Originally was proposed by Zheka Kozlov here:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html
>
> Just a tiny optimization: we can use for-i loop instead of
> `Iterable.forEach()` which is relying on
Specification update to clarify Matcher behavior to include a null return value.
-
Commit messages:
- 8217496 Matcher.group() can return null after usePattern
Changes: https://git.openjdk.java.net/jdk/pull/5827/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5827=00
On Tue, 5 Oct 2021 17:51:31 GMT, Сергей Цыпанов
wrote:
>> Originally was proposed by Zheka Kozlov here:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html
>>
>> Just a tiny optimization: we can use for-i loop instead of
>> `Iterable.forEach()` which is relying
On Tue, 5 Oct 2021 09:18:57 GMT, Сергей Цыпанов
wrote:
>> Originally was proposed by Zheka Kozlov here:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html
>>
>> Just a tiny optimization: we can use for-i loop instead of
>> `Iterable.forEach()` which is relying
> Originally was proposed by Zheka Kozlov here:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html
>
> Just a tiny optimization: we can use for-i loop instead of
> `Iterable.forEach()` which is relying on iterator.
>
> Simple benchmark demonstrates slight
On Mon, 27 Sep 2021 20:56:28 GMT, Phil Race wrote:
> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
> the name of the application in the system menu bar.
>
> Because this set shortly after the VM is running, it causes a thread safety
> issue described in
On Tue, 5 Oct 2021 09:18:57 GMT, Сергей Цыпанов
wrote:
>> Originally was proposed by Zheka Kozlov here:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html
>>
>> Just a tiny optimization: we can use for-i loop instead of
>> `Iterable.forEach()` which is relying
On Mon, 4 Oct 2021 10:24:01 GMT, Jan Lahoda wrote:
>> Helllo @naotoj .
>> I used `System.console()` and `Console.charset()`.
>>
>> The following executables had same issue, I fixed them.
>>> jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe,
>>> jpackage.exe
>>
>> I
I forwarded the issue to Guy again recently. No reply as yet. He’s a busy dude.
Do we have any alternates?
> On Oct 5, 2021, at 10:58 AM, Andrew Haley
> wrote:
>
> On 9/28/21 10:30, Raffaello Giulietti wrote:
>> I was pondering whether to propose adding a launch-time option on the
>>
On Sat, 25 Sep 2021 10:15:11 GMT, Peter Levart wrote:
> This patch improves reflective access speed as shown by the included
> benchmarks:
>
> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a
>
> ... and is also a prerequisite to make JEP 416
On 9/28/21 10:30, Raffaello Giulietti wrote:
> I was pondering whether to propose adding a launch-time option on the command
> line to choose between the current and the proposed implementation for some
> time, so to help the community gaining confidence in the new algorithm and
> still have
On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov
wrote:
> Pass "cause" exception as constructor parameter is shorter and easier to read.
This pull request has now been integrated.
Changeset: 1459180f
Author:Andrey Turbanov
Committer: Weijun Wang
URL:
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis
wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashing function than
> Sorting:
>
> - adopt radix sort for sequential and parallel sorts on int/long/float/double
> arrays (almost random and length > 6K)
> - fix tryMergeRuns() to better handle case when the last run is a single
> element
> - minor javadoc and comment changes
>
> Testing:
> - add new data inputs
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis
wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashing function than
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis
wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashing function than
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:
-
I think the last sentence was missing a „not“ and referring to the same
manifest?
However the results are a bit of a mess, but utf-8 handling for argv would be
great plus (if converted correctly), right?
--
http://bernd.eckenfels.net
Von: core-libs-dev im
I ran cacls after the failed jpackage.
C:\temp\my-javafx-application>cacls build
C:\temp\my-javafx-application\build F
CREATOR OWNER:(OI)(CI)(IO)F
R
CREATOR GROUP:(OI)(CI)(IO)R
On Mon, 4 Oct 2021 16:51:27 GMT, Martin Buchholz wrote:
>> Сергей Цыпанов 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 four additional
>>
> Originally was proposed by Zheka Kozlov here:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html
>
> Just a tiny optimization: we can use for-i loop instead of
> `Iterable.forEach()` which is relying on iterator.
>
> Simple benchmark demonstrates slight
On 05/10/2021 08:54, Sverre Moe wrote:
With JDK 17, jpackage fails to write to the destination directory on
Windows.
It worked fine with JDK 11 (with jpackage from JDK14) and Docker.
Only happens on Windows docker. Running directly on WIndows it works with
JDK 17.
What has changed with
On 2021-10-05 03:22, John Platts wrote:
I wrote a test program (in C++) to detect the codepages that would be returned by the
GetACP(), GetOEMCP(), and GetConsoleCP() functions when the
UTF-8 setting is added to the
manifest.
The manifest element (supported on Windows 10 Version
1903 or
On Mon, 4 Oct 2021 22:24:39 GMT, Peter Levart wrote:
>> This patch improves reflective access speed as shown by the included
>> benchmarks:
>>
>> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a
>>
>> ... and is also a prerequisite to make JEP
With JDK 17, jpackage fails to write to the destination directory on
Windows.
It worked fine with JDK 11 (with jpackage from JDK14) and Docker.
Only happens on Windows docker. Running directly on WIndows it works with
JDK 17.
What has changed with jpackage that it no longer can write to the
On Tue, 5 Oct 2021 00:25:41 GMT, Phil Race wrote:
>> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
>> the name of the application in the system menu bar.
>>
>> Because this set shortly after the VM is running, it causes a thread safety
>> issue described in
33 matches
Mail list logo
