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
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 `String::format`. This
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 Mon, 15 Nov 2021 17:28:44 GMT, Naoto Sato wrote:
>> @naotoj , sorry for bothering you again.
>> Still I got exception. It seems value "jnuEncoding" should be overwritten or
>> set "fastEncoding" to "FAST_UTF_8" on jnu_util.c.
>> Could you check this part again ?
>>
>> $ env
On Wed, 27 Oct 2021 20:16:54 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For
> 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 should
> not be longer than 0x bytes, and we try to validate the
On Sun, 14 Nov 2021 16:14:54 GMT, Martin Buchholz wrote:
>> Sergey Bylokhov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update EmptyComment.java
>
> test/jdk/java/util/zip/ZipOutputStream/EmptyComment.java line 88:
>
>> 86:
On Sun, 14 Nov 2021 14:44:08 GMT, Lance Andersen wrote:
>> Sergey Bylokhov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update EmptyComment.java
>
> test/jdk/java/util/zip/ZipOutputStream/EmptyComment.java line 35:
>
>> 33: *
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 drafted:
https://bugs.openjdk.java.net/browse/JDK-8277078
On Fri, 8 Oct 2021 21:25:26 GMT, Paul Sandoz wrote:
> This PR improves the performance of vector operations that accept masks on
> architectures that support masking in hardware, specifically Intel AVX512 and
> ARM SVE.
>
> On architectures that do not support masking in hardware the same
On Mon, 15 Nov 2021 19:30:54 GMT, Roger Riggs wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Use ForceGC instead of System.gc()
>> - Convert test to testng
>
>
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
> The caches in ObjectStreamClass basically map WeakReference to
> SoftReference, where the ObjectStreamClass also references
> the same Class. That means that the cache entry, and thus the class and its
> class-loader, will not get reclaimed, unless the GC determines that memory
> pressure is
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 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 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 Mon, 15 Nov 2021 18:23:16 GMT, Philippe Marschall
wrote:
> > ```
> > 3. I made many methods just return `this` after checking for operated on
> > and closed:
> > ```
>
> Reading the Javadoc again I'm not sure this is allowed. The method Javadoc
> doesn't clearly say it but the package
On Mon, 15 Nov 2021 18:08:22 GMT, Philippe Marschall
wrote:
> I have a similar project at
> [empty-streams](https://github.com/marschall/empty-streams). A couple of
> notes:
>
> 1. I found the need for streams to be stateful. I had need for the following
> state:
>
>1. closed
>
On Fri, 12 Nov 2021 21:43:42 GMT, Roman Kennke wrote:
> The caches in ObjectStreamClass basically map WeakReference to
> SoftReference, where the ObjectStreamClass also references
> the same Class. That means that the cache entry, and thus the class and its
> class-loader, will not get
> 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
> multi-line (block) comments. Nothing in the code proper has
On Mon, 15 Nov 2021 18:01:04 GMT, Joe Darcy wrote:
> If the intent of this change is to alter the lifetimes of the objects in
> question in a meaningful way, I recommend a CSR for the behavioral
> compatibility impact.
It would be hard for application code to observe this change: before the
On Wed, 20 Oct 2021 21:57:29 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 the
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
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 to the creation of such jar's and jmod's to enable
a
On Mon, 15 Nov 2021 18:08:22 GMT, Philippe Marschall
wrote:
> 3. I made many methods just return `this` after checking for operated on
> and closed:
Reading the Javadoc again I'm not sure this is allowed. The method Javadoc
doesn't clearly say it but the package Javadoc for intermediate
On Fri, 5 Nov 2021 12:53:46 GMT, kabutz wrote:
> This is a draft proposal for how we could improve stream performance for the
> case where the streams are empty. Empty collections are common-place. If we
> iterate over them with an Iterator, we would have to create one small
> Iterator object
On Fri, 12 Nov 2021 21:43:42 GMT, Roman Kennke wrote:
> The caches in ObjectStreamClass basically map WeakReference to
> SoftReference, where the ObjectStreamClass also references
> the same Class. That means that the cache entry, and thus the class and its
> class-loader, will not get
On Mon, 15 Nov 2021 07:33:00 GMT, Martin Grigorov wrote:
>> Mandy Chung has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 43 commits:
>>
>> - fix copyright header and typo
>> - improve documentation of AccessorUtils
>> - Merge
On Fri, 5 Nov 2021 19:58:01 GMT, Alexey Semenyuk wrote:
> The fix is to isolate C++ calls in the separate forked child process on
> Linux.
> This change requires the passing of JLI command line arguments and values of
> environment variables between two processes.
This pull request has now
On Thu, 11 Nov 2021 04:07:18 GMT, Alexey Semenyuk wrote:
> 8276084: Linux DEB Bundler: release number in outputted .deb file should be
> optional
This pull request has now been integrated.
Changeset: 9046077f
Author:Alexey Semenyuk
URL:
Hi there,
OpenJDK currently supports version 2000 of the GB18030
(https://en.wikipedia.org/wiki/GB_18030) character set viz. GB18030-2000. The
character mappings corresponding to Unicode codepoints '\u1E3F' and '\uE7C7'
were swapped in a new version of the character set named GB18030-2005.
On Mon, 15 Nov 2021 02:40:14 GMT, Ichiroh Takiguchi
wrote:
>> I reproduced those failures on Debian Linux. Corrected the issue by
>> replacing unsupported jnu encoding with `UTF-8` in `System::initPhase1`.
>
> @naotoj , sorry for bothering you again.
> Still I got exception. It seems value
> 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:
Replace jnuEncoding in
The caches in ObjectStreamClass basically map WeakReference to
SoftReference, where the ObjectStreamClass also references
the same Class. That means that the cache entry, and thus the class and its
class-loader, will not get reclaimed, unless the GC determines that memory
pressure is very
> 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
> 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
> 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 Mon, 15 Nov 2021 13:56:18 GMT, Alan Bateman wrote:
> I can't quite tell if you have something that runs into the issue or whether
> you just spotted the open issue
Hello Alan,
I just happened to notice this issue in JBS and thought of checking if there's
any interest in this fix. From the
On Mon, 15 Nov 2021 13:26:30 GMT, Jaikiran Pai wrote:
> Hello Daniel, The issue is still reproducible (only) if the jar indexing is
> enabled by setting the `-Djdk.net.URLClassPath.enableJarIndex=true`
Just to add to Daniel's comment. JAR indexing has several issues, most going
back 20+
On Mon, 15 Nov 2021 13:25:01 GMT, Daniel Fuchs wrote:
> Hi Jaikiran, is this still an issue now that Jar Index is disabled by
> default? (see https://git.openjdk.java.net/jdk/pull/5524)
Hello Daniel,
The issue is still reproducible (only) if the jar indexing is enabled by
setting the
On Sun, 7 Nov 2021 06:53:12 GMT, kabutz wrote:
>>> The net effect of this change might depend on your workload. If you call
>>> stream() on empty collections that have cheap isEmpty(), this change will
>>> likely improve performance and reduce waste. However, this same change
>>> might do the
On Wed, 10 Nov 2021 07:45:27 GMT, Anthony Vanelverdinghe
wrote:
>> @kabutz I agree that i wouldn't consider it clean code to use a stream like
>> i put into the example. I only brought it up because it might break existing
>> code, since i think streams are expected to be lazy. Interesting to
On Sun, 7 Nov 2021 07:51:06 GMT, Michael Bien wrote:
>>> wouldn't this make streams no longer lazy if the collection is empty?
>>>
>>> ```java
>>> List list = new ArrayList<>();
>>> Stream stream = list.stream();
>>>
>>> list.addAll(List.of("one", "two", "three"));
>>>
On Sun, 7 Nov 2021 06:26:22 GMT, kabutz wrote:
>> (immutable collections could override stream() instead, since they don't
>> have that problem)
>
>> The net effect of this change might depend on your workload. If you call
>> stream() on empty collections that have cheap isEmpty(), this change
On Sun, 7 Nov 2021 04:26:13 GMT, Michael Bien wrote:
>> wouldn't this make streams no longer lazy if the collection is empty?
>>
>> List list = new ArrayList<>();
>> Stream stream = list.stream();
>>
>> list.addAll(List.of("one", "two", "three"));
>>
>>
On Sat, 6 Nov 2021 22:03:26 GMT, Pavel Rappo wrote:
>> This is a draft proposal for how we could improve stream performance for the
>> case where the streams are empty. Empty collections are common-place. If we
>> iterate over them with an Iterator, we would have to create one small
>>
On Sun, 7 Nov 2021 03:53:29 GMT, Michael Bien wrote:
>> src/java.base/share/classes/java/util/Collection.java line 743:
>>
>>> 741: */
>>> 742: default Stream stream() {
>>> 743: if (isEmpty()) return Stream.empty();
>>
>> The net effect of this change might depend on your
On Sat, 13 Nov 2021 16:59:10 GMT, liach wrote:
>> This is a draft proposal for how we could improve stream performance for the
>> case where the streams are empty. Empty collections are common-place. If we
>> iterate over them with an Iterator, we would have to create one small
>> Iterator
On Fri, 5 Nov 2021 12:53:46 GMT, kabutz wrote:
> This is a draft proposal for how we could improve stream performance for the
> case where the streams are empty. Empty collections are common-place. If we
> iterate over them with an Iterator, we would have to create one small
> Iterator object
On Fri, 5 Nov 2021 12:53:46 GMT, kabutz wrote:
> This is a draft proposal for how we could improve stream performance for the
> case where the streams are empty. Empty collections are common-place. If we
> iterate over them with an Iterator, we would have to create one small
> Iterator object
On Fri, 5 Nov 2021 12:53:46 GMT, kabutz wrote:
> This is a draft proposal for how we could improve stream performance for the
> case where the streams are empty. Empty collections are common-place. If we
> iterate over them with an Iterator, we would have to create one small
> Iterator object
On Sat, 6 Nov 2021 17:23:34 GMT, Pavel Rappo wrote:
> Streams are closeable, and a terminal operation may be invoked on a given
> stream only once. Thus, shouldn't the third line in both of the examples
> below throw `IllegalStateException`?
>
> ```
> Stream empty = Stream.empty();
>
On Fri, 5 Nov 2021 12:53:46 GMT, kabutz wrote:
> This is a draft proposal for how we could improve stream performance for the
> case where the streams are empty. Empty collections are common-place. If we
> iterate over them with an Iterator, we would have to create one small
> Iterator object
This is a draft proposal for how we could improve stream performance for the
case where the streams are empty. Empty collections are common-place. If we
iterate over them with an Iterator, we would have to create one small Iterator
object (which could often be eliminated) and if it is empty we
On 15/11/2021 8:14 pm, Alan Bateman wrote:
On 15/11/2021 09:48, David Holmes wrote:
I think there may be a misunderstanding here, AFAICS they are using
reflection to remove the final-ness of a field in their own classes,
not modifying anything in Class or Field.
That's the outcome. To get
On Fri, 12 Nov 2021 12:25:20 GMT, Pavel Rappo wrote:
> Please review this simple two-hunk fix to the documentation comment of
> java.util.Properties#load(java.io.Reader). The first hunk (line/lines) is a
> suggestion. I believe it reads better since the plurality is more idiomatic;
> native
On Fri, 12 Nov 2021 15:06:35 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source code in java.xml and
> java.xml.crypto. This scripts verifies that modifiers are in the "blessed"
> order, and fixes it otherwise. I have manually checked the changes made by
> the
On Fri, 12 Nov 2021 15:06:35 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source code in java.xml and
> java.xml.crypto. This scripts verifies that modifiers are in the "blessed"
> order, and fixes it otherwise. I have manually checked the changes made by
> the
On 15/11/2021 09:48, David Holmes wrote:
I think there may be a misunderstanding here, AFAICS they are using
reflection to remove the final-ness of a field in their own classes,
not modifying anything in Class or Field.
That's the outcome. To get there, they call a private method
Hi Alan,
On 15/11/2021 5:11 pm, Alan Bateman wrote:
On 14/11/2021 22:56, Claes Redestad wrote:
:
Alan: changing `Field.modifiers` still works, but dropping the final
modifier is not enough for this to work in the new impl. It won't be
hard to adapt to the new world. Users who relies on this
Hello,
the 2nd version of the article [1] accompanying this issue [2] and issue
[3] has been kindly and thoroughly reviewed by the following renowned
world-class researchers:
* Guy Steele Jr [4], Oracle Labs
* Paul Zimmermann [5], INRIA
* Jean-Michel Muller [6], Ecole Normale Supérieure de
61 matches
Mail list logo
