[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