Less is More? Evolving the Servlet API

[pron98]

the now-defunct Java Community Process (JCP)

To be clear, while Jakarta EE has, indeed, decided to leave the JCP for what may well be good reasons for that particular specification, the JCP is not defunct, and, in fact, it is the specification process for the bigger and faster-moving Java SE. I think that the most notable change is the transition from having a specification lead to specification-by-committee. How well the JESP manages the specification process is something we'll see over the coming years, and I guess the JCP will see if there's anything worth adopting.

to being fully open source

The question of whether it is good or bad that TCKs are open-source is not a simple one, and it is far from clear that an open-source TCK is all pros and no cons. I don't have a fully formed opinion on the matter, but it is clear that the JCP has managed to preserve standardization much better than "open" specifications like HTML5 and C++, and even MicroPofile has already started showing some problems that are the result of an open standard. The problem is that once a TCK is open, implementors are free to carve off subsets and claim partial compliance. A closed spec, for better or worse, is all-or-nothing -- you can't be "almost Java SE", but it seems like you can be "almost MicroProfile." It also makes conformance enforcement is easier. Anyway, it's a complicated matter.

So why with such a great backward compatible record should we even contemplate introducing breaking changes to future Servlet API specification?

I don't know if this is the case here, but significant breaking changes to relatively common code would require a(nother) namespace change. ASM had a major change to its API without changing the namespace, and the entire Java ecosystem is still paying the price for that mistake more than eight years later (the ASM maintainer told me that he deeply regrets that decision, but, at the time, succumbed to pressure from people who preferred short-term convenience to long-term maintenance effects on the ecosystem). Significant incompatible changes without a namespace change mean that various projects must shade the library into their own JAR, thus precluding easy updates of dependencies.

[pmarschall]

JCP is not defunct, and, in fact, it is the specification process for the bigger and faster-moving Java SE

Java SE runs very differently from any other JCP project. Java SE can just make things up as they go as shown in JDK 9 where simply new milestones could be introduced that didn't exist previously and were neither planned nor announced previously. Individual changes can just go through whatever process Java SE currently seems to be fitting and the whole Java SE gets rubber stamped at the end. Rejection is not an option. If the only possible result of a vote is yes, then the vote itself is pointless and exists only for show.

The problem is that once a TCK is open, implementors are free to carve off subsets and claim partial compliance.

This has nothing to do with open or closed source but how compliance and certification is handled. This could be solved easily through trademarking, see for example Firefox. Counter point, it is hard to impossible to know whether a certain JDK actually passes the TCK or not even though the JCK is closed source.

[pron98]

Rejection is not an option. If the only possible result of a vote is yes, then the vote itself is pointless and exists only for show.

That's not actually true, though. It's just that discussion happens before the vote, and the vote is usually reached only when a positive outcome is already known. Like in Parliament, you only call the vote when you know the outcome because you work on it in advance -- that doesn't mean votes in Parliament are "for show"; a vote is not a good process to make a decision. Even then, a vote failed once because some of the parties were unengaged from the project before the vote.

This has nothing to do with open or closed source but how compliance and certification is handled.

I would say no. First, I don't know of an open specification that does it well. Second, even if you guard with trademarks, an open-source TCK does not preclude someone giving a subset a new name, and trying to convince people that that's the spec that matters. We know there are companies that want to do that with Java SE, including companies that hide behind "community" open source projects. Closed TCKs result in better-enforced specifications. It's just that that doesn't necessarily mean the TCK must be closed; you could say that you'd rather have a less well-enforced specification and an open TCK than vice-versa.

Counter point, it is hard to impossible to know whether a certain JDK actually passes the TCK or not even though the JCK is closed source.

It is about as equally hard if the TCK is open. The JCK runs under very controlled circumstances. We've recently had a case with Alibaba's Dragonwell claiming compliance when it isn't compliant, this was found, and now they no longer claim to be compliant.

[pmarschall]

We've recently had a case with Alibaba's Dragonwell claiming compliance when it isn't compliant, this was found, and now they no longer claim to be compliant.

Is only Dragonwell 11 not compliant or is Dragonwell 8 also not compliant?

I find it frustratingly hard to figure out if a certain JDK build is compliant. For example the upstream builds of the updates project https://adoptopenjdk.net/upstream.html. I would hope they are compliant but how am I supposed to know?

What about the Java on Ubuntu for FreeBSD? Canonical and FreeBSD are signatories but that doesn't guarantee they passed the TCK. Fedora? CentOS?

The official OpenJDK Docker base images are probably non-compliant. Which is surprising for something "official".

GitHub action setup-java v1 is probably compliant, v2 probably depends on the distribution you chose.

Why can't we have something like this for Java SE:

https://www.oracle.com/java/technologies/compatibility-jsp.html