|Re: [jakartaee-platform-dev] [External] : Re: Redefine what Priority annotation means across Jakarta EE specifications|
Name `ordinal` is used in Java enums, to define the order within the enumeration. The first one has ordinal 0…
So in this case it may be confusing as well, as for me “ordinal” means in numerical order – e.g. lower number comes before higher number.
First of all, the @Priority annotation was introduced by the CDI team. As is the specific part of the interceptors spec. Both originally have been part of CDI when spec still was called "Web Beans"...
I think we should NOT change anything and also NOT introduce any new annotation. It would just confuse people which are used to the current solution.
Whiles the name 'Priority' is probably not the best I think the current behaviour in CDI is fine.
JAX-RS made use of the annotation only many years later and in retrospect they should probably have asked people from the CDI EG. Their wording and behaviour of the usage in JAX-RS is imo quite confusing.
For application supplied providers they define:
"Application-supplied providers may be annotated with @Priority. If two or more providers are candidates for a certain task, the one with the highest priority is chosen: the highest priority is defined to be the one with the lowest value in this case."
The highest wins, which is the lowest... omg.
BUT for other parts of JAX-RS it is the other way around:
"The order in which filters and interceptors are executed as part of their corresponding chains is controlled by the @Priority annotation defined in .... Execution chains for extension points ContainerResponse and ClientResponse are sorted in descending order; the higher the number the higher the priority."
Yes, that's probably a mess, but it's not the fault of @Priority in the first place ;)
If we do like to use some fixed annotation based ordering then we should stick with @Priority and explicitly define that the highest number wins. Because changing this annotation now would be a huge pain with a low gain. Because functionally there would be no benefit.
But the whole discussion is probably somewhat moot. Because the original reason for not using @Priority in ConfigSources is that this number is totally dynamic and does not come from within the source at all! That's the reason why it is a method returning an int (could probably be float as well). And to make sure that people do not get confused with the ordering (and because it's really something different) I coined the term 'ordinal', simply because it was not yet taken and thus I could exactly define how I liked it. That was 10 years ago and the name did stick . But if there is a better name which has a big benefit over the current version then I'm happy to hear those better ideas!
Back to the top