jps fix and test exclude list for jdk-module-image

[Mandy Chung]

  On 1/19/11 6:59 AM, Alan Bateman wrote:
>
> Apologies for the late review, but I finally got to this.
>
No problem, thanks for the review.

> The addition of the jdk_jigsaw tests looks good but it's not clear to 
> me why the jdk_rmi batch is being added to JDK_TEST_LIST (it's also on 
> JDK_TEST_LIST2, the batches that require a display for some reason). I 
> wonder if this is something we should get sorted out upstream as the 
> jdk_rmi batch is not run by default (to my knowledge).
>

The addition of the jdk_rmi tests was temporary for my own testing that 
I missed to take it out. I'll take it out.  That was added to workaround 
that when I used jprt -testset all option, the JDK_TEST_LIST2 test jobs 
just exit.  It's on my list to investigate.

> Also you've added a few tests to the problem list:
>

The problem list is specific to modules build (i.e. testing 
jdk-module-image). I'm going to sync with jdk 7 and I will update this 
list or get them sorted out upstream if it's an issue in JDK 7.
>  85 java/nio/channels/FileChannel/ClosedByInterrupt.java    generic-all
>  86 java/nio/channels/SocketChannel/AdaptSocket.java        linux-x64
>  87 java/nio/channels/SocketChannel/Connect.java            linux-x64
>  88 java/nio/MappedByteBuffer/Force.java                    windows-i586
>
> In the case of java/nio/channels/FileChannel/ClosedByInterrupt.java, I 
> will guess that jdk and langtools weren't in sync at the time of the 
> test run. I can't tell why the next two are on the list. In the case 
> of java/nio/MappedByteBuffer/Force.java  I assume it's the clean-up 
> issue we have on Windows where file mappings can remain for a period 
> after the process terminates. This isn't technically a test bug but I 
> have created 7012823 to track looking for ideas on how to avoid these 
> false failures.
>
> You've also added a few RMI tests to the list:
>
> 100 # Need further investigation
> 101 # TestFailedException: TEST FAILED: could not create registry
> 102 sun/rmi/runtime/Log/checkLogging/CheckLogStreams.java   solaris-all
> 103 sun/rmi/runtime/Log/checkLogging/CheckLogging.java      solaris-all
> 104
> 105 java/rmi/transport/dgcDeadLock/DGCDeadLock.java         solaris-all
>
> I guess we aren't seeing these upstream because the jdk_rmi batch 
> isn't run (as I mentioned above).
>
> The updates to the class analyzer look fine to me. Amusing to see 
> application.vendor=mchung :-)
>
> The changes to get jps to print the correct information mostly looks 
> okay to me. Some of the code in the launcher is starting to get tricky 
> with the tools running in module mode.
>
Yeah, it's starting to get tricky and some of the code can be removed 
when we support multiple entry points.
> A small comment is that it would be nice if SetJavaMainProp didn't use 
> sprintf.
>
I'll fix it (thanks for catching it).

> On the jvmstat counters, should we skip create the javaModule counter 
> if not set?
>

I was thinking if there might be a need to determine if the application 
is running in a modular JDK and the presence of the javaModule counter 
would be an indication.  Given it's unclear if that is needed, I will 
skip creating it if not set for now.

> In MonitoredVmUtil.java, you're using "sm" as the StringMonitor in a 
> few places that a bit inconsistent with the existing code. Should it 
> be javaModule instead?
>

Will clean that up.

> That's all I have.
>
Thanks
Mandy