Was our OpenJDK documentation ever updated to highlight the @modules
change for JDK 9 ? Could we edit the developer's guide[1] to highlight
the @modules tag [2]. The current doc states that an @bug tag should be
supplied. It would help to document why/when an @modules tag would be
required also.
[1] http://openjdk.java.net/guide/changePlanning.html
[2] http://openjdk.java.net/jtreg/tag-spec.html
Regards,
Sean.
On 25/05/2016 19:46, Alexandre (Shura) Iline wrote:
On May 25, 2016, at 11:31 AM, Xueming Shen <xueming.s...@oracle.com> wrote:
On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote:
Sherman,
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.
Shura
and we would want to know why. So the intention here is not to skip the zipfs
test silently, if
the zipfs is missing from the jdk image. That said, arguably these existing
tests are the unit tests
for the zipfs functionality, it might be desired to have separate test(s) for
testing the availability
of the zipfs...
sherman
Shura
On May 25, 2016, at 10:49 AM, Xueming Shen<xueming.s...@oracle.com> wrote:
Should it? My understanding is that those tests don't use zipfs directly
from zipfs module, it access it via java.base's FileSystemProvider interface.
It depends on the jdk runtime to pick up the zipfs "provider" to function. So
if the jdk runtime fails to pick up the zipfs module for whatever reason,
that's something we want to detect as well?
-Sherman
On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote:
Hi.
Should the tests also declare “@modules jdk.zipfs”?
Shura
On May 25, 2016, at 9:39 AM, Xueming Shen<xueming.s...@oracle.com> wrote:
Hi,
Please help review the changes for the following zipfs related bug fixes
JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when
invoking register()
JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result
JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending
with slash /
JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize()
issue:
https://bugs.openjdk.java.net/browse/JDK-8147539
https://bugs.openjdk.java.net/browse/JDK-8153248
https://bugs.openjdk.java.net/browse/JDK-8146754
https://bugs.openjdk.java.net/browse/JDK-8139956
webrev:
http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/
The changes are relative easy.
(1) ZipPath.initOffsets() should deal with empty path specially, as the
UnixPath impl does
(2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care
of at
ZipPath.normalize(byte[], int), but is missed in the "main" method)
(3) ZipPath.register() should throw PME as suggested.
Thanks,
Sherman
