Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rest-dev] Drop Minimum Java Requirement to Java 17


I'm -1 for a multi release JAR indeed. I'm +0 for a JDK 17 release, although I would really prefer a JDK 21 one.

Kind regards,
Arjan Tijms

On Tue, 19 Dec 2023 at 09:14, Markus Karg <markus@xxxxxxxxxxxxxxx> wrote:

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?




Von: rest-dev [mailto:rest-dev-bounces@xxxxxxxxxxx] Im Auftrag von Arjan Tijms via rest-dev
Gesendet: Montag, 18. Dezember 2023 23:23
An: Alessio Soldano
Cc: Arjan Tijms; Jakarta Rest project developer discussions
Betreff: Re: [rest-dev] Drop Minimum Java Requirement to Java 17




On Mon, 18 Dec 2023 at 18:16, Alessio Soldano <asoldano@xxxxxxxxxx> wrote:

 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













Kind regards,

Arjan Tijms



Alessio Soldano

Manager, Software Engineering 

Red Hat


Back to the top