Hi,
On 12/2/19 6:13 PM, Bob Vandette wrote:
2)
How should we deal with "not supported" for booleans/arrays, etc.?
Would it make sense to return record objects from the Metrics API so
that this could be dealt with? E.g.
Metrics m = ...
MetricResult<int[]> result = m.getCpuSetCpus();
switch(result.getType()) {
case NOT_SUPPORTED: /* do something */; break;
case SUPPORTED: int[] val = result.get(); break;
...
}
I'm bringing this up, because the proposed patch doesn't deal with the
above open questions as of yet. With that being said, it's mostly
identical to the proposed hotspot changes in [1].
For issue 2 …
I wonder if we should change the API to throw UnsupportedOperationException for
those methods
that are not available. This exception is used quite a lot in the java/nio and
java/net packages
for dealing with functionality not available on a host platform.
OTOH, The ProcessHandle API took a different approach, returning
Optional<XXX> when in some situations, the requested information about a
process is not known. Being either inaccessible or not supported.
There's a javadoc of Processhandle.Info type:
/**
* Information snapshot about the process.
* The attributes of a process vary by operating system and are not
available
* in all implementations. Information about processes is limited
* by the operating system privileges of the process making the
request.
* The return types are {@code Optional<T>} allowing explicit tests
* and actions if the value is available.
* @since 9
*/
But if you already have the API cast in stone, changing it to return
Optional(s) might not be backwards compatible. But so is changing the
behavior to throw UnsupportedOperationException from methods that didn't
already throw it.
Regards, Peter
