EVALUATION
The PDF spec says:
"If no setMethod operation is defined then only the value field of the attribute's descriptor will be set. [...] If caching is supported by the model MBean, the new attribute value will be cached in the value field of the descriptor if the currencyTimeLimit field of the descriptor is not -1."
This implies that we must not throw an exception if setMethod is not set, unless caching is not supported.
There appears to be a contradiction between the PDF spec and the Javadoc spec here. The safest thing to do would appear to be to keep the existing behaviour, i.e. do not throw an exception, at least unless we can determine that the value would not be cached.
|
EVALUATION
This is not strictly speaking a spec violation. The spec is a little unclear on the question, but it appears that an implementation would be justified in making the following interpretation. When an attribute's descriptor defines a getMethod but not a setMethod, then calling setAttribute causes the set value to be stored in the descriptor itself. This makes a small amount of sense when the descriptor defines an explicit currencyTimeLimit that is not -1. Then the setAttribute value is the cached value for the number of milliseconds defined by currencyTimeLimit. A getAttribute that arrives within that period will retrieve the cached value.
On the other hand, if there is no currencyTimeLimit, or if it is -1, then the cached value is always stale. In this case, if there is a getMethod but no setMethod, the value set by a setAttribute will never be seen by a subsequent getAttribute. It would make sense to throw an exception here.
###@###.### 2004-02-19
|