This change introduces a new terminal operation on Stream. This looks like a
convenience method for Stream.collect(Collectors.toList()) or
Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
method directly on Stream enables it to do what can't easily by done by a
Collect
> This patch set encompasses the following commits:
>
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class -
> decodeBlock(), and provides a flexible API for the intrinsic. The API is
> similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and
On Mon, 26 Oct 2020 19:22:23 GMT, Paul Murphy
wrote:
>> Just to make sure I understand, you're not asking for a change here, is that
>> right?
>
> I think the first line should also express the initial layout of the 6 bit
> values similar to the linked algo. I think changing this comment add
> This patch set encompasses the following commits:
>
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class -
> decodeBlock(), and provides a flexible API for the intrinsic. The API is
> similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and
On Sat, 24 Oct 2020 21:38:55 GMT, CoreyAshford
wrote:
>> Yes, it assumes uniformly random data, but also recall that the unencoded
>> data bytes get shifted by 2, 4, 6 bits into the encoded bytes, which I'm
>> guessing would tend to make the data somewhat more uniform, even if the
>> source d
On Tue, 3 Nov 2020 00:00:26 GMT, Kiran Sidhartha Ravikumar
wrote:
>> My question is why it is failing. Have you figured it? The existing
>> exceptions are either negative DST or last rule beyond 2037, which javazic
>> cannot handle. The changes introduced with 2020d does not meet either of
>>
InputStream::readNBytes() invokes read(byte[],int,int) repeatedly to load bytes
into a sequence of intermediate arrays. If an intermediate array is not
completely filled before being added to the list of arrays the contents of
which are eventually concatenated to produce the result, then the unf
On Mon, 2 Nov 2020 18:14:47 GMT, Naoto Sato wrote:
>> It's probably these last rule what is causing the issue
>>
>> Rule Palestine 2020max - Mar Sat>=24 0:001:00
>> S
>> Rule Palestine 2020max - Oct Sat>=24 1:000
>> -
>>
>> The
On Mon, 2 Nov 2020 17:08:10 GMT, Stephen Colebourne
wrote:
>> src/java.base/share/classes/java/time/format/Parsed.java line 497:
>>
>>> 495: AMPM_OF_DAY.checkValidValue(ap);
>>> 496: }
>>> 497: updateCheckDayPeriodConflict(AMPM_OF_
On Mon, 2 Nov 2020 17:05:40 GMT, Stephen Colebourne
wrote:
>> MINUTE_OF_HOUR without HOUR_OF_DAY/HOUR_OF_AMPM may not make any sense, so
>> it is only validated in updateCheckDayPeriodConflict.
>
> But can you get a CLDR rule that says "at night" before 05:30 and "In the
> morning" from 05:30
> Hi,
>
> Please review the changes for the subject issue. This is to enhance the
> java.time package to support day periods, such as "in the morning", defined
> in CLDR. It will add a new pattern character 'B' and its supporting builder
> method. The motivation and its spec are in this CSR:
>
On Mon, 2 Nov 2020 17:27:35 GMT, Stephen Colebourne
wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed exception messages.
>
> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java
> line 65
On Tue, 27 Oct 2020 16:09:45 GMT, Jan Lahoda wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java
>> line 88:
>>
>>> 86:
>>> 87: @Override
>>> 88: protected Content getDeprecatedOrPreviewLink(Element member) {
>>
>> This
On Fri, 16 Oct 2020 16:07:41 GMT, Maurizio Cimadamore
wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 46 commits:
>>
>> - Removing trailing whitespace.
>> - Merging master into JDK-8250768.
>> - Updating t
On Mon, 2 Nov 2020 18:15:09 GMT, Jan Lahoda wrote:
>> This is an update to javac and javadoc, to introduce support for Preview
>> APIs, and generally improve javac and javadoc behavior to more closely
>> adhere to JEP 12.
>>
>> The notable changes are:
>>
>> * adding support for Preview APIs
On Mon, 2 Nov 2020 17:33:57 GMT, Lance Andersen wrote:
> Please review this fix for JDK-8255529 which removes methods that were unused
> and were added back merge in July
>
> Mach5 jdk-tier1, jdk-tier2, jdk-tier3 ran clean.
This pull request has now been integrated.
Changeset: 05bcd67e
Author
On Mon, 2 Nov 2020 18:06:28 GMT, Kiran Sidhartha Ravikumar
wrote:
>> test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 201:
>>
>>> 199: zid.equals("Iran") || // last rule mismatch
>>> 200: zid.equals("Asia/Gaza") || // last rule mismatch
>>> 201:
> This is an update to javac and javadoc, to introduce support for Preview
> APIs, and generally improve javac and javadoc behavior to more closely adhere
> to JEP 12.
>
> The notable changes are:
>
> * adding support for Preview APIs (javac until now supported primarily only
> preview langua
On Mon, 2 Nov 2020 17:33:57 GMT, Lance Andersen wrote:
> Please review this fix for JDK-8255529 which removes methods that were unused
> and were added back merge in July
>
> Mach5 jdk-tier1, jdk-tier2, jdk-tier3 ran clean.
Marked as reviewed by redestad (Reviewer).
-
PR: https:/
On Mon, 2 Nov 2020 17:10:34 GMT, Naoto Sato wrote:
>> Hi Guys,
>>
>> Please review the integration of tzdata2020d to JDK.
>>
>> Details regarding the change can be viewed at -
>> https://mm.icann.org/pipermail/tz-announce/2020-October/62.html
>> Bug: https://bugs.openjdk.java.net/browse/JD
On 10/26/20 12:47 PM, Paul Murphy wrote:
On Thu, 22 Oct 2020 22:06:11 GMT, CoreyAshford
wrote:
src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3878:
3876: // |Element| | |
| | |
On Mon, 2 Nov 2020 17:33:57 GMT, Lance Andersen wrote:
> Please review this fix for JDK-8255529 which removes methods that were unused
> and were added back merge in July
>
> Mach5 jdk-tier1, jdk-tier2, jdk-tier3 ran clean.
Looks good to me.
-
Marked as reviewed by naoto (Reviewe
On Thu, 29 Oct 2020 09:26:05 GMT, Jan Lahoda wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java
>> line 1288:
>>
>>> 1286: case FIELD: case INSTANCE_INIT: case LOCAL_VARIABLE:
>>> case PARAMETER:
>>> 1287: case RESOURCE_VARIABLE
On Thu, 29 Oct 2020 09:43:56 GMT, Jan Lahoda wrote:
>> I don't think there should be much interaction with -source .
>> We don't support preview features from previous version or preview class
>> files from previous versions, so I think it should be enough to handle the
>> currently present pr
On Fri, 30 Oct 2020 22:03:08 GMT, Naoto Sato wrote:
>> Hi,
>>
>> Please review the changes for the subject issue. This is to enhance the
>> java.time package to support day periods, such as "in the morning", defined
>> in CLDR. It will add a new pattern character 'B' and its supporting builder
On Fri, 30 Oct 2020 11:06:59 GMT, Stephen Colebourne
wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed exception messages.
>
> src/java.base/share/classes/java/time/format/Parsed.java line 497:
>
>> 495:
On Fri, 30 Oct 2020 21:30:50 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/time/format/Parsed.java line 472:
>>
>>> 470: }
>>> 471: if (dayPeriod != null) {
>>> 472: if (fieldValues.containsKey(HOUR_OF_DAY)) {
>>
>> Are we certain that the CLDR data does
Please review this fix for JDK-8255529 which removes methods that were unused
and were added back merge in July
Mach5 jdk-tier1, jdk-tier2, jdk-tier3 ran clean.
-
Commit messages:
- Remove unused methods
Changes: https://git.openjdk.java.net/jdk/pull/1015/files
Webrev: https://we
On Mon, 2 Nov 2020 16:29:07 GMT, Kiran Sidhartha Ravikumar
wrote:
> Hi Guys,
>
> Please review the integration of tzdata2020d to JDK.
>
> Details regarding the change can be viewed at -
> https://mm.icann.org/pipermail/tz-announce/2020-October/62.html
> Bug: https://bugs.openjdk.java.net/
On Fri, 30 Oct 2020 22:23:30 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this simple message fix that follows JDK-8255242.
>
> Naoto
This pull request has now been integrated.
Changeset: 6dac8d27
Author:Naoto Sato
URL: https://git.openjdk.java.net/jdk/commit/6dac8d27
Stats:
Hi Guys,
Please review the integration of tzdata2020d to JDK.
Details regarding the change can be viewed at -
https://mm.icann.org/pipermail/tz-announce/2020-October/62.html
Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
TestZoneInfo310.java test failure is addressed along with it. T
This change add 3 new methods in Objects:
public static long checkIndex(long index, long length)
public static long checkFromToIndex(long fromIndex, long toIndex, long length)
public static long checkFromIndexSize(long fromIndex, long size, long length)
This mirrors the int utility methods that w
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation (see JEP 393 [1]). This iteration
> focus on improving the usability of the API in 3 main ways:
>
> * first, by providing a way to obtain truly *shared* segments, which can
On Mon, 2 Nov 2020 11:59:09 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the third incubation round
>> of the foreign memory access API incubation (see JEP 393 [1]). This
>> iteration focus on improving the usability of the API in 3 main ways:
>>
>> * fi
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation (see JEP 393 [1]). This iteration
> focus on improving the usability of the API in 3 main ways:
>
> * first, by providing a way to obtain truly *shared* segments, which can
On Sun, 1 Nov 2020 16:06:32 GMT, Alan Bateman wrote:
> The javadoc for copyFrom isn't changed in this update but I notice it
> specifies IndexOutOfBoundException when the source segment is larger than the
> receiver, have other exceptions been examined?
This exception is consistent with other
> Hi,
>
> This patch adds an asExact() combinator to VarHandle, that will return a new
> VarHandle that performs exact type checks, similar to
> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
> which can lead to performance degradation.
>
> This is implemented usi
On Sun, 1 Nov 2020 16:06:32 GMT, Alan Bateman wrote:
> Now that MemorySegment is AutoCloseable then maybe the term "alive" should be
> replaced with "open" or "closed" and isAlive replaced with isOpen is isClosed.
While the reason for the method being called "isAlive" are mostly historical
(th
On Wed, 16 Sep 2020 07:57:30 GMT, Jan Lahoda wrote:
> Unqualified Elements.getTypeElement(CharSequence) and
> Elements.getPackageElement(CharSequence) search for elements across all
> modules in the module graph, and only return a value when they find exactly
> one element. This is troublesome
> Unqualified Elements.getTypeElement(CharSequence) and
> Elements.getPackageElement(CharSequence) search for elements across all
> modules in the module graph, and only return a value when they find exactly
> one element. This is troublesome, as an element (uniquely) visible from a
> root modu
40 matches
Mail list logo
