On Mon, 15 Nov 2021 19:31:09 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, 16 Nov 2021 00:40:10 GMT, Sergey Bylokhov wrote:
>> The ZipOutputStream class may create bogus zip data which cannot be opened
>> by the ZipFile. The root cause is how the comment field is stored by the
>> ZipOutputStream. According to the zip specification, the comment field
>>
On Sun, 14 Nov 2021 21:42:01 GMT, Lance Andersen wrote:
> Yes it would be nice to clarify that a null is accepted by setComment. When
> null is specified, the comment length is written as 0
@mrserb Are you taking the spec clarification or should we just created another
issue in JBS to track
On Fri, 12 Nov 2021 17:01:38 GMT, Paul Sandoz wrote:
>>> > You could also do this directly in the Panama repo branches. I'll
>>> > volunteer to help, if you want.
>>>
>>> I'll run the script on the PR I've submitted for the Foreign API, and I
>>> will update that one - thanks. Perhaps
On Mon, 15 Nov 2021 17:32:04 GMT, Naoto Sato wrote:
>> Please review the subject fix. In light of JEP400, Java runtime can/should
>> start in UTF-8 charset if the underlying native encoding is not supported.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit
On Tue, 16 Nov 2021 05:24:38 GMT, Vicente Romero wrote:
> Please review this PR which aims to optimize the implementation of the
> `toString` method we provide for records. A benchmark comparing the
> implementation we are providing for records with lombok found out that lombok
> is much
On Wed, 17 Nov 2021 09:59:43 GMT, Alan Bateman wrote:
>> ZipEntry::setComment indicates that the comment will be truncated if needed
>> and ZipOutputStream takes care of this.
>>
>> Perhaps writeEND() should also be updated to something like:
>> `writeBytes(comment, 0,
On Fri, 12 Nov 2021 17:01:38 GMT, Paul Sandoz wrote:
>>> > You could also do this directly in the Panama repo branches. I'll
>>> > volunteer to help, if you want.
>>>
>>> I'll run the script on the PR I've submitted for the Foreign API, and I
>>> will update that one - thanks. Perhaps
On Sun, 17 Oct 2021 21:06:44 GMT, Andrey Turbanov wrote:
> Non-static classes hold a link to their parent classes, which can be avoided.
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5983
On 16/11/2021 19:02, Pushkar N Kulkarni wrote:
Hi Alan,
Thanks. I appreciate your response.
Yes, I think GB13080 must continue to be GB13080-2000 for now. I was initially hoping to
add a new character set with the name GB13080-2005. But I guess your suggestion of
internally mapping one of
On Wed, 17 Nov 2021 17:27:20 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since
On Wed, 17 Nov 2021 12:08:37 GMT, Lance Andersen wrote:
> There appears to be a similar test,
> open/test/jdk/java/util/zip/ZipFile/Comment.java, I think we probably want to
> fold your changes into the existing test and possibly convert to use TestNG.
I know that test, and I explicitly
On Wed, 17 Nov 2021 18:20:07 GMT, Brian Burkhalter wrote:
> I also do not like potentially non-obvious default behavior, nor a command
> line flag, nor a (static) setting on `BigInteger`. Thus I think the original
> `parallelMultiply()` (or perhaps `multiplyParallel()`) would be preferable.
On Wed, 17 Nov 2021 17:48:39 GMT, Naoto Sato wrote:
>> Please review the subject fix. In light of JEP400, Java runtime can/should
>> start in UTF-8 charset if the underlying native encoding is not supported.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit
On Wed, 17 Nov 2021 19:25:33 GMT, Sergey Bylokhov wrote:
> > Sorry if my point was not clear. I would prefer to have 1 test to exercise
> > a Zip file comment vs have tests in multiple areas. Expanding the existing
> > test in this case keeps the primary coverage in one location and makes it
In JDK 9, function objects implemented as anonymous inner classes in
java.util.regex.Pattern have been replaced by lambda functions (see
[JDK-8151481](https://bugs.openjdk.java.net/browse/JDK-8151481)). This led to a
significant performance regression (up to ~8X) for patterns with negated
On Fri, 12 Nov 2021 17:01:38 GMT, Paul Sandoz wrote:
>>> > You could also do this directly in the Panama repo branches. I'll
>>> > volunteer to help, if you want.
>>>
>>> I'll run the script on the PR I've submitted for the Foreign API, and I
>>> will update that one - thanks. Perhaps
> Please review the subject fix. In light of JEP400, Java runtime can/should
> start in UTF-8 charset if the underlying native encoding is not supported.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Removed changes to Util.java as
On Wed, 17 Nov 2021 18:43:46 GMT, Sergey Bylokhov wrote:
> > There appears to be a similar test,
> > open/test/jdk/java/util/zip/ZipFile/Comment.java, I think we probably want
> > to fold your changes into the existing test and possibly convert to use
> > TestNG.
>
> I know that test, and I
On Wed, 17 Nov 2021 17:51:03 GMT, Erik Österlund wrote:
> > I would be wary to make any API use multiple threads behind the scenes
> > without the user explicitly asking for it. While latency of the given
> > operation might improve in isolation, parallelization always incur some
> > (often
On Wed, 17 Nov 2021 19:18:19 GMT, Magnus Ihse Bursie wrote:
>> Both jar and jmod utilise java.io file operations whose methods define no
>> ordering of the return file lists, and in fact rely on OS query file
>> ordering, which can differ by underlying OS architecture.
>> This PR adds sort
On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard wrote:
> Both jar and jmod utilise java.io file operations whose methods define no
> ordering of the return file lists, and in fact rely on OS query file
> ordering, which can differ by underlying OS architecture.
> This PR adds sort processing
> Hi all,
>
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close
> operations on GZip we are not setting the deflator to a finished state which
> is leading to an infinite loop when we try writing on the
On Nov 17, 2021, at 11:14 AM, Paul Sandoz
mailto:psan...@openjdk.java.net>> wrote:
Would adding a parameter in the nature of `maxProcessors` make any sense?
Kind of but i would recommend not doing it. That's hard to express in a manner
that developers will choose appropriate values across all
On Wed, 17 Nov 2021 17:51:03 GMT, Erik Österlund wrote:
> I would be wary to make any API use multiple threads behind the scenes
> without the user explicitly asking for it. While latency of the given
> operation might improve in isolation, parallelization always incur some
> (often
On Wed, 17 Nov 2021 15:11:24 GMT, Maurizio Cimadamore
wrote:
>> So the refresh is still upcoming? Sorry, I thought it was pushed last week.
>> When it is pushed, I'll merge in master and the duplicated changes will just
>> be removed from the PR.
>
>> So the refresh is still upcoming? Sorry,
On Tue, 16 Nov 2021 00:40:10 GMT, Sergey Bylokhov wrote:
>> The ZipOutputStream class may create bogus zip data which cannot be opened
>> by the ZipFile. The root cause is how the comment field is stored by the
>> ZipOutputStream. According to the zip specification, the comment field
>>
On Wed, 17 Nov 2021 19:11:35 GMT, Paul Sandoz wrote:
> > I also do not like potentially non-obvious default behavior, nor a command
> > line flag, nor a (static) setting on `BigInteger`. Thus I think the
> > original `parallelMultiply()` (or perhaps `multiplyParallel()`) would be
> >
On Wed, 17 Nov 2021 13:02:10 GMT, Alan Bateman wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replace jnuEncoding in jni_util.c with UTF-8, if platform encoding is not
>> supported
>
>
On Wed, 17 Nov 2021 17:48:39 GMT, Naoto Sato wrote:
>> Please review the subject fix. In light of JEP400, Java runtime can/should
>> start in UTF-8 charset if the underlying native encoding is not supported.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit
On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard wrote:
> Both jar and jmod utilise java.io file operations whose methods define no
> ordering of the return file lists, and in fact rely on OS query file
> ordering, which can differ by underlying OS architecture.
> This PR adds sort processing
On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard wrote:
> Both jar and jmod utilise java.io file operations whose methods define no
> ordering of the return file lists, and in fact rely on OS query file
> ordering, which can differ by underlying OS architecture.
> This PR adds sort processing
On Wed, 17 Nov 2021 19:21:39 GMT, Paul Sandoz wrote:
>>> @mcimadamore Thanks!
>>>
>>> @PaulSandoz I'll keep this PR open until after the integration is done, and
>>> check if or what parts are still needed after that. I don't want to mess up
>>> your integration with trivia like this. (Had I
On Tue, 16 Nov 2021 21:22:36 GMT, Claes Redestad wrote:
> I would be wary to make any API use multiple threads behind the scenes
> without the user explicitly asking for it. While latency of the given
> operation might improve in isolation, parallelization always incur some
> (often
On Mon, 15 Nov 2021 17:28:30 GMT, Roger Riggs wrote:
> The ObjectInputStream.GetField.get(String name, Object val) method is
> returning null instead of throwing an exception when the class of the object
> is not found. The caller is not able to correctly handle the case where the
> class is
On Wed, 17 Nov 2021 18:48:00 GMT, Lance Andersen wrote:
> Sorry if my point was not clear. I would prefer to have 1 test to exercise a
> Zip file comment vs have tests in multiple areas. Expanding the existing test
> in this case keeps the primary coverage in one location and makes it easier
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Wed, 10 Nov 2021 12:58:13 GMT, Aleksei Efimov wrote:
>> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to
>> the state previous to JDK-8160768, where an authentication failure stops
>> from trying other LDAP servers with the same credentials [1]. After
>>
> Hi all,
>
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close
> operations on GZip we are not setting the deflator to a finished state which
> is leading to an infinite loop when we try writing on the
On Wed, 17 Nov 2021 19:48:25 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since
On Wed, 17 Nov 2021 14:56:19 GMT, Magnus Ihse Bursie wrote:
> So the refresh is still upcoming? Sorry, I thought it was pushed last week.
> When it is pushed, I'll merge in master and the duplicated changes will just
> be removed from the PR.
There are _two_ refreshes:
* foreign API refresh:
Hi Suminda,
please read my reply to you from May
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077081.html
Greetings
Raffaello
On 2021-11-17 14:54, Suminda Sirinath Salpitikorala Dharmasena wrote:
On Mon, 15 Nov 2021 19:31:09 GMT, Raffaello Giulietti
wrote:
Hello,
On Mon, 15 Nov 2021 19:31:09 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
The ObjectInputStream.GetField.get(String name, Object val) method is returning
null instead of throwing an exception when the class of the object is not
found. The caller is not able to correctly handle the case where the class is
not found. The signature of GetField.get(name, val) should have
On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard wrote:
> Both jar and jmod utilise java.io file operations whose methods define no
> ordering of the return file lists, and in fact rely on OS query file
> ordering, which can differ by underlying OS architecture.
> This PR adds sort processing
On Mon, 15 Nov 2021 17:32:04 GMT, Naoto Sato wrote:
>> Please review the subject fix. In light of JEP400, Java runtime can/should
>> start in UTF-8 charset if the underlying native encoding is not supported.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit
On Tue, 16 Nov 2021 05:24:38 GMT, Vicente Romero wrote:
> Please review this PR which aims to optimize the implementation of the
> `toString` method we provide for records. A benchmark comparing the
> implementation we are providing for records with lombok found out that lombok
> is much
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Wed, 17 Nov 2021 17:20:11 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since
On Wed, 17 Nov 2021 17:14:32 GMT, Brian Burkhalter wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Reordered import statements to be consistent with canonical order
>
>
On Tue, 16 Nov 2021 21:09:08 GMT, Naoto Sato wrote:
>> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
>> PrintStream to its charset. This issue was raised during the conversations
>> in https://github.com/openjdk/jdk/pull/5771
>> A corresponding CSR has also been
On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
>
On Wed, 17 Nov 2021 22:00:30 GMT, Vicente Romero wrote:
>> Please review this PR which aims to optimize the implementation of the
>> `toString` method we provide for records. A benchmark comparing the
>> implementation we are providing for records with lombok found out that
>> lombok is much
On Tue, 16 Nov 2021 21:49:55 GMT, Naoto Sato wrote:
> BTW, I still observe on Windows (system locale=ja-JP):
>
> ```
> D:\projects\jdk\git\jdk>.\build\windows-x64\jdk\bin\jshell
> -J-Duser.language=ja
> | JShellへようこそ -- バージョン18-internal
> | 概要については、次を入力してください: /help intro
>
> jshell>
Pretty much what it says. The new option controls a static member in
InstanceKlass that's consulted to determine whether the finalization machinery
is activated for instances when a class is loaded. A new native method is added
so that this state can be queried from Java. This is used to
On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard wrote:
> Both jar and jmod utilise java.io file operations whose methods define no
> ordering of the return file lists, and in fact rely on OS query file
> ordering, which can differ by underlying OS architecture.
> This PR adds sort processing
On Thu, 18 Nov 2021 01:34:36 GMT, Stuart Marks wrote:
> Pretty much what it says. The new option controls a static member in
> InstanceKlass that's consulted to determine whether the finalization
> machinery is activated for instances when a class is loaded. A new native
> method is added so
On Fri, 5 Nov 2021 17:31:50 GMT, Naoto Sato wrote:
> Please review the subject fix. In light of JEP400, Java runtime can/should
> start in UTF-8 charset if the underlying native encoding is not supported.
This pull request has now been integrated.
Changeset: b8453ebd
Author:Naoto Sato
On Wed, 17 Nov 2021 20:13:03 GMT, Lance Andersen wrote:
>> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 828:
>>
>>> 826: String[] dirFiles = f.list();
>>> 827: // Ensure files list is sorted for reproducible
>>> jar content
>>> 828:
On Wed, 17 Nov 2021 21:04:20 GMT, Ravi Reddy wrote:
>> Hi all,
>>
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close
>> operations on GZip we are not setting the deflator to a finished state which
>>
On Wed, 17 Nov 2021 21:24:40 GMT, Andrew Leonard wrote:
>> I agree, we should change this to include braces with the if statement.
>
> I agree, I always use {}, I was being consistent with the rest of the
> expand() method, but I will add {} as I prefer that too, better to set a good
>
> Please review this PR which aims to optimize the implementation of the
> `toString` method we provide for records. A benchmark comparing the
> implementation we are providing for records with lombok found out that lombok
> is much faster mainly because our implementation uses
On Thu, 18 Nov 2021 01:34:36 GMT, Stuart Marks wrote:
> Pretty much what it says. The new option controls a static member in
> InstanceKlass that's consulted to determine whether the finalization
> machinery is activated for instances when a class is loaded. A new native
> method is added so
On Thu, 18 Nov 2021 06:43:01 GMT, Kim Barrett wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added
On Wed, 17 Nov 2021 19:48:25 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since
On Mon, 15 Nov 2021 16:20:07 GMT, iaroslavski wrote:
>> 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
On Thu, 18 Nov 2021 05:20:02 GMT, Stuart Marks wrote:
>> src/java.base/share/classes/java/lang/ref/Finalizer.java line 195:
>>
>>> 193:
>>> 194: static {
>>> 195: if (Holder.ENABLED) {
>>
>> Hello Stuart,
>> My understanding of the the lazy `Holder` is that it's there to delay the
On Thu, 18 Nov 2021 01:34:36 GMT, Stuart Marks wrote:
> Pretty much what it says. The new option controls a static member in
> InstanceKlass that's consulted to determine whether the finalization
> machinery is activated for instances when a class is loaded. A new native
> method is added so
On Thu, 18 Nov 2021 07:13:55 GMT, David Holmes wrote:
>> Huh, good catch! This was mostly left over from an earlier version of the
>> flag that used system properties, which aren't initialized until after the
>> Finalizer class is initialized.
>>
>> It might be the case that the Holder can be
On Thu, 18 Nov 2021 07:27:30 GMT, Aleksey Shipilev wrote:
>> @stuart-marks not sure I see how anything is different here compared to the
>> existing logic. The `Finalizer` class is explicitly initialized quite early
>> in the init process, but if a preceding class's initialization created an
On Thu, 18 Nov 2021 07:40:34 GMT, David Holmes wrote:
>> Do we even have to have a flag on Java side? It looks like these calls are
>> only done as the upcalls from VM, so we might just keep the flag on VM side?
>
> @shipilev not sure what you mean by "a flag on the Java side". The Java code
On Thu, 18 Nov 2021 07:16:56 GMT, Kim Barrett wrote:
> There is nothing here to make the various GCs take advantage of finalization
> being disabled. Is the plan to leave that to followup changes?
@kimbarrett I provided the basic VM parts here. I'm not aware of what
specifically a GC might
On Thu, 18 Nov 2021 07:44:05 GMT, Aleksey Shipilev wrote:
>> @shipilev not sure what you mean by "a flag on the Java side". The Java
>> code just queries the VM for the finalization enabled/disabled state and
>> uses that to control things.
>
> Yeah, "flag" is `Holder.ENABLED` here. I mean,
On Thu, 18 Nov 2021 01:34:36 GMT, Stuart Marks wrote:
> Pretty much what it says. The new option controls a static member in
> InstanceKlass that's consulted to determine whether the finalization
> machinery is activated for instances when a class is loaded. A new native
> method is added so
On Thu, 18 Nov 2021 04:13:21 GMT, Jaikiran Pai wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added
On Mon, 15 Nov 2021 22:43:37 GMT, Naoto Sato wrote:
> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
> PrintStream to its charset. This issue was raised during the conversations in
> https://github.com/openjdk/jdk/pull/5771
> A corresponding CSR has also been
On Thu, 18 Nov 2021 00:11:49 GMT, Naoto Sato wrote:
> > BTW, I still observe on Windows (system locale=ja-JP):
> > ```
> > D:\projects\jdk\git\jdk>.\build\windows-x64\jdk\bin\jshell
> > -J-Duser.language=ja
> > | JShellへようこそ -- バージョン18-internal
> > | 概要については、次を入力してください: /help intro
> >
> >
77 matches
Mail list logo
