| Re: [rest-dev] Drop Minimum Java Requirement to Java 17 |
It's a pity that the Jakarta EE 11 release plan opened that hole for Java 17. It would all be clear if it would simply say that components MUST compile to Java 21. Anyways, I think we simply have different philosphophy here, and neither is better or worse than the other, and it will not be possible to convince each other to give up his position. So according to the rules we gave us and if I count correctly, we effectively have two vetos against stepping back to 17 (mine and Arjan), correctly? Arjan, if I follow your last posting correctly, then you would also be -1 for a Multi-Release JAR (compiled to 21 but holding additional binaries for 17), right? -Markus Von: rest-dev [mailto:rest-dev-bounces@xxxxxxxxxxx] Im Auftrag von Arjan Tijms via rest-dev Hi, On Mon, 18 Dec 2023 at 18:16, Alessio Soldano <asoldano@xxxxxxxxxx> wrote:
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 |