jsr107/jsr107spec — Issue #54: How to Provide Different Consistency Options
Author: gregrluck
Created: 2012-02-14 14:34:26+00:00
State: open

The problem is:

1) Caches like Ehcache have different consistency options.
2) We do not want to enumerate all of these in the spec because their might not be common agreement on them
3) The TCK currently only works with strong consistency
4) We have advice from PMO/EE7 that it is not Ok to simply honour strong and allow the others but without the spec saying anything. The spec has to _allow_ the behaviour.
5) We do not want to end up with a spec that only supports strong consistency.

See below for discussion.

Patrick's right, all the behavior of the JCP-defined APIs in the product has to be as required or allowed by the spec.

If the spec says "this API does X", then it has to always do X, no matter how you configure the product.

If, as you suggest, the spec allows consistency modes that are different than what the spec defines, there should be a standard way for applications to get the mode that the spec does define. The TCK should be written to use that mode. If the way to choose the mode is not standardized (a bad idea, in my opinion), we'll need to add a special TCK compatibility rule that allows the TCK to always be run in a mode that provides the spec-defined consistency, and I would strongly suggest that the spec require the default mode (if such a thing makes sense) to provide the spec defined behavior.

A key attribute of our Java compatibility program has been to prevent the typical vendor "bait and switch" where they claim to conform to the standard, but the product really only works in the standard way if you configure it specially. If you're "Java compatible", we want you to always be Java compatible.

Patrick Curran wrote on 02/03/12 11:52:
Hello, Greg:

Normally I would refer questions like this to the Spec Lead, but since that's you I guess this wouldn't help very much :)

In future, it would be helpful if you could use the pmo@jcp.org address for queries such as this, to ensure that you'll get an answer even if Harold is away.

As for your questions, see my responses inline below.

-------- Original Message --------
Subject:	Please respond - question on defaults for TCK tests
Date:	Fri, 3 Feb 2012 08:53:30 +1000
From:	Greg Luck
To:	Harold Ogle
CC:	Yannis Cosmadopoulos , Chris Dennis
Harold

We are planning on having our product defaults not pass the TCK. To pass the TCK we would need to set a system property called say "jsr107.compliance.mode=true".
One example is on consistency. Out of the box our default is eventual consistency. But to pass the TCK we will need to use our strong consistency setting.

Is that Ok? And don't give your whatever you like answer. I have found that as Oracle is co copyright owner and this is also EE 7 they have stricter rules than the JCP.

Please advise.

I'm sure you really know the answer to this question :)

Of course this isn't OK. All implementations must be compatible. This means not only passing the TCK, but meeting all of the other compatibility requirements that are specified in the TCK User's Guide. One of those requirements is that implementations must be compatible "in all modes," which means that you can't play games with switches in the manner you're suggesting.

On a second point, is it Ok to say things like "Implementations may support additional consistency models". i.e. it is not in the spec but we are foreshadowing that this is an area where we expect implementations to add additional modes.
If you mean is it OK for the spec to say that "Implementations may support additional consistency models" - absolutely. The purpose of the spec is not only to define what is required, but also to specify where implementations are free to innovate.