On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov
wrote:
>> 8258422: Cleanup unnecessary null comparison before instanceof check in
>> java.base
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8258422: Cleanup unnecess
On Wed, 16 Dec 2020 21:21:19 GMT, Vicente Romero wrote:
>> Yes, not great, but at least it isn't brittle when running the test, only
>> when changing it. I'd like to take a separate pass over the tests for 17 if
>> possible.
>
>> Yes, not great, but at least it isn't brittle when running the te
> The fix for JDK-8256693 too often produces a ParameterizedType as the result
> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary
> only when this type or any of its transitive owner types has type parameters,
> but should be avoided if this isn't the case.
>
> This im
Hello, I feel like this was previously discussed in
https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find
original mail I post this here.
Currently `Collections.addAll()` is implemented and documented as:
/**
* ...
* The behavior of this convenience method
On Mon, 14 Dec 2020 12:13:23 GMT, Сергей Цыпанов
wrote:
> Hello, I feel like this was previously discussed in
> https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot
> find original mail I post this here.
>
> Currently `Collections.addAll()` is implemented and documented a
On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov
wrote:
>> 8258422: Cleanup unnecessary null comparison before instanceof check in
>> java.base
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8258422: Cleanup unnecess
> Hello, I feel like this was previously discussed in
> https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot
> find original mail I post this here.
>
> Currently `Collections.addAll()` is implemented and documented as:
> /**
> * ...
> * The behavior of this con
On Thu, 17 Dec 2020 10:33:05 GMT, Сергей Цыпанов
wrote:
>> Hello, I feel like this was previously discussed in
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot
>> find original mail I post this here.
>>
>> Currently `Collections.addAll()` is implemented and documen
On Thu, 17 Dec 2020 10:15:23 GMT, Сергей Цыпанов
wrote:
>> Hello, I feel like this was previously discussed in
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot
>> find original mail I post this here.
>>
>> Currently `Collections.addAll()` is implemented and documen
> Another change to align with upcoming changes in the JLS terminology ('type'
> versus 'class and interface').
>
> For background see:
> https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html
>
> Where a class models types (as in the type of a variable or an ex
On Thu, 17 Dec 2020 10:34:38 GMT, Rémi Forax
wrote:
>> Сергей Цыпанов has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains one commit:
>>
>> 8193031: add elements in bulk in Collections.addAll()
>
> src/java.base/share/classes/java/
On Thu, 17 Dec 2020 10:45:17 GMT, Сергей Цыпанов
wrote:
>> src/java.base/share/classes/java/util/Collections.java line 5589:
>>
>>> 5587: */
>>> 5588: @SafeVarargs
>>> 5589: @SuppressWarnings("varargs")
>>
>> I don't think you need a SuppressWarnings here
>
> Hi, without this I ge
On Thu, 17 Dec 2020 10:50:01 GMT, Rémi Forax
wrote:
>> Hi, without this I get failed build:
>> Compiling 3057 files for java.base
>> Compiling 89 properties into resource bundles for java.desktop
>>
>> return c.addAll(Arrays.asList(elements));
>> ^
On Thu, 17 Dec 2020 11:03:45 GMT, Сергей Цыпанов
wrote:
>> ok, it means there is a bug in the compiler, the analysis done for unsafe
>> varargs (with -Xlint:varargs) doesn't check that the called method (here
>> Arrays.asList()) is tagged with @SafeVarargs.
>
> Should I then wait for the fix o
On Wed, 16 Dec 2020 15:17:57 GMT, Julia Boes wrote:
> Another change to align with upcoming changes in the JLS terminology ('type'
> versus 'class and interface').
>
> For background see:
> https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html
>
> Where a cla
On Thu, 17 Dec 2020 10:29:50 GMT, Alan Bateman wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8258422: Cleanup unnecessary null comparison before instanceof check in
>> java.base
>> take advantage of "flow s
Hi all,
java/util/HexFormat/HexFormatTest.java fails on x86_32 due to '-Xmx4G'.
The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms.
The current implementation only supports maximum 3800M on 32-bit systems [1].
I've tried to reduce the -Xmx size, but it still fails even wi
On Wed, 16 Dec 2020 00:24:20 GMT, Alexey Semenyuk wrote:
> Ignore files created by prefs subsystem when checking if source runtime
> contains the same files as packed runtime.
Marked as reviewed by herrick (Reviewer).
-
PR: https://git.openjdk.java.net/jdk16/pull/31
On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov
wrote:
>> 8258422: Cleanup unnecessary null comparison before instanceof check in
>> java.base
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8258422: Cleanup unnecess
On Thu, 17 Dec 2020 11:35:26 GMT, Andrey Turbanov
wrote:
>> src/java.base/share/classes/jdk/internal/misc/Signal.java line 102:
>>
>>> 100: */
>>> 101: public boolean equals(Object other) {
>>> 102: if (this == other) {
>>
>> It might be a bit cleaner to rename Object other to
On Thu, 17 Dec 2020 13:32:06 GMT, Daniel Fuchs wrote:
>> Actually, I'm not sure if `oth` is better name for variable than `other1`.
>> I would say they have the same rank :)
>
> I believe Alan is suggesting to do:
>
> /**
> * Compares the equality of two Signal objects.
> *
>
Hi Martin,
this makes sense. Thanks for doing the backport.
Best regards
Christoph
> -Original Message-
> From: core-libs-dev On Behalf Of
> Doerr, Martin
> Sent: Mittwoch, 16. Dezember 2020 14:39
> To: core-libs-dev ; jdk-updates-
> d...@openjdk.java.net
> Subject: [CAUTION] [11u] RFR:
> The ByteBuffers micro benchmark seems to be a little dated.
>
> It should be a useful resource to leverage when analysing the performance
> impact of any potential implementation changes in the byte buffer classes.
> More specifically, the impact of such changes on the performance of sharp
>
> 8258422: Cleanup unnecessary null comparison before instanceof check in
> java.base
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8258422: Cleanup unnecessary null comparison before instanceof check in
java.base
On Thu, 17 Dec 2020 14:01:14 GMT, Andrey Turbanov
wrote:
>> 8258422: Cleanup unnecessary null comparison before instanceof check in
>> java.base
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8258422: Cleanup unnecess
When updating this, might you take the opportunity to remove the ambiguous
antecedent too? The use of "this method" when there are two methods in the
discussion (Collections.addAll, and the proximate one; Collection.addAll)
is unclear (indeed, one could argue the original text might have intended
t
Hi,
Please find an almost trivial fix for:
8258582: HttpClient: the HttpClient doesn't explicitely shutdown its default
executor when stopping.
The HttpClient should shutdown his executor when stopping, when the executor
was created by the HttpClient itself.
best regards,
-- daniel
-
On Wed, 16 Dec 2020 00:24:20 GMT, Alexey Semenyuk wrote:
> Ignore files created by prefs subsystem when checking if source runtime
> contains the same files as packed runtime.
This pull request has now been integrated.
Changeset: 61cbf0ff
Author:Alexey Semenyuk
URL: https://git.open
Hi Christoph,
thanks for the review!
Best regards,
Martin
> -Original Message-
> From: Langer, Christoph
> Sent: Donnerstag, 17. Dezember 2020 14:45
> To: Doerr, Martin ; core-libs-dev d...@openjdk.java.net>; jdk-updates-...@openjdk.java.net
> Subject: RE: [11u] RFR: 8211825: ModuleLa
On Thu, 17 Dec 2020 12:11:33 GMT, Jie Fu wrote:
> Hi all,
>
> java/util/HexFormat/HexFormatTest.java fails on x86_32 due to '-Xmx4G'.
> The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms.
> The current implementation only supports maximum 3800M on 32-bit systems [1].
>
> jaxp.library.SimpleHttpServer
> https://bugs.openjdk.java.net/browse/JDK-8212035
Mahendra Chhipa has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains seven commits:
- Implemented the Review comments.
- Implemented the review comments
On Mon, 14 Dec 2020 19:44:59 GMT, Daniel Fuchs wrote:
>> Mahendra Chhipa has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into
>> JDK-8212035
>> - Implemnted the revi
On Thu, 10 Dec 2020 17:22:06 GMT, Brian Burkhalter wrote:
> Please review this small verbiage change to specify clearly the behavior of
> `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of
> `Reader::read(char[] cbuf, int off, int len)` when `len` is zero.
This pull req
On Thu, 17 Dec 2020 14:51:44 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find an almost trivial fix for:
> 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default
> executor when stopping.
>
> The HttpClient should shutdown his executor when stopping, when the executor
> was
> This is for JDK16, as a precursor to fixing JDK-8258002.
>
> While it is good to be using localized strings in the generated output, the
> significance for JDK-8258002 is that the strings are now obtained from a
> resource file, and not hardcoded in JavaScript file itself.
>
> The source file
Please review this change moving lookup of MD5 digest in `java.lang.UUID` to an
internal holder class.
-
Commit messages:
- 8258588: MD5 MessageDigest in java.util.UUID should be cached
Changes: https://git.openjdk.java.net/jdk/pull/1821/files
Webrev: https://webrevs.openjdk.java.
On Thu, 17 Dec 2020 16:39:17 GMT, Jonathan Gibbons wrote:
>> This is for JDK16, as a precursor to fixing JDK-8258002.
>>
>> While it is good to be using localized strings in the generated output, the
>> significance for JDK-8258002 is that the strings are now obtained from a
>> resource file,
On Thu, 17 Dec 2020 01:01:38 GMT, Stuart Marks wrote:
> Back out code changes from JDK-8235812 to restore correct matching behavior.
> Adjust test to comment out cases that tested for incorrect behavior.
Backout and test changes according to it look good to me.
-
Marked as reviewe
On Thu, 17 Dec 2020 17:10:10 GMT, Jonathan Gibbons wrote:
>> This is for JDK16, as a precursor to fixing JDK-8258002.
>>
>> While it is good to be using localized strings in the generated output, the
>> significance for JDK-8258002 is that the strings are now obtained from a
>> resource file,
On Thu, 17 Dec 2020 16:24:10 GMT, Mahendra Chhipa
wrote:
>> jaxp.library.SimpleHttpServer
>> https://bugs.openjdk.java.net/browse/JDK-8212035
>
> Mahendra Chhipa has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains seven commits:
>
>
> This is for JDK16, as a precursor to fixing JDK-8258002.
>
> While it is good to be using localized strings in the generated output, the
> significance for JDK-8258002 is that the strings are now obtained from a
> resource file, and not hardcoded in JavaScript file itself.
>
> The source file
On Wed, 16 Dec 2020 14:42:36 GMT, Richard Fussenegger
wrote:
> > There is very little value in adding the exception doing so might prevent
> > existing applications from continuing to function.
>
> I disagree on the value and am with the author of the original issue. All
> these existing appl
> On Dec 16, 2020, at 1:47 AM, Chris Hegarty wrote:
>
> On Wed, 16 Dec 2020 09:20:09 GMT, Andrey Turbanov
> wrote:
>
>>> 8258422: Cleanup unnecessary null comparison before instanceof check in
>>> java.base
>>
>> Andrey Turbanov has updated the pull request incrementally with one
>> addi
> 8258422: Cleanup unnecessary null comparison before instanceof check in
> java.base
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8258422: Cleanup unnecessary null comparison before instanceof check in
java.base
rename 'oth
> 8258422: Cleanup unnecessary null comparison before instanceof check in
> java.base
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8258422: Cleanup unnecessary null comparison before instanceof check in
java.base
rename 'oth
On Thu, 17 Dec 2020 14:51:44 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find an almost trivial fix for:
> 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default
> executor when stopping.
>
> The HttpClient should shutdown his executor when stopping, when the executor
> was
On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons wrote:
> This is for JDK16, as a precursor to fixing JDK-8258002.
>
> While it is good to be using localized strings in the generated output, the
> significance for JDK-8258002 is that the strings are now obtained from a
> resource file, and n
On Thu, 17 Dec 2020 20:38:45 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 16 -> JDK 17
This pull request has now been integrated.
Changeset: f15528eb
Author:Jesper Wilhelmsson
URL: https://git.openjdk.java.net/jdk/commit/f15528eb
Stats: 773 lines in 63 files changed: 449 ins
Forwardport JDK 16 -> JDK 17
-
Commit messages:
- Merge
- 8247994: Localize javadoc search
- 8258515: javac should issue an error if an annotation is nested in a local
class or interface
- 8258225: compiler/c2/cr6340864/TestIntVect.java runs faster in interpreter
- 8258293: tool
Remove all non final static variables in jpackage java code (using
InheritableThreadLocal for Logger and Argument instances) and remove
sychronization in JPackageToolProvider.
-
Commit messages:
- JDK-8223322: Improve concurrency in jpackage instances
- JDK-8223322: Improve concur
> Please review this change moving lookup of MD5 digest in `java.lang.UUID` to
> an internal holder class.
PROgrm_JARvis has updated the pull request incrementally with one additional
commit since the last revision:
8258588: add missing " UUIDs" to comment of UUID$Md5Digest
-
Ch
On Thu, 17 Dec 2020 17:18:37 GMT, Lance Andersen wrote:
>>> There is very little value in adding the exception doing so might prevent
>>> existing applications from continuing to function.
>>
>> I disagree on the value and am with the author of the original issue. All
>> these existing applica
On Thu, 17 Dec 2020 22:07:36 GMT, Richard Fussenegger
wrote:
>>> > There is very little value in adding the exception doing so might prevent
>>> > existing applications from continuing to function.
>>>
>>> I disagree on the value and am with the author of the original issue. All
>>> these exi
On Thu, 17 Dec 2020 14:51:44 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find an almost trivial fix for:
> 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default
> executor when stopping.
>
> The HttpClient should shutdown his executor when stopping, when the executor
> was
Hi Johannes,
I'm glad to see this prototype. Converting dynamic proxy to hidden
classes has a few challenges as JDK-8242888 describes.
1) the serialization specification w.r.t. dynamic proxies
We need to look into the implication to the specification and whether
the default serialization me
On Thu, 17 Dec 2020 20:46:50 GMT, Andy Herrick wrote:
> Remove all non final static variables in jpackage java code (using
> InheritableThreadLocal for Logger and Argument instances) and remove
> sychronization in JPackageToolProvider.
Changes looks fine, but are we sure that external 3rd part
On Thu, 17 Dec 2020 20:46:50 GMT, Andy Herrick wrote:
> Remove all non final static variables in jpackage java code (using
> InheritableThreadLocal for Logger and Argument instances) and remove
> sychronization in JPackageToolProvider.
Changes requested by asemenyuk (Committer).
test/jdk/tool
On Thu, 17 Dec 2020 20:46:50 GMT, Andy Herrick wrote:
> Remove all non final static variables in jpackage java code (using
> InheritableThreadLocal for Logger and Argument instances) and remove
> sychronization in JPackageToolProvider.
test/jdk/tools/jpackage/share/ConcurrentTest.java line 68:
On Thu, 17 Dec 2020 23:24:02 GMT, Alexey Semenyuk wrote:
>> Remove all non final static variables in jpackage java code (using
>> InheritableThreadLocal for Logger and Argument instances) and remove
>> sychronization in JPackageToolProvider.
>
> Changes requested by asemenyuk (Committer).
I'd
On Thu, 17 Dec 2020 01:01:38 GMT, Stuart Marks wrote:
> Back out code changes from JDK-8235812 to restore correct matching behavior.
> Adjust test to comment out cases that tested for incorrect behavior.
This pull request has now been integrated.
Changeset: cbc3feeb
Author:Stuart Marks
UR
Now that class data support for hidden classes in master, I decided to
tackle JDK-8229959 again.
JDK-8229959: Convert proxy class to use constant dynamic [1]
JDK-8242888: Convert dynamic proxy to hidden classes [2]
The idea is simple: Define proxies as hidden classes, pass the methods
as class
The java.io.File has a toURI() API which returns a (system dependent)
URI as per its javadoc. The java.io.File also has a toPath() API which
then exposes a toUri() API from the java.nio.file.Path. The javadoc of
the File class doesn't specify any semantics about the toUri() returned
by the java
Thanks Mandy,
Appreciate your feedback, as always.
On 18-Dec-20 0:01, Mandy Chung wrote:
Hi Johannes,
I'm glad to see this prototype. Converting dynamic proxy to hidden
classes has a few challenges as JDK-8242888 describes.
1) the serialization specification w.r.t. dynamic proxies
Seri
On 12/8/20 5:30 AM, Remi Forax wrote:
De: "Dave Franken"
Adding methods like notContains or notFilter have been considered several times
in the past and rejected because it's too many methods with no real gain. I'm
sure you can dig some old emails on lambda-dev and see the first iteration
64 matches
Mail list logo
