[PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy
Peter Levart
peter.levart at gmail.com
Mon Dec 23 16:01:05 UTC 2019
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
More information about the core-libs-dev
mailing list