I realized after sending that option 2 can be made more abstract:
default > R to(Function function)
{
return function.apply((T[]) this.toArray());
}
>
> 2. Pass the result of toArray directly into a function that can then return a
> Collection. This should work with Set.of, List.of and any
Hi all,
I’d like to propose adding one or two of the following methods on Stream to
cover more surface area of the Collections ecosystem, without requiring a big
increase in the size of the Stream interface. Apologies if this has come up for
discussion before.
1. Stream contents into a
> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to
> Java-based JIT compiler (Graal) from JDK:
>
> - `jdk.internal.vm.compiler` — the Graal compiler
> - `jdk.internal.vm.compiler.management` — Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` — Graal's
On 4/25/21 11:09 AM, Peter Levart wrote:
When making this proposition, I was only thinking of how to enable new
yet-nonexistent operations on collections that have order / are reversible and that
the code calling these methods would already knows that it is dealing with ordered /
reversible
> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to
> Java-based JIT compiler (Graal) from JDK:
>
> - `jdk.internal.vm.compiler` — the Graal compiler
> - `jdk.internal.vm.compiler.management` — Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` — Graal's
On Mon, 26 Apr 2021 14:27:49 GMT, Maurizio Cimadamore
wrote:
>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI. The differences are outlined in [1]. In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either
On Tue, 27 Apr 2021 02:07:50 GMT, Nick Gasson wrote:
>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/aapcs/AapcsLinker.java
>> line 50:
>>
>>> 48: * the ARM 64-bit Architecture".
>>> 49: */
>>> 50: public class AapcsLinker implements CLinker {
>>
>> I see why
On Mon, 26 Apr 2021 14:29:43 GMT, Maurizio Cimadamore
wrote:
>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI. The differences are outlined in [1]. In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either
Please consider this request to correct a minor problem with the optimization
added for JDK-4926314. The change is to attempt to read the number of elements
remaining in the target buffer unless that number is non-positive in which case
read zero. The test addition fails without and passes with
On Thu, 8 Apr 2021 15:23:52 GMT, Vladimir Kozlov wrote:
> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to
> Ahead-of-Time Compiler from JDK:
>
> - `jdk.aot` module — the `jaotc` tool
> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution
>
On Mon, 26 Apr 2021 01:17:43 GMT, Hamlin Li wrote:
> code like below will create Deflater before null check, although it's not a
> real mem leak, but it's better to do null check before new Deflater.
>
> try {
> DeflaterOutputStream dos = new DeflaterOutputStream(null);
>
On Mon, 26 Apr 2021 14:55:57 GMT, Lance Andersen wrote:
> Hi Hamlin,
>
> The change looks fine. Please add the noreg-trivial change to the issue given
> there is not a test update for this so that you do not get pinged by a bot
Hi Lance, Thanks for reminding.
Thanks @LanceAndersen @naotoj
8260560: convert jdeps and jdeprscan tools to use Stream.toList()
-
Commit messages:
- Updating jdeps and jdeprscan to use Stream.toList()
Changes: https://git.openjdk.java.net/jdk/pull/3705/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3705=00
Issue:
> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to
> Ahead-of-Time Compiler from JDK:
>
> - `jdk.aot` module — the `jaotc` tool
> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution
> - related HotSpot code guarded by `#if INCLUDE_AOT`
>
>
On Thu, 22 Apr 2021 16:00:32 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang wrote:
>> The JDK codebase re-created many variants of checkIndex(`grep -I -r
>> 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which
>> annotated with @IntrinsicCandidate and it only has a corresponding C1
>> intrinsic version.
On Mon, 26 Apr 2021 02:36:54 GMT, Hamlin Li wrote:
>> code like below will create Deflater before null check, although it's not a
>> real mem leak, but it's better to do null check before new Deflater.
>>
>> try {
>> DeflaterOutputStream dos = new
On Thu, 31 Dec 2020 10:10:56 GMT, Philippe Marschall
wrote:
> Implement three optimiztations for Reader.read(CharBuffer)
>
> * Add a code path for heap buffers in Reader#read to use the backing array
> instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read
On Mon, 26 Apr 2021 09:33:03 GMT, Pavel Rappo wrote:
> I had been looking for an example of a "properties" file when spotted a typo
> in `logging.properties`. I decided to proofread the file. That resulted in
> finding a few other issues.
This pull request has now been integrated.
Changeset:
On Sun, 25 Apr 2021 10:38:03 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in
On Mon, 26 Apr 2021 15:48:18 GMT, Mark Reinhold wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rollback "in" -> "with"; remove more trailing whitespace
>
> src/java.logging/share/conf/logging.properties line 5:
>
On Mon, 26 Apr 2021 17:14:29 GMT, Pavel Rappo wrote:
>> I had been looking for an example of a "properties" file when spotted a typo
>> in `logging.properties`. I decided to proofread the file. That resulted in
>> finding a few other issues.
>
> Pavel Rappo has updated the pull request
On Mon, 26 Apr 2021 17:14:29 GMT, Pavel Rappo wrote:
>> I had been looking for an example of a "properties" file when spotted a typo
>> in `logging.properties`. I decided to proofread the file. That resulted in
>> finding a few other issues.
>
> Pavel Rappo has updated the pull request
On Mon, 26 Apr 2021 17:14:29 GMT, Pavel Rappo wrote:
>> I had been looking for an example of a "properties" file when spotted a typo
>> in `logging.properties`. I decided to proofread the file. That resulted in
>> finding a few other issues.
>
> Pavel Rappo has updated the pull request
> I had been looking for an example of a "properties" file when spotted a typo
> in `logging.properties`. I decided to proofread the file. That resulted in
> finding a few other issues.
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
There was a regression introduced in JDK 15 of jpackage tool on Windows.
The file permission of the built EXE has changed. The file is now ReadOnly.
Both EXE and MSI was ReadWrite, now
EXE is Read-Only while MSI is still Read-Write
The EXE can no longer be signed because it cannot be modified.
I
On Mon, 26 Apr 2021 09:33:03 GMT, Pavel Rappo wrote:
> I had been looking for an example of a "properties" file when spotted a typo
> in `logging.properties`. I decided to proofread the file. That resulted in
> finding a few other issues.
Otherwise, these changes look fine.
On Mon, 26 Apr 2021 09:33:03 GMT, Pavel Rappo wrote:
> I had been looking for an example of a "properties" file when spotted a typo
> in `logging.properties`. I decided to proofread the file. That resulted in
> finding a few other issues.
Thanks, Daniel. Let's maybe wait for one more reviewer
Hi Lin,
Sorry for not replying earlier, I thought I had.
I believe we should still flush out the API proposal on the CoreLibs alias
before continuing to move forward with updates to the PR (as was suggested by
both Alan and I)
For example, the updates to the PR does not include any proposed
On Mon, 26 Apr 2021 09:33:03 GMT, Pavel Rappo wrote:
> I had been looking for an example of a "properties" file when spotted a typo
> in `logging.properties`. I decided to proofread the file. That resulted in
> finding a few other issues.
LGTM, but English is not my primary language.
On Mon, 26 Apr 2021 02:36:54 GMT, Hamlin Li wrote:
>> code like below will create Deflater before null check, although it's not a
>> real mem leak, but it's better to do null check before new Deflater.
>>
>> try {
>> DeflaterOutputStream dos = new
On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson wrote:
> macOS on Apple silicon uses slightly different ABI conventions to the
> standard AArch64 ABI. The differences are outlined in [1]. In
> particular in the standard (AAPCS) ABI, variadic arguments may be passed
> in either registers or on
On Mon, 26 Apr 2021 02:36:54 GMT, Hamlin Li wrote:
>> code like below will create Deflater before null check, although it's not a
>> real mem leak, but it's better to do null check before new Deflater.
>>
>> try {
>> DeflaterOutputStream dos = new
On 4/26/21 1:27 PM, Сергей Цыпанов wrote:
On Mon, 26 Apr 2021 08:45:52 GMT, Alan Bateman wrote:
@AlanBateman if DL is not responding, will it be ok to just revert the changes
related to `java.util.concurrent`?
That should be fine, the null check in Objects.equals is benign with these
On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang wrote:
>> The JDK codebase re-created many variants of checkIndex(`grep -I -r
>> 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which
>> annotated with @IntrinsicCandidate and it only has a corresponding C1
>> intrinsic version.
On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson wrote:
> macOS on Apple silicon uses slightly different ABI conventions to the
> standard AArch64 ABI. The differences are outlined in [1]. In
> particular in the standard (AAPCS) ABI, variadic arguments may be passed
> in either registers or on
Without commenting on the value proposition of what you propose to do, I
am fairly certain that jpackage is not the way to do it. The job of
jpackage is to take an application, bundle it with a Java Runtime, and
create a native package / installer from it. What you are describing
goes far
On Sun, 25 Apr 2021 09:45:15 GMT, YassinHajaj
wrote:
>> src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line
>> 400:
>>
>>> 398: private static final String getProperty(final String propName,
>>> final String defVal) {
>>> 399: PrivilegedAction pa = () ->
On Thu, 8 Apr 2021 08:54:06 GMT, Alan Bateman wrote:
>> Dear All,
>> May I ask your help to review this change? Thanks!
>>
>> BRs,
>> Lin
>
>> Dear All,
>> May I ask your help to review this change? Thanks!
>
> @LanceAndersen Do you have cycles to help Lin? This proposal will require
>
On Mon, 26 Apr 2021 08:45:52 GMT, Alan Bateman wrote:
>> @AlanBateman if DL is not responding, will it be ok to just revert the
>> changes related to `java.util.concurrent`?
>
> That should be fine, the null check in Objects.equals is benign with these
> usages.
One more thing I'm thinking
I had been looking for an example of a "properties" file when spotted a typo in
`logging.properties`. I decided to proofread the file. That resulted in finding
a few other issues.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.java.net/jdk/pull/3688/files
On Mon, 19 Apr 2021 15:07:16 GMT, Fernando Guallini
wrote:
> Refactor the following shell tests to java:
> test/jdk/java/lang/RuntimeTests/shutdown/ShutdownHooks.sh
> test/jdk/java/lang/Runtime/exec/SetCwd.java
>
> In addition, the test SetCwd was running itself in separate java subprocesses
On Mon, 26 Apr 2021 07:57:21 GMT, Сергей Цыпанов
wrote:
>> src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
>> line 458:
>>
>>> 456: private static boolean isSamePackage(Class class1, Class
>>> class2) {
>>> 457: return
On Fri, 23 Apr 2021 10:44:30 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review the second half of my update for the `java.time`
> package to make use of the `instanceof` pattern variable?
>
> This PR was split into two parts due to the large number of files affected.
>
>
On Fri, 23 Apr 2021 14:29:36 GMT, Chris Hegarty wrote:
>> Patrick Concannon has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>>
On Mon, 19 Apr 2021 14:45:58 GMT, Alan Bateman wrote:
>> As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up
>> null-checks remaining after
>> [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as
>> Class.getPackageName() never returns null.
>
>
On Tue, 16 Feb 2021 13:48:20 GMT, Simon Legner
wrote:
> 8264031: (zipfs) Typo in ZipFileSystem.deleteFile ZipException
This pull request has now been integrated.
Changeset: 7b609a20
Author:Simon Legner
Committer: Aleksey Shipilev
URL:
On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang wrote:
>> The JDK codebase re-created many variants of checkIndex(`grep -I -r
>> 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which
>> annotated with @IntrinsicCandidate and it only has a corresponding C1
>> intrinsic version.
48 matches
Mail list logo
