Executors.newVirtualThreadPerTaskExecutor() leaks CompletableFuture

[Holo The Sage Wolf]

> I don't think that is "leaking" in the way a leak is typically considered
(i.e. a memory leak)

It is also very common to an exposure of unintended information "leaking"
(e.g. "leaking internal state")

That being said, CompletableFuture doesn't leak anything and there isn't
any problems in the executor using this instead of plain Future

On Wed, Mar 15, 2023, 00:43 Paul Bjorkstrand <paul.bjorkstrand at gmail.com>
wrote:

> That is not unique to Executors.newVirtualThreadPerTaskExecutor. It is
> also the same Executors.newThreadPerTaskExecutor. Both use the
> same ThreadPerTaskExecutor (with different thread factories) that returns
> instances of ThreadBoundFuture, which extends CompletableFuture [1], for
> calls to the submit(..) methods.
>
> I don't think that is "leaking" in the way a leak is typically considered
> (i.e. a memory leak). It may be "leaking" some information about the
> implementation, but that is just a consequence of an open, inspectable
> system like the JDK.
>
> [1]:
> https://github.com/openjdk/loom/blob/fibers/src/java.base/share/classes/java/util/concurrent/ThreadPerTaskExecutor.java#L327
>
> -Paul
>
>
> On Tue, Mar 14, 2023 at 3:41 PM Kasper Nielsen <kasperni at gmail.com> wrote:
>
>> Hi,
>>
>> I don't know if it is much of an issue in practice but you can cast the
>> futures returned from Executors.newVirtualThreadPerTaskExecutor
>> to CompletableFuture:
>>
>> ExecutorService e = Executors.newVirtualThreadPerTaskExecutor();
>> CompletableFuture f = (CompletableFuture<?>) e.submit(() -> {});
>>
>> Other executors return instances of FutureTask which is probably less
>> likely to be abused.
>>
>> /Kasper
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230315/f3f081ae/attachment.htm>