Re: [cu-dev] Behavior of virtual=true on Java SE 17

[Ondro Mihályi <mihalyi@xxxxxxxxxxx>]

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 17

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

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

 

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 17

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

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

 

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