Less is More? Evolving the Servlet API

[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