Multiple Implementations

8 views
Skip to first unread message

David Blevins

unread,
Mar 24, 2021, 8:07:54 PM3/24/21
to jakartaee-...@googlegroups.com
We have 13 certified Jakarta EE servers, however for most component specifications we have just 1 certified implementation.

Am I alone in thinking this is a problem?

There's a vote going on where one of the options would take one implementation and promote it to the top of each specification page as a ratified implementation, above all other implementations. It would be again listed at the top in the compatible implementation list. I've written why I think this is harmful in our current status of one-implementation specs and very little spec activity overall. It includes a presentation with analysis of our 12 most popular or recent specs.

- https://www.eclipse.org/lists/jakarta.ee-spec/msg01482.html

For those who flip through the presentation, slide 23 on Jakarta REST was used to make the statement that even a little diversity in implementation makes a big difference and that is probably why Jakarta REST is our most active/healthy component spec. It was used in contrast to the previous specs that have few implementations and lower activity.

On slide 28 I point out that because there is just one implementation for most specs there is very little vendor engagement and most the activity on specifications in the JCP at least came from individuals -- that's you all here.

I'm very curious on what people here think.

Is having multiple implementations important and worth fighting for?


--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

Reza Rahman

unread,
Mar 24, 2021, 8:22:17 PM3/24/21
to Jakarta Ambassadors
David,

I appreciate your engaging folks here.

To be honest, this is a very complex topic. From a principles standpoint, having multiple truly independent implementations is ideal. However, if you look at the Java SE world, having one reference implementation with multiple robust distributions from multiple independent parties is also workable and one might say even reduces some duplication of effort and leads to a pooling of resources. I think ultimately what leads to investment into a common pool is whether companies think investing in specifications/distributions will make them money, whether or not implementations are truly independent or if one party has a bit more (but not overly so) influence than another. If you really look, the situation is very similar with Linux and there is ongoing investment in keeping Linux robust.

What do you think? Am I off base?

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

> On Mar 24, 2021, at 8:07 PM, David Blevins <david....@gmail.com> wrote:
>
> We have 13 certified Jakarta EE servers, however for most component specifications we have just 1 certified implementation.
> --
> You received this message because you are subscribed to the Google Groups "Jakarta EE Ambassadors" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jakartaee-ambass...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/ED6641EC-EAE2-4314-AF85-D4E65946D2EA%40gmail.com.

arjan tijms

unread,
Mar 26, 2021, 8:24:38 AM3/26/21
to David Blevins, Jakarta EE Ambassadors
Hi,

Thanks for starting this topic. It's a topic close to my heart as you know, as I've been tracking which servers use what for some time.

There's many good things in the presentation, but to comment first on one particular sentence:

Are there things we do to that make implementing specifications more difficult or burdensome?

One thing IMHO is integrating with non-standard SPIs. It takes a lot of pain to find the proprietary SPIs to do things, and often even more pain to keep it up to date. As an example:


That particular issue is just a small detail in the overall scheme of things, but I think it's exemplary for the bigger problem: sometimes failing to make the life of spec implementers easier, and focussing fully on the end-user instead. Of course there's a budget regarding time and energy, and choices have to be made, but I think some of that budget should go towards helping spec implementers.

Kind regards,
Arjan Tijms













Reply all
Reply to author
Forward
0 new messages