RFR 8066085: Need a sanity test for rmic -iiop
FELIX YANG
felix.yang at oracle.com
Fri Dec 19 09:56:13 UTC 2014
Hi Stuart,
please review the updated webrev:
http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.01/
Thanks,
-Felix
On 12/12/2014 4:08 PM, Stuart Marks wrote:
> On 12/11/14 8:41 PM, FELIX YANG wrote:
>> Hi all,
>> please review the fix to add a sanity checking for rmic -iiop
>> compiling.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8066085
>>
>> Webrev:
>> http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.00/
>
> Hi Felix,
>
> Thanks for picking up the writing of this test. I have several comments.
>
> 1. Usually we try to avoid naming tests after bug IDs. There are such
> tests in the suite but most tests have more descriptive names. I'd
> suggest something like "iiopSanityTest".
>
> 2. There are other rmic tests in jdk/test/sun/rmi/rmic; the test
> should be moved there (and the path to the TestLibrary updated
> correspondingly).
>
> 3. The test summary should be a bit more explicit. Instead of "a
> sanity test for rmic -iiop compiling" I'd suggest something like
> "Compiles a PortableRemoteObject with rmic -iiop and ensures that stub
> and tie classes are generated."
>
> 4. When invoking rmic, you need to make sure to pass the -iiop option.
>
> 5. Add check for the _Tie class as well as the _Stub class. Not that
> it really matters, since we know these classes are in the unnamed
> package, but the stub and tie class files would end up in directories
> corresponding to their package names -- if they were in a named package.
>
> 6. In doTest(), the try/catch of InterruptedException and IOException
> and call to TestLibrary.bomb() is mostly unnecessary. (Yes, other RMI
> tests do this, and I've been removing it where appropriate. In the RMI
> test library, the bomb() call merely wraps and rethrows the exception,
> and doesn't really add any value. It's like calling fail() in a
> test-ng test.) In general an uncaught exception will cause a jtreg
> test to fail, so you might as well just declare the method with
> "throws Exception" and let them propagate. This helps reduce clutter.
>
> 7. Similarly I'm not sure it's necessary to check the classname
> argument for null; the failure should be apparent enough if classname
> is null. But if you think it's worth it, a concise way to null-check
> an argument is to use Objects.requireNonNull().
>
> 8. The "rmiComplie" method is misnamed (or typo'd); I'd suggest
> something like "runRmic".
>
> 9. Changing the directory of the rmic subprocess is confusing, because
> it makes different parts of the program deal with different paths to
> the same files. In addition, switching directories to the test.classes
> directory will leave the stub/tie classes there, which could possibly
> confuse future test runs, since that directory isn't necessarily
> cleared between test runs.
>
> The default working directory of jtreg tests is the "scratch"
> directory, which is cleared before each test run. Leaving the current
> directory as-is when running the subprocesses will write the generated
> stub/tie classes to the scratch directory, which is the right thing.
>
> This implies that you'll need to add the -classpath argument and a
> path to the test.classes directory to the rmic command line.
>
> Thanks,
>
> s'marks
>
>
More information about the core-libs-dev
mailing list