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
This
Message Is From an External Sender
This
message came from outside your organization.
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.
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.
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:
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.
> 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.
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.
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.
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.
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
