again I think the specification should be inclusive.
I'm not so sure about that. I think specifications should be strict (tightly specified, rigid) and definitely not being inclusive. Being inclusive has always led to problems. Yes, it sounds nice, but it really is not so nice.
Imagine an API that takes an Object as parameter, since we want the API to be inclusive to all kinds of objects. Maybe an HTTPRequest, maybe an EJBInvocation, maybe a RestRequest. Say that the method returns roles. Since we want to be inclusive again, they may actually be groups (and not roles at all), or mapped roles, or application roles, or local servlet roles. We don't specify any of it, since we want to be inclusive to all kinds of roles.
Eventually we end up with something that has so many gaps, we can't reasonably use it in practice.
Specifically here, "which might happen to require Java 21", means nothing to a library vendor. I can't create a component for Jakarta REST 4.0 using Java 21, if all the specification says that there may be implementations that happen to require Java 21. I want the guarantee that my component for Jakarta REST 4.0 works on all compatible implementations of Jakarta REST 4.0. Therefore I have to resort to the lowest common denominator, and therefore I can't use Java 21, even if my code would greatly benefit from it.
Kind regards,
Arjan Tijms
--
Alessio Soldano
Manager, Software Engineering
Red Hat
