[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cu-dev] Behavior of virtual=true on Java SE 17
|
- From: Jan Westerkamp <jan.westerkamp@xxxxxxx>
- Date: Thu, 8 Feb 2024 13:09:26 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ijug.eu; dmarc=pass action=none header.from=ijug.eu; dkim=pass header.d=ijug.eu; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4X7a3f8M+8IF63bYKooAk1U2AmNoqSQqv/18GcqALTk=; b=fcxclnaX0wppJGkkmil17j9PI8/y2G2zTs8oViW8GG/pJCzbw+VCU4GQ9rBPheJngQqPTjb8OCAzj8riK48m4CTYI99ilJ7hCZaIChTWV5DJVi9fPGvkO3E5y+EVpYN4f+v/K2EuSg+RxYJnjSSDsp6O304jC35yzdylN1tPHxjE4jQ9Y8MSuZOaor64vPgDi/Th0xaCZ3vR8TFMsGi00i8zxCj/P88vugZKnaHlGr8ttVC8HhMAELClUGa7wRbIHeKO3RR6QugqDHmTq6ESxMOhduwWTHhHb4hWpMyp6uKNICFe2v28cAkLbfn25mbAAoGNc1KDyn9Czx4KAOsOpQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CY+oV4pREc0PH6/pPo1Z5aRRfGafD6108rdWXb9O2y7c/DFdliMmrXiHPHIzGJW49dNrnbIs4/FD3o8/9FvOnchhV+SR6hwmHGnAIoejioX97wQTkjmLKCfkDUHukgYL7YdkQ+t60TFai4ADLpn6GWbk/jJuG49TlB/2EeKTcqZ6bQjnUNhwABAwaFyIJmqIIcAmkvDgm/U9ux5+1oZtKRWaUwTxAvmg1BXU9/W5Y4GTAkIF1lBg9AOhFxq36XpkBeskSk6ykozT7waIiNCO/S+j0tErIw77Pt96QTlS3CY7RO0vdnTP+e5Qepb/Cn35OudGKvcnMoTKLTV8WqK9WQ==
- Delivered-to: cu-dev@xxxxxxxxxxx
- List-archive: <https://www.eclipse.org/mailman/private/cu-dev/>
- List-help: <mailto:cu-dev-request@eclipse.org?subject=help>
- List-subscribe: <https://www.eclipse.org/mailman/listinfo/cu-dev>, <mailto:cu-dev-request@eclipse.org?subject=subscribe>
- List-unsubscribe: <https://www.eclipse.org/mailman/options/cu-dev>, <mailto:cu-dev-request@eclipse.org?subject=unsubscribe>
- User-agent: Mozilla Thunderbird
Hi all,
as mentioned in the last Platform call,
I disagree here:
As a user of the Jakarte EE
Plaform/Jakarta Concurrency Spec I expect defined behaviour and
when I configure to use Virtual Treads to manage my environment
(perhaps by using resources more efficiently) I expect to get the
requested behaviour (Virtual Threads support) or fail fast (by
Exception).
Specifications designed well focusing
on the usability, not of implementation simplicity.
Weakening the specification (behaviour)
by shortcut to make it easier to implement the spec because
resources are limited it the wrong way in my opinion. The TCK will
become at minimum complex or even unspecific too! As a result the
maintainability is decreased.
Changing the behaviour later to be more
specific or reliable results in a breaking change (and a Major
Release).
On the long run, this is a waste of
rare (compute and human) resources...
Adding support for Java SE 17 for
Jakarta EE 11 complicates the situation a little bit, but I think
the current agreement on a unspecified behaviour on Java SE 21 to
may support Virtual Treads is an issue too, as this results
in an optional feature that is also weak specified.
Ways out of this from my point of view:
Why we not think about Virtual Treads
support as an optional feature with a feature flag (and default
behaviour) on the Java SE and Jakarta implementation level?
Only when both of these platform levels
support Virtual Threads, then Virtual Treads can be requested
reliably (without raising an Exception).
For getting (reliable) Virtual Threads
(VT) support in a strong specification we need to ensure that the
Jakarta EE implementation (Jakarta platform or environment part)
and Java SE implementation (Java SE platform or environment part)
support Virtual Treads.
Let's name the feature flag
VirtualThreadsSupport and the Exception UnsupportedException for
now.
The Java SE version defines Virtual
Treads support on the first level, the Jakarta EE Platform on the
second one:
Java SE 17 independent of
implementation VT support: VirtualThreadsSupport = false (default
value, changing this to true or using virtual=true throws
an UnsupportedException)
Java SE 21 depends on implementation VT
support:
a) Jakarta EE implementation does
not support VT: VirtualThreadsSupport = false (default
value, changing this to true or using virtual=true throws an
UnsupportedException)
b) Jakarta EE implementation does
support VT: VirtualThreadsSupport = true (default value, changing
this to false is possible and results in behaviour like a))
So in fact supporting Virtual Threads
is combination of the Java SE and Jakarta EE feature (AND
operator).
The Jakarta Concurrency spec should
give control (API read access by i.e.
isVirtualThreadsSupportEnabled() and configuration option as
described above).
The TCK can check the support via the
feature flag and can test the optional feature only when supported
in a simple way.
As a shortcut to save resources on spec
implementation teams it is possible to not support Virtual Treads
at all, as this is an optional feature of the spec and it report
this returning the feature flag state (without raising a costly
Exception).
On the long run, we could also
deprecate the new VT feature, when there is an agreement on making
VT support a requirement (not optional only) in the future.
Feature flags should be removed, when
not needed any more, i.e. when a future release might require Java
SE 21+ and VT support too.
Best,
Jan
PS: Regarding the original discussion
this is a vote for option 3, with an enhancement ;-)
Am 08.02.24 um 11:25 schrieb Ondro
Mihályi via cu-dev:
Yes, I support option 2: platforms should ignore
virtual=true and just return a platform thread on Java 17.
Before I suggested that implementations can decide, but
that would require some work in the TCT, so I think option 2
is best in the current situation. Implementations can still
decide to support some other behavior with a custom
configuration option.
Ondro
Based on the previous many conversations, I thought the
TCK would be designed in a way that both Java 17 and 21
can pass. I was apparently incorrect However the message
was repeated on some other calls. At the moment:
Virtual=false: both Java 17 and 21 behave the same
virtual=true; Java 21 sometimes give you a virtual
thread but it might give you a platform thread. Java 17
always gives you a platform.
For the test you wrote, it should pass either Java 17
or Java 21.
I think based on this conversation, the tests can be
executed and would pass regardless.
Option 2 is the ideal one in my opinion as well. I
think Steve and Ondro also suggested this.
On Thu, Feb 8, 2024 at
8:21 AM Steve Millidge (Payara) via cu-dev <
cu-dev@xxxxxxxxxxx>
wrote:
I would vote option 2.
However from a developer experience the
application behaviour could be significantly different
switching between JDKs and implementations but at
least that is documented. This arises
predominantly from virtual=true being a hint.
Perhaps with the 17 support we should revisit the
hint decision but that is a separate discussion.
Before, I assumed that the TCK
verifies that virtual threads are used with
virtual=true. But if it’s the case that even on Java
21 using virtual threads is optional, why we need a
different behavior for Java 17?
What about just these 2 rules:
virtual=false,
JDK 17 or 21 - Expect a platform thread
virtual=true,
JDK 17 or 21 - Expect either a virtual or
platform thread
On
JDK 17, it would always be a platform thread.
That also satisfies both expectations. Let’s not
invent another special rule for Java 17 if the
current rules for Java 21 work already for 17
too.
Ondro
Emily,
> I think now we are sort of agreeing
on this
Incorrect, there has been no agreement on
behavior and talk of the TCK has just
derailed the discussion.
Whatever behavior we decide on we can
test with the TCK one way or another (No
tests have been delivered, only sample code
written to prove testing is possible).
This is what has been decided:
virtual=false, JDK 21 - Expect a platform
thread
virtual=true, JDK 21 - Expect either a
virtual or platform thread
virtual=false, JDK 17 - Expect a platform
thread
virtual=true, JDK 17 -
This is the only part of the matrix we
haven't decided on:
- Should this be a runtime
error?
- Should platforms ignore this
and just return a platform thread?
- Should it be undefined (some
products may choose to ignore, throw a
runtime error, or fail to deploy the
application)?
We can test any of these scenarios
(including 3, which will be to not test
anything, because there will be nothing to
test, because it is undefined).
We really just need to vote on what we
want and worry about the testing later since
I have proven we can test any of these
scenarios.
Thanks,
Kyle Jon Aure
I am pretty confused with the
discussion.
I think now we are sort of agreeing
on this: the VT TCK test should pass on
both Java 17 and 21.
What kind of TCK are we talking
about? We need to first clarify the
precondition and postcondition on this.
My suggestion:
1. Precondition: set virtual=true
2. post condition: if Java 17,
platform thread; If Java 21, virtual
thread some times.
Now the question is how do we know
the version of Java runtime is using,
based on what Kyle said.
Correct, Steve.
I suggest that implementations
decide whatever they want to do as
long as they pass the TCK. And the
TCK should make it possible to pass
on Java 17, that's why I suggested
that it doesn't verify that virtual
threads are actually used. It's that
simple. Let's do it and move on to
something productive.
Ondro
On Wed, Feb 7, 2024 at
5:50 PM Steve Millidge (Payara) via
cu-dev <
cu-dev@xxxxxxxxxxx>
wrote:
OK was going on the
comment in the email
thread
“They should
just ensure that an app
with virtual=true can be
deployed and runs as
expected, regardless of
whether platform or
virtual threads are used.
Then the tests would pass
both on Java 17 and 21.”
|
--
|
|
Steve
Millidge
Founder
& CEO
|
Ondro will
need to chime in to
restate his position, but
as I understand it from
comments in the pull, it
was to “leave it to
implementations how they
react, whether they just
ignore virtual=true and use
platform threads, with or
without a warning, or
deployment fails.” I am
trying to point out that
this is at odds with not
skipping tests and
skipping deployment of
entire test applications
because you don’t have any
guarantee that the
deployment will work if
the vendor gets to choose.
The
problem I see with
skipping tests is
that a vendor may
not allow deployment
of an application
with virtual=true on
17 while Ondo, I
believe, was
asserting that the
application should
deploy OK with
virtual=true with 17
which is my
preferred
This Message
Is From an
External
Sender
This message
came from
outside your
organization.
The
problem I see with
skipping tests is
that a vendor may
not allow deployment
of an application
with virtual=true on
17 while Ondo, I
believe, was
asserting that the
application should
deploy OK with
virtual=true with 17
which is my
preferred option. My
understanding (from
memory) is that even
on 21 this is a
“hint” so the only
thing you can really
assert in the TCK
regardless of the
JDK is that the task
is ran in the way it
would have ran
previously before
this “hint” existed.
It
has never been in
the plans for TCK
tests to enforce
that a virtual
thread be returned
when the application
specifies the
virtual=true
request. We defined
the true value as a
request for virtual
threads to be used
if possible, so the
tested behavior is
that the
task/runnable runs
and completes
successfully,
without asserting
that the thread is
virtual. Tests of
virtual=false will
assert that the
thread is a platform
thread because in
that case it is a
spec requirement to
have a platform
thread.
The
problem in the TCK
is not over
asserting behavior
for virtual=true,
the problem I have
with what has been
said is assuming the
TCK can deploy
applications with
virtual=true on Java
SE 17. For those of
you who are
advocating
vendor-specific
behavior for
virtual=true on Java
SE 17, it needs to
be clarified that
vendor-specific
behavior literally
means the vendor can
choose any behavior
it wants when it
sees virtual=true.
A vendor might
choose to ignore the
setting and use
platform threads,
fail at run time,
fail at deploy time,
run the task
immediately inline,
skip running the
task at all, … or
whatever else the
vendor thinks of.
The vendor can do
whatever it wants,
and the TCK would
somehow need to
handle that.
Kyle
has a solution here
that will skip
deploying
applications with
virtual=true on Java
SE 17. That is
really the only
valid option if
defining
virtual=true to have
vendor-specific
meaning on Java SE
17 because you
cannot assume that
all vendors will
choose to allow the
application to
deploy if you leave
it up to them.
We
still need to have a
vote on which of the
three options are
being chosen. I am
worried it will end
up as a 3-way split
with none having
majority support.
Ondro
and others,
> Therefore
I suggest that
we change the
existing
virtual thread
tests in the
TCK so that
they don't
validate
anything about
virtual
threads. They
should just
ensure that an
app with
virtual=true
can be
deployed and
This Message
Is From an
External
Sender
This message
came from
outside your
organization.
> Therefore I suggest
that we change
the existing
virtual thread
tests in the
TCK so that
they don't
validate
anything about
virtual
threads. They
should just
ensure that an
app with
virtual=true
can be
deployed and
runs as
expected,
regardless of
whether
platform or
virtual
threads are
used.
From my understanding, the
added support
for Java 17
did not
exclude Java
21 so as you
stated we have
to support
running the
TCK against
Java 17 and
Java 21.
So what I have done is added
the
UsingVirtualThreads
annotation to
the TCK which
can be put on
any test class
that will
attempt to
deploy an
application
with
`virtual=true`.
If the test is running on
Java 17, the
test class
will be
skipped and
the
application
will never be
deployed.
If the test is running on
Java 21, the
test class
will proceed
and the
application
will be
deployed.
Furthermore, I added
assumptions to
any test
method that
makes
assertions
about virtual
threads. This
means that if
a platform
running on
Java 21 does
not support
virtual
threads the
test case will
exit there and
not attempt to
make any
assertions
about virtual
threads.
I think this hits all the
points brought
up in this
email thread
that were
concerns for
the TCK.
If I missed anything let me
know here or
on the PR.
On Wed, 7 Feb 2024 at 12:59,
Steve Millidge
(Payara) via
cu-dev <cu-dev@xxxxxxxxxxx> wrote:
I agree
with Ondro
here – if we
are adapting
the spec to
support JDK17
then we should
not test
anything wrt
to virtual
threads and
just support
application
deployments
with that
property set
or missing
completely.
I really don't like the
decision to
support Java
17, so take my
opinion with a
grain of salt
here, please.
I think that we should
minimize the
impact of the
decision to
support Java
17 as much as
possible, even
if the
reaction to
this would not
be very
popular.
Therefore I
suggest that
we change the
existing
virtual thread
tests in the
TCK so that
they don't
validate
anything about
virtual
threads. They
should just
ensure that an
app with
virtual=true
can be
deployed and
runs as
expected,
regardless of
whether
platform or
virtual
threads are
used. Then the
tests would
pass both on
Java 17 and
21.
Later, in a newer
Concurrency
spec version
after EE 11,
we can revert
the tests so
that they
validate that
the threads
are virtual
and require
Java 21.
I think it's a good and
simple
solution to
comply with
the decision
to support
Java 17 and
make our lives
easier.
Otherwise we
risk more and
more delays,
endless
discussions,
and
frustration.
All
the best,
Director,
Jakarta EE
expert
Omnifish OÜ,
Narva mnt 5,
10117 Tallinn,
Estonia | VAT:
EE102487932
Emily
and Ondro,
thanks for
pointing out
there is a
third option
here to have
the behavior
be unspecified
when
virtual=true
is used on
Java SE 17.
That would
leave it up to
the vendor
whether to
raise an error
or ignore the
virtual=true
value and/or
issue a
warning. It
would also
require the
TCK to avoid
attempting to
deploy all
test
applications
where
virtual=true
is used when
running on
Java SE 17. I
discussed this
with Kyle who
pointed out
that is
current
possibly to be
running the
TCK test
client from a
Java level
that is
different from
the Java level
of the Jakarta
EE product
being tested,
making it
impossible for
the TCK to
accurately
determine
whether or not
it ought to
attempt
deployment of
test
applications
with
virtual=true.
To address
that, we would
need to add a
new
requirement to
the TCK that
both must run
on the same
Java SE level.
I’ll
post this
comment to the
pull request
as well where
this is also
being
discussed.
I
am with Ondro
on this (see
here). I think
using
unspecified
behavior might
be a better
option as the
value is still
valid but the
JVM cannot
fulfil the
task. Even in
JVM 21, the
app might not
get a VT even
though the app
asks for a VT.
EmilyOn
This
Message Is
From an
External
Sender
This
message came
from outside
your
organization.
I am
with Ondro on
this (see
here). I
think using
unspecified
behavior might
be a better
option as the
value is still
valid but the
JVM cannot
fulfil the
task. Even in
JVM 21, the
app might not
get a VT even
though the app
asks for a VT.
Ivar,
That’s
an interesting
idea.
>
Would it be
possible to
provide a
warning of
some kind both
at compile
time and
runtime for
Option 2?
At
run time, yes.
The spec could
require
implementations
to log a
warning at run
time when
seeing the
annotation. I
think that
would be a
good idea if
going with
Option 2.
At
compile time,
even if there
were a way to
cause a
warning at
compile time,
it would be
wrong to do so
because it is
a valid
scenario to
compile your
application
with Java SE
17 but run it
on Java SE
21. Users
should not
have to
receive a
warning for
that.
On
Fri, Feb 2,
2024 at 9: 09 AM Nathan Rauh via
cu-dev
<cu-dev@ eclipse. org> wrote: If anyone
else has an
opinion on
what the
behavior of
virtual=true
should be when
running on
Java SE 17,
please comment
in https: //github. com/jakartaee/concurrency/pull/415
This
Message Is
From an
External
Sender
This
message came
from outside
your
organization.
1.
It’s
an error
because Java
SE 17 can’t
possibly ever
honor your
request to use
virtual
threads.
2.
Ignore
your request
for a virtual
thread on Java
SE 17 and use
a platform
thread
instead.
_______________________________________________
cu-dev mailing
list
cu-dev@xxxxxxxxxxx
To unsubscribe
from this
list, visit
https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing
list
cu-dev@xxxxxxxxxxx
To unsubscribe
from this
list, visit
https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list,
visit
https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cu-dev
--
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
--
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
