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
On Wed, 9 Dec 2020 08:20:38 GMT, Nick Gasson wrote:
> This is more-or-less a straight port of the x86 code to AArch64.
> GraphKit::make_native_call() calls SharedRuntime::make_native_invoker()
> to generate a blob that jumps to the native function entry point. This
> simply switches the thread
On Thu, 17 Dec 2020 02:48:38 GMT, Jesper Wilhelmsson
wrote:
> Merge JDK 16 -> JDK 17
This pull request has now been integrated.
Changeset: 11bd7a81
Author:Jesper Wilhelmsson
URL: https://git.openjdk.java.net/jdk/commit/11bd7a81
Stats: 882 lines in 41 files changed: 659 ins; 30
Merge JDK 16 -> JDK 17
-
Commit messages:
- Merge
- 8258338: Support deprecated records
- 8241353: NPE in ToolProvider.getSystemJavaCompiler
- 8255880: UI of Swing components is not redrawn after their internal state
changed
- 8257637: Update usage of "type" terminology in
On Wed, 16 Dec 2020 17:16:14 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.
>
> Brian
Back out code changes from JDK-8235812 to restore correct matching behavior.
Adjust test to comment out cases that tested for incorrect behavior.
-
Commit messages:
- 8258259: Unicode linebreak matching behavior is incorrect; backout
JDK-8235812
Changes:
On Wed, 9 Dec 2020 00:32:44 GMT, Paul Sandoz wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix typo, clarify asserts disabled, test prefGrowth==0
>
> Marked as reviewed by psandoz (Reviewer).
@Martin-Buchholz
> 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
On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote:
> This is part of an effort in the JDK to replace archaic/non-inclusive words
> with more neutral terms (see JDK-8253315 for details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as follows:
>
On Mon, 14 Dec 2020 09:11:31 GMT, Hannes Wallnöfer 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 Wed, 16 Dec 2020 20:08:11 GMT, Brent Christian wrote:
>> This is part of an effort in the JDK to replace archaic/non-inclusive words
>> with more neutral terms (see JDK-8253315 for details).
>>
>> Here are the changes covering core libraries code and tests. Terms were
>> changed as
On Wed, 16 Dec 2020 19:57:32 GMT, Joel Borggrén-Franck
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.
what about declaring a static final field for that value instead
On Fri, 2 Oct 2020 15:18:04 GMT, Roger Riggs wrote:
> java.util.HexFormat utility:
>
> - Format and parse hexadecimal strings, with parameters for delimiter,
> prefix, suffix and upper/lowercase
> - Static factories and builder methods to create HexFormat copies with
> modified parameters.
> This is part of an effort in the JDK to replace archaic/non-inclusive words
> with more neutral terms (see JDK-8253315 for details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or
On Wed, 16 Dec 2020 07:10:41 GMT, Alan Bateman wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> improve SERIAL_FILTER_PATTERN comment
>
> src/java.base/share/classes/java/util/Locale.java line 1649:
>
>> 1647:
On Wed, 16 Dec 2020 16:26:37 GMT, Vicente Romero wrote:
>> 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
>>
On Wed, 16 Dec 2020 18:27:35 GMT, Aleksei Efimov wrote:
>> Let's take advantage of "flow scoping" to eliminate some of these casts. A
>> few examples follow.
>
> Hi Andrey,
>
> Could you, please, also take a look at `java.net.Socket`:
> java/net/Socket.java:if (bindpoint != null &&
On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `characterdata`, `charsetmapping`,
On Wed, 16 Dec 2020 09:44:37 GMT, Chris Hegarty 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
>> use instanceof pattern
On Wed, 16 Dec 2020 17:16:14 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.
>
> Brian
On Mon, 14 Dec 2020 07:52:14 GMT, Nick Gasson wrote:
>> This is more-or-less a straight port of the x86 code to AArch64.
>> GraphKit::make_native_call() calls SharedRuntime::make_native_invoker()
>> to generate a blob that jumps to the native function entry point. This
>> simply switches the
> 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.
Brian Burkhalter has updated the pull request incrementally with one
On Wed, 16 Dec 2020 14:52:39 GMT, Roger Riggs wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8248383: Re-indent subclasses in @see tages
>
> test/jdk/java/io/Reader/ReadIntoZeroLengthArray.java line 39:
>
>>
On Fri, Dec 11, 2020 at 5:35 PM Brian Burkhalter
wrote:
>
> Hello,
>
> ...
>
>
> I think perhaps they could all go in the same PR as the things are quite
> related. It would be good to have simple JMH benchmarks to measure the
> improvements. The benchmark code does not necessarily have to be
On Wed, 16 Dec 2020 09:41:47 GMT, Joel Borggrén-Franck
wrote:
> 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
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 expression),
On Thu, 10 Dec 2020 23:36:13 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.
>
> Brian
On Mon, 14 Dec 2020 19:36:45 GMT, Roger Riggs 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 applications are
On Wed, 16 Dec 2020 10:12:54 GMT, Alan Bateman wrote:
>> I think this is almost ready to be pushed, but I'd like to have someone from
>> the client team review the changes for java.desktop as well. @prrace Any
>> change you can have a look at this?
>
> I think it will be annoying to have the
Hi,
JDK-8211825 is backported to 11.0.11-oracle. I'd like to backport it for parity.
The original change applies cleanly, by javac from 11u has a problem with the
new AutomaticModulesTest:
AutomaticModulesTest.java:70: error: reference to createJarFile is ambiguous
On Tue, 15 Dec 2020 19:28:15 GMT, Julia Boes wrote:
> This change is in line 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
>
> For easier
> This change is in line 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
>
> For easier reviewing, paragraphs will only be reflowed before the
> 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
take
On Tue, 15 Dec 2020 22:52:30 GMT, Magnus Ihse Bursie wrote:
>> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`,
>> `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good
>> overall.
>
> I think this is almost ready to be pushed, but I'd like to have
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
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
> additional commit since the last revision:
>
> 8258422: Cleanup
On Fri, 27 Nov 2020 22:37:18 GMT, Rafael Winterhalter
wrote:
>> @raphw can you take a look at this?
>
> I just ran it a bit and this seems right to me. I just had an error reported
> in relation to this and I think this is fixed by your changes, too.
>
On Tue, 24 Nov 2020 15:54:47 GMT, Joel Borggrén-Franck
wrote:
> The fix for JDK-8256693 too often produces a ParameterizedType as the result
> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary
> when this type or any of its transitive owner types has type parameters,
> 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
use
39 matches
Mail list logo
