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.
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 17
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.
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.
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
|
