RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()
xueming.shen at oracle.com
Wed May 25 19:01:34 UTC 2016
On 05/25/2016 11:46 AM, Alexandre (Shura) Iline wrote:
>> On May 25, 2016, at 11:31 AM, Xueming Shen<xueming.shen at oracle.com> wrote:
>> On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote:
>>> Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:”-limitmods java.base” in the JTReg command line. The tests will be selected for execution, but would they work?
>>> I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available.
>> Hi Shura,
>> Yes, the test will fail if the jdk.zipfs is absence. With the assumption that zipfs module should
>> be available to the jdk images/runtime by default. If it's not there/available, something is wrong
> Well, not necessarily.
> Since JTReg is taking on the burden to select tests for execution based on the available modules, be it -limitmods option or a custom built limited JDK image, the test suite will be used to execute tests for compact profiles, for example. We will be relying on JTReg to select proper tests. The plan is to get rid of the test groups for compact profiles when the test markup is complete.
Sure, if there is such "plan".
Here is the updated webrev with the @module tag.
More information about the nio-dev