Community
Participate
Search
| Re: [cu-dev] BALLOT Behavior of virtual=true on Java SE 17 (vote by Thurs Feb 15) |
_______________________________________________There has been a lot of discussion of this topic. Let’s run a ballot so that we can choose an approach and move forward with it.
A vote of 0 is a vote to abstain and is not counted for or against any of the proposals.
A vote for option 1 is a vote for the specification to say that virtual=true when running on Java SE 17 is an error.
A vote for option 2 is a vote for the specification to say that virtual=true always results in a platform thread (which is the virtual=false behavior) when running on Java SE 17.
A vote for option 3 is a vote for the specification to say that the behavior of virtual=true is unspecified and is vendor-specific when running on Java SE 17. Each vendor will choose whatever behavior it wants.
A vote for option 4 is a vote for Jan’s proposal below that uses the combination of feature flag VirtualThreadsSupport and virtual.
This vote will be counted by simple majority of votes from Jakarta Concurrency specification committers as listed in https://projects.eclipse.org/projects/ee4j.cu/who .
Non-committers are encouraged to vote as a measure of community sentiment, and will be used as a tie-breaker if the committer vote comes out even.
This BALLOT will run until Thursday 2024-02-15 4:00PM CDT or when all committers have voted, whichever comes first.
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Jan Westerkamp via cu-dev <cu-dev@xxxxxxxxxxx>
Date: Thursday, February 8, 2024 at 6:09 AM
To: cu-dev@xxxxxxxxxxx <cu-dev@xxxxxxxxxxx>
Cc: Jan Westerkamp <jan.westerkamp@xxxxxxx>
Subject: [EXTERNAL] Re: [cu-dev] Behavior of virtual=true on Java SE 17Hi 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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
On Thu, Feb 8, 2024 at 10:31 AM Emily Jiang via cu-dev <cu-dev@xxxxxxxxxxx> wrote:
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.
Sent from Outlook for Android
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Ondro Mihályi via cu-dev <cu-dev@xxxxxxxxxxx>
Sent: Thursday, February 8, 2024 6:04:44 AM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Ondro Mihályi <mihalyi@xxxxxxxxxxx>
Subject: Re: [cu-dev] Behavior of virtual=true on Java SE 17
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
On Thu, 8 Feb 2024 at 00:21, Kyle Aure via cu-dev <cu-dev@xxxxxxxxxxx> wrote:
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
On Wed, Feb 7, 2024 at 4:40 PM Emily Jiang via cu-dev <cu-dev@xxxxxxxxxxx> wrote:
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.
On Wed, Feb 7, 2024 at 6:50 PM Ondro Mihályi via cu-dev <cu-dev@xxxxxxxxxxx> wrote:
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
From: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: Wednesday, February 7, 2024 4:20 PM
To: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>; cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: Re: [cu-dev] Behavior of virtual=true on Java SE 17
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=trueand 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.
From: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Date: Wednesday, February 7, 2024 at 9:56 AM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Subject: [EXTERNAL] RE: [cu-dev] Behavior of virtual=true on Java SE 17The 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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.
--
Steve Millidge
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> On Behalf Of Nathan Rauh via cu-dev
Sent: Wednesday, February 7, 2024 3:41 PM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Subject: Re: [cu-dev] Behavior of virtual=true on Java SE 17
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.
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Kyle Aure via cu-dev <cu-dev@xxxxxxxxxxx>
Date: Wednesday, February 7, 2024 at 9:15 AM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Kyle Aure <kylejaure@xxxxxxxxx>
Subject: [EXTERNAL] Re: [cu-dev] Behavior of virtual=true on Java SE 17Ondro 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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 runs as expected, regardless of whether platform or virtual threads are used.
As of right now there are no tests in the TCK for virtual threads. What I have done is opened a sample PR here: https://github.com/jakartaee/concurrency/pull/425
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.
Thank you,
Kyle Jon Aure
On Wed, Feb 7, 2024 at 7:01 AM Eduardo Martins via cu-dev <cu-dev@xxxxxxxxxxx> wrote:
+1
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.
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> On Behalf Of Ondro Mihályi via cu-dev
Sent: Wednesday, February 7, 2024 12:41 PM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Ondro Mihályi <mihalyi@xxxxxxxxxxx>
Subject: Re: [cu-dev] Behavior of virtual=true on Java SE 17
Hi Nathan,
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,
Ondro Mihalyi
Director, Jakarta EE expert
OmniFish - Jakarta EE Consulting & Support | www.omnifish.ee
Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932
On Mon, Feb 5, 2024 at 3:45 PM Nathan Rauh via cu-dev <cu-dev@xxxxxxxxxxx> wrote:
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.
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Emily Jiang via cu-dev <cu-dev@xxxxxxxxxxx>
Date: Monday, February 5, 2024 at 3:51 AM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [cu-dev] Behavior of virtual=true on Java SE 17I 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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.
Emily
On Fri, Feb 2, 2024 at 5:40 PM Nathan Rauh via cu-dev <cu-dev@xxxxxxxxxxx> wrote:
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.
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Ivar Grimstad via cu-dev <cu-dev@xxxxxxxxxxx>
Date: Friday, February 2, 2024 at 11:25 AM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [cu-dev] Behavior of virtual=true on Java SE 17On 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
On Fri, Feb 2, 2024 at 9:09 AM Nathan Rauh via cu-dev <cu-dev@xxxxxxxxxxx> 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
The options being considered are:
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.
Would it be possible to provide a warning of some kind both at compile time and runtime for Option 2?
I’ll leave this open for several more days, but I’d like to get a decision made one way or the other so that we can make progress on supporting Java SE 17 which is now being required by the Jakarta platform.
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
--
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration.
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
--Thanks
Emily_______________________________________________
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
--Thanks
Emily_______________________________________________
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
--Thanks
Emily_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________cu-dev mailing listcu-dev@xxxxxxxxxxxTo 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