[PATCH] Add const to input parameter for JNU_IsInstanceOfByName

[Andrew Luo]

Hi Everyone,

I'm making some const-correctness fixes to some downstream libraries that use 
JNU_* functions, and noticed that JNU_IsInstanceOfByName takes in the class 
name by char* instead of const char* when it does not need to modify the 
string.  It would be useful to change this so that we don't have to 
(unnecessarily) const-cast every time and can safely pass string literals to 
this function.  Patch is inline below - any comments/feedback welcome.

Thanks,

-Andrew

diff -r 70fab3a8ff02 src/java.base/share/native/libjava/jni_util.c
--- a/src/java.base/share/native/libjava/jni_util.cTue Jul 16 07:29:12 2019 
+0900
+++ b/src/java.base/share/native/libjava/jni_util.cMon Jul 15 16:07:35 2019 
-0700
@@ -1096,7 +1096,7 @@
}

JNIEXPORT jint JNICALL
-JNU_IsInstanceOfByName(JNIEnv *env, jobject object, char* classname)
+JNU_IsInstanceOfByName(JNIEnv *env, jobject object, const char* classname)
{
 jclass cls;
 if ((*env)->EnsureLocalCapacity(env, 1) < 0)
diff -r 70fab3a8ff02 src/java.base/share/native/libjava/jni_util.h
--- a/src/java.base/share/native/libjava/jni_util.hTue Jul 16 07:29:12 2019 
+0900
+++ b/src/java.base/share/native/libjava/jni_util.hMon Jul 15 16:07:35 2019 
-0700
@@ -208,7 +208,7 @@
  * has been thrown.
  */
JNIEXPORT jint JNICALL
-JNU_IsInstanceOfByName(JNIEnv *env, jobject object, char *classname);
+JNU_IsInstanceOfByName(JNIEnv *env, jobject object, const char *classname);


/* Get or set class and instance fields.

Re: 8131664: Javadoc for PrintStream is now incorrect

[Brian Burkhalter]

Hi Lance,

> On Jul 15, 2019, at 1:33 PM, Lance Andersen  wrote:
> 
> Is there an existing CSR or are you waiting for the review to complete here?

The latter.

> Overall, I think it is OK.
> 
> The existing autoflush wording looks  like it could use some wordsmithing at 
> some point (as I know we do this a little differently in some of the APIs )
> 
> - “A boolean”  not sure we need to state this as it is obvious from the 
> declaration.

It looks like here one could change "A boolean; if true,” to simply “Whether”.

> -  Some places in the JDK, we say  True if ; false otherwise.  I am not 
> sure how many APIs after the really early ones  start  with “if true…”
> 
> Anyways, something to consider for a future todo list I guess :-) 

Might be worth doing. I’ll after any other comments come in.

Thanks,

Brian

Re: 8131664: Javadoc for PrintStream is now incorrect

[Lance Andersen]

Hi Brian,

Is there an existing CSR or are you waiting for the review to complete here?

Overall, I think it is OK.

The existing autoflush wording looks  like it could use some wordsmithing at 
some point (as I know we do this a little differently in some of the APIs )

- “A boolean”  not sure we need to state this as it is obvious from the 
declaration.
-  Some places in the JDK, we say  True if ; false otherwise.  I am not 
sure how many APIs after the really early ones  start  with “if true…”

Anyways, something to consider for a future todo list I guess :-) 

Best
Lance
> On Jul 15, 2019, at 4:03 PM, Brian Burkhalter  
> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8131664 
> 
> http://cr.openjdk.java.net/~bpb/8131664/webrev.00/ 
> 
> 
> This patch proposes to clean up some verbiage in java.io 
> .PrintStream with respect to the encoding being used to 
> convert chars to bytes.
> 
> Thanks,
> 
> Brian
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

[Brian Burkhalter]

There is however this problematic statement in the PrintStream class doc that 
neither of the two alternative versions of the fix addresses:

"Two other features are provided as well. Unlike other output streams, a 
PrintStream never throws an IOException; instead, exceptional situations merely 
set an internal flag that can be tested via the checkError method.”

In both cases this would need to be changed as it is incorrect.

Brian

> On Jul 15, 2019, at 10:14 AM, Brian Burkhalter  
> wrote:
> 
> Here is an alternative version which adds a writeBytes(byte[]) method instead 
> of overriding write(byte[]):
> 
> http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.00/ 
>  
>  >
> 
> This has the advantage of allowing new code to call writeBytes() without a 
> try-catch block without introducing a compatibility issue for code which is 
> already calling write(byte[]) in a try-catch block.

8131664: Javadoc for PrintStream is now incorrect

[Brian Burkhalter]

https://bugs.openjdk.java.net/browse/JDK-8131664 

http://cr.openjdk.java.net/~bpb/8131664/webrev.00/ 


This patch proposes to clean up some verbiage in java.io 
.PrintStream with respect to the encoding being used to 
convert chars to bytes.

Thanks,

Brian

Re: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods

[Jonathan Gibbons]

Generally, the current idiom in JDK API docs is to use a link beginning 
"{@docRoot}/../specs/." such as 
"{@docRoot}/../specs/serialization/index.html"


-- Jon

On 07/13/2019 01:16 PM, Joe Darcy wrote:

PS I've uploaded an updated an iteration of the webrev

    http://cr.openjdk.java.net/~darcy/8202385.4/

to address. the syntactic concerns previously raised. I added

    ...defined by the  Java Object Serialization 
Specification...


which is the current name of the document and is similar to the style 
of reference made in java.io.Serializable. Offhand, I didn't know of 
the correct idiom to refer to the document as a working hyperlink, but 
would be switch to that idiom.


Cheers,

-Joe

On 7/12/2019 8:19 PM, Joe Darcy wrote:

Hi Roger,

On 7/12/2019 1:31 PM, Roger Riggs wrote:

Hi Joe,

As an annotation on a field or method, this is a use site annotation.



It is an annotation intended for the declarations of fields and 
methods of Serializable types.




From the description, the checks that could be added would only be done
if the annotation was present and the annotation is a tag for existing
fields and methods that are part of the serialization spec.



Right; the annotation is semantically only applicable to the fields 
and methods associated with the serialization system.





The signatures of the fields and methods can be known to the 
compiler independent

of the annotation and produce the same warnings.
So this looks like a case of trying to have belt and suspenders.

If the checks are not done when the annotation is not present, then 
it will still be
the case that incorrect or misused fields and methods will still 
escape detection.


Though the details of the compiler check are outside of the scope of 
this annotation,

it seems unclear whether the annotation is necessary.


I have a prototype annotation processor to implement checks for

    JDK-8202056: Expand serial warning to check for bad overloads of 
serial-related methods and ineffectual fields


The current version of the processor does not assume the presence of 
java.io.Serial. The summarize the existing checking methodology:


    If a type is Serialiazable and a field or method has a name 
matching the names of one of the special fields or methods to 
serialization, check that the field or method has the required 
modifiers, type, and, the the case of methods, parameter types and 
exception types.


That is all well and good and represents a large fraction of the 
checking of interest. However, it does not catch a mis-declaration 
like "readobject" instead of "readObject". One could argue that 
sufficiently thorough testing should catch that kind of error; 
however, my impression is that thoroughness of testing is rare in 
practice. I don't think it would be reasonable for javac to have some 
kind of Hamming distance 
(https://en.wikipedia.org/wiki/Hamming_distance) check between the 
name of fields/methods and the name of the serialization related 
fields methods to try to catch such mis-declarations. An annotation 
like java.io.Serial is intended to allow the programmer to indicate 
"yes, this is supposed to be one of the serialization related fields 
or methods" and enable the compile to perform checks against that 
category of error.





Can the name of the annotation be more descriptive?
Just "Serial" seems a bit too simple and does not have a strong 
binding to the Serialization classes and specification.

Alternatives:
   SerialMetadata
   SerialControl
   SerialFunction


From the earlier design iterations "Serial" was chosen to be 
evocative of the "@serial" javadoc tag.


Thanks,

-Joe




39:  There should be a reference to the serialization specification 
for the definition
of the fields and methods to make it clear where the authoritative 
identification is spec'd.


73-75:  Please align the  and  tags on separate lines with 
matching indentation.


77: Extra leading space.

Regards, Roger

On 7/9/19 7:14 PM, Joe Darcy wrote:

Hello,

Returning to some old work [1], please review the addition of a 
java.io.Serial annotation type for JDK 14 to mark serial-related 
fields and methods:


    webrev: http://cr.openjdk.java.net/~darcy/8202385.3/
    CSR: https://bugs.openjdk.java.net/browse/JDK-8217698

Thanks,

-Joe

[1] Previous review threads:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053055.html 



http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054801.html 

Re: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

[Brian Burkhalter]

Here is an alternative version which adds a writeBytes(byte[]) method instead 
of overriding write(byte[]):

http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.00/ 


This has the advantage of allowing new code to call writeBytes() without a 
try-catch block without introducing a compatibility issue for code which is 
already calling write(byte[]) in a try-catch block.

Thanks,

Brian

> On Jul 15, 2019, at 9:00 AM, Brian Burkhalter  
> wrote:
> 
>> On Jul 13, 2019, at 12:00 PM, Tagir Valeev > > wrote:
>> 
>> And whilst great you are fixing up this code, we are but a small fraction of 
>> the world's code
>> that use java.io  and I wonder if this is worth the 
>> compatibility risk ?
>> 
>> Why not introducing a separate writeBytes method like it was done for 
>> ByteArrayOutputStream (JDK-8199713)?
> 
> Actually that seems like a better idea: accomplishes the objective while not 
> introducing a compatibility issue. Note: JDK 8199713 reference above is the 
> CSR of the actual issue [1].
> 
> Thanks,
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8180410 
> 

Re: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

[Roger Riggs]

Looks fine,  Brian.

On 7/15/19 11:58 AM, Brian Burkhalter wrote:

So updated: http://cr.openjdk.java.net/~bpb/8187898/webrev.02/ 


Thanks,

Brian


On Jul 12, 2019, at 4:15 PM, Philip Race  wrote:

In that case just delete the comments and the commented out code ...

-phil.

On 7/12/19, 3:12 PM, Brian Burkhalter wrote:

I think I'd be more inclined to make the code at 970 like that at 1036.

Can’t do this exactly as drawImageBGR at 903 does not throw a PrinterException. 
Have to use RuntimeException.

Brian


On Jul 12, 2019, at 1:39 PM, Phil Race mailto:philip.r...@oracle.com>> wrote:

oh well ... in which I suppose this is the best you can do here.

-phil.

On 7/12/19 1:10 PM, Brian Burkhalter wrote:

(2) I don't know why at 1034 you changed from PrinterIOException to 
PrinterException.

There is no PrinterIOException constructor which accepts a String as its only 
parameter and there is no IOException to pass to a PrinterIOException 
constructor.

Re: [11u] RFR: 8227127: Era designator not displayed correctly using the COMPAT provider

[naoto . sato]

Looks good to me.

Naoto

On 7/15/19 7:19 AM, Severin Gehwolf wrote:

Hi,

Could I please get a review of this 11u backport? The JDK 14 patch
doesn't apply as is due to JDK-8221432 (CLDR data update) not being
present. I've fixed LocaleDataTest.java's @bug line manually. Otherwise
the patch is the same.

Bug: https://bugs.openjdk.java.net/browse/JDK-8227127
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227127/01/webrev/

Testing: tier1 and manual test from the bug on Linux x86_64.

Thanks,
Severin

Re: RFR: 8227615: [TESTBUG] Fix jtreg "jdk/sun/security/util/FilePermCompat/CompatImpact.java" failing with graal issue.

[Vladimir Kozlov]

Good.

Thanks,
Vladimir

On 7/15/19 2:32 AM, Xiaohong Gong (Arm Technology China) wrote:

Hi,

   Please help to review this small patch:
   Webrev: http://cr.openjdk.java.net/~pli/rfr/8227615/webrev.00/
   JBS: https://bugs.openjdk.java.net/browse/JDK-8227615

   Jtreg test "jdk/sun/security/util/FilePermCompat/CompatImpact.java" fails 
due to access denied to JVMCI runtime with graal mode.
   This patch fixes the permission issue by making the application's own policy 
extending the default system policy. Besides it also fixes
the stderr file couldn't be found issue by renaming the file name to the right 
one.

Thanks,
Xiaohong Gong

Re: RFR: 8227574: Fix jtreg access denied failure with graal mode.

[Vladimir Kozlov]

Looks good to me.

Thanks,
Vladimir

On 7/15/19 1:40 AM, Xiaohong Gong (Arm Technology China) wrote:

Hi,

Please help to review the following patch that fixes two jtreg tests failure 
with graal mode due to the access denied issue.
Webrev: http://cr.openjdk.java.net/~pli/rfr/8227574/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8227574

JTReg tests:
   jdk/java/net/URLPermission/URLTest.java
   jdk/javax/sql/testng/test/rowset/spi/SyncFactoryPermissionsTests.java
fail due to losing permission of the JVMCI runtime.
This patch fixes the two tests by making their policy extending the default 
system policy which grants the permissions to jdk.internal.vm.compiler module 
and its dependencies.

Thanks,
Xiaohong Gong

Re: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

[Brian Burkhalter]

Hello,

> On Jul 13, 2019, at 12:00 PM, Tagir Valeev  wrote:
> 
> And whilst great you are fixing up this code, we are but a small fraction of 
> the world's code
> that use java.io  and I wonder if this is worth the 
> compatibility risk ?
> 
> Why not introducing a separate writeBytes method like it was done for 
> ByteArrayOutputStream (JDK-8199713)?

Actually that seems like a better idea: accomplishes the objective while not 
introducing a compatibility issue. Note: JDK 8199713 reference above is the CSR 
of the actual issue [1].

Thanks,

[1] https://bugs.openjdk.java.net/browse/JDK-8180410

Re: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

[Brian Burkhalter]

So updated: http://cr.openjdk.java.net/~bpb/8187898/webrev.02/ 


Thanks,

Brian

> On Jul 12, 2019, at 4:15 PM, Philip Race  wrote:
> 
> In that case just delete the comments and the commented out code ... 
> 
> -phil.
> 
> On 7/12/19, 3:12 PM, Brian Burkhalter wrote:
>> 
>>> I think I'd be more inclined to make the code at 970 like that at 1036.
>> 
>> Can’t do this exactly as drawImageBGR at 903 does not throw a 
>> PrinterException. Have to use RuntimeException.
>> 
>> Brian
>> 
>>> On Jul 12, 2019, at 1:39 PM, Phil Race >> > wrote:
>>> 
>>> oh well ... in which I suppose this is the best you can do here.
>>> 
>>> -phil.
>>> 
>>> On 7/12/19 1:10 PM, Brian Burkhalter wrote:
 
> (2) I don't know why at 1034 you changed from PrinterIOException to 
> PrinterException.
 
 There is no PrinterIOException constructor which accepts a String as its 
 only parameter and there is no IOException to pass to a PrinterIOException 
 constructor.
>> 

[11u] RFR: 8227127: Era designator not displayed correctly using the COMPAT provider

[Severin Gehwolf]

Hi,

Could I please get a review of this 11u backport? The JDK 14 patch
doesn't apply as is due to JDK-8221432 (CLDR data update) not being
present. I've fixed LocaleDataTest.java's @bug line manually. Otherwise
the patch is the same.

Bug: https://bugs.openjdk.java.net/browse/JDK-8227127
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227127/01/webrev/

Testing: tier1 and manual test from the bug on Linux x86_64.

Thanks,
Severin

Re: RFR: JDK-8220807: excessive verbose output when running with --win-per-user-install

[Alexey Semenyuk]

Looks good.

- Alexey

On 7/15/2019 7:48 AM, Andy Herrick wrote:
revised [3] to only suppress these warnings when 
--win-per-user-install option used


[3] http://cr.openjdk.java.net/~herrick/8220807/webrev.02/

/Andy

On 7/12/2019 1:22 PM, Alexey Semenyuk wrote:

Andy,

The fix suppresses warning for system wide installations too,not just 
for per user. Is this by intention?


- Alexey

On 7/12/2019 10:31 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8220807

[2] http://cr.openjdk.java.net/~herrick/8220807/

/Andy

Re: RFR: JDK-8220807: excessive verbose output when running with --win-per-user-install

[Andy Herrick]

revised [3] to only suppress these warnings when --win-per-user-install 
option used


[3] http://cr.openjdk.java.net/~herrick/8220807/webrev.02/

/Andy

On 7/12/2019 1:22 PM, Alexey Semenyuk wrote:

Andy,

The fix suppresses warning for system wide installations too,not just 
for per user. Is this by intention?


- Alexey

On 7/12/2019 10:31 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8220807

[2] http://cr.openjdk.java.net/~herrick/8220807/

/Andy

RFR: 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap

[Tagir Valeev]

Hello!

Please review the following patch:
http://cr.openjdk.java.net/~tvaleev/webrev/8176894/r2/
https://bugs.openjdk.java.net/browse/JDK-8176894

Also please review the associated CSR:
https://bugs.openjdk.java.net/browse/JDK-8227666

The patch was originally submitted by Sergey Kuksenko in March 2017 and
reviewed by some people:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046825.html
The latest patch submitted by Sergey is here:
http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.01/

I asked Sergey why it was abandoned. Seems there were no particular reason
and Sergey asked if I could pick up this work. I will be happy to finish it.

Here's the list of differences between the latest Sergey patch and my patch:
- A bug is fixed in putIfAbsent implementation. TreeMap.java, lines 576 and
596:  `|| oldValue == null` condition added (the null value should be
overwritten no matter what)
- A testcase is added to cover this problem (InPlaceOpsCollisions.java,
also checks HashMap and LinkedHashMap). Not sure if it's the best place for
such test though. Probably a separate file would be better?
- TreeMap.merge() implementation is added.
- TreeMap is added to the FunctionalCMEs.java test (btw this file copyright
says that it's a subject to Classpath exception which is probably wrong?)
- Simple microbenchmark is added: TreeMapUpdate.java

My quick benchmarking shows that optimized version is indeed faster for the
most of the tests and no regression is observed for put() method. Here's
raw results of jdk13-ea+26 and jdk13-ea+26+patch if anybody is interested.
http://cr.openjdk.java.net/~tvaleev/jmh/JDK-8176894/

With best regards,
Tagir Valeev.

RE: RFR [14]: 8227438: [TESTLIB] Determine if file exists by Files.exists in function FileUtils.deleteFileIfExistsWithRetry

[Frank Yuan]

Thank you, Joe and Lance!

Pushed the change.


Frank

> -Original Message-
> From: Joe Wang [mailto:huizhe.w...@oracle.com]
> Subject: Re: RFR [14]: 8227438: [TESTLIB] Determine if file exists by 
> Files.exists in function FileUtils.deleteFileIfExistsWithRetry
> 
> +1
> 
> -Joe
> 
> 
> On 7/11/19 11:32 PM, Frank Yuan wrote:
> > Hi
> >
> >
> >
> > Would you like to review the following patch for
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8227438
> >
> >
> >
> > --- a/test/lib/jdk/test/lib/util/FileUtils.java  Thu Jul 11 15:58:54 
> > 2019 +
> >
> > +++ b/test/lib/jdk/test/lib/util/FileUtils.java   Fri Jul 12 13:33:30 2019 
> > +0800
> >
> > @@ -96,7 +96,7 @@
> >
> >*/
> >
> >   public static void deleteFileIfExistsWithRetry(Path path) throws 
> > IOException {
> >
> >   try {
> >
> > -if (Files.exists(path)) {
> >
> > +if (!Files.notExists(path)) {
> >
> >   deleteFileWithRetry0(path);
> >
> >   }
> >
> >   } catch (InterruptedException x) {
> >
> >
> >
> >
> >
> > Files.exists returns false if the existence cannot be determined, so 
> > replace it with "!Files.notExists" like the change in
> > JDK-8184961.
> >
> >
> >
> > Thanks
> >
> > Frank
> >
> >
> >

Re: RFR: 8227642: [TESTBUG] Make docker tests podman compatible

[Severin Gehwolf]

Hi Misha,

On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledt...@oracle.com wrote:
> Hi Severin,
> 
>The change looks good to me. Thank you for adding support for Podman 
> container technology.
> 
> Testing: I ran both HotSpot and JDK container tests with your patch; 
> tests executed on Oracle Linux 7.6 using default container engine (Docker):
> 
>  test/hotspot/jtreg/containers/   AND 
> test/jdk/jdk/internal/platform/docker/
> 
> All PASS

Thanks for the review and check!

Cheers,
Severin

> 
> Thanks,
> 
> Misha
> 
> 
> On 7/12/19 11:08 AM, Severin Gehwolf wrote:
> > Hi,
> > 
> > There is an alternative container engine which is being used by
> > Fedora
> > and RHEL 8, called podman[1]. It's mostly compatible with docker.
> > It
> > looks like OpenJDK docker tests can be made podman compatible with
> > a
> > few little tweaks. One "interesting" one is to not assert
> > "Successfully
> > built" in the build output but only rely on the exit code, which
> > seems
> > to be OK for my testing. Interestingly the test would be skipped in
> > that case.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642
> > webrev: 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/
> > 
> > Adjustments I've done:
> >   * Don't assert "Successfully built" in image build output[2].
> >   * Add /usr/sbin to PATH as the podman binary relies on iptables
> > for it
> > to work which is in /usr/sbin on Fedora
> >   * Allow for Metrics.getCpuSystemUsage() and
> > Metrics.getCpuUserUsage()
> > to be equal to the previous value. I've found those counters to
> > be
> > slowly increasing, which made the tests unreliable.
> > 
> > Testing:
> > 
> > Running docker tests with docker as engine. Did the same with
> > podman as
> > engine via -Djdk.test.docker.command=podman on Linux x86_64. Both
> > passed (non-trivially).
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> > 
> > [1] https://podman.io/
> > [2] Image builds with podman look
> >  like ("COMMIT" over "Successfully built"):
> > STEP 1: FROM fedora:29
> > STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean
> > all
> > --> Using cache
> > 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d
> > STEP 3: COPY TestMetrics.class  TestMetrics.java /opt/
> > 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8
> > STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-
> > modules java.base --add-exports
> > java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics
> > STEP 5: COMMIT fedora-metrics-11
> > d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e
> >