Yes, it's an oversight that the ProblemList entry is commented out and
not deleted. I'll fix that.
It is intended to be helpful to users to provide details in the
exception about the file causing the problem. The different exceptions
identify the file in question, which is probably more important/useful
than the READ/WRITE, which is there to help provide helpful diagnostic
messages. This is all working around the appalling under-specification
of java.io.IOException, which provides NO mandated information other
than the single bit of info that "an IO error occurred".
I don't consider it would be progress if end users have to analyze stack
traces to determine the context of a message that has been reported.
-- Jon
On 6/24/20 5:19 AM, Pavel Rappo wrote:
Jon,
Consider deleting that entry in ProblemList.txt instead of commenting it out.
Otherwise, the change looks good.
***
That change reminded me of a question I had: do we really need to split I/O errors into
"read" and "write" errors and associate filenames with I/O errors on the Java
level?
I'm asking this because it's very tempting to refactor that code. For example,
thanks to NIO, we could fold code like this into a one-liner:
public void copyFile(DocFile fromFile) throws DocFileIOException {
try (OutputStream output = openOutputStream()) {
try (InputStream input = fromFile.openInputStream()) {
byte[] bytearr = new byte[1024];
int len;
while ((len = read(fromFile, input, bytearr)) != -1) {
write(this, output, bytearr, len);
}
} catch (IOException e) {
throw new DocFileIOException(fromFile,
DocFileIOException.Mode.READ, e);
}
} catch (IOException e) {
throw new DocFileIOException(this, DocFileIOException.Mode.WRITE,
e);
}
}
I'm pretty sure that if any of the java.nio.file.Files's methods throws
IOException, the user will be able to quickly and accurately diagnose the error
using the accompanying message.
Should I create an RFE to investigate that?
-Pavel
On 15 Jun 2020, at 19:41, Jonathan Gibbons <jonathan.gibb...@oracle.com> wrote:
Please review a change to enable a javadoc test to be removed from the problem
list.
The test was excluded because an IOException was occurring when running the test
on Windows, Most of the change here is support code to diagnose the problem, and
to investigate whether the issue can be fixed.
Eventually, a reference was found on a Microsoft site, indicating that normal
directories
cannot be made read-only on Windows. Thus the primary fix is to skip each
test-case
if the setup for the test case fails to create a readonly directory on Windows.
In addition doc comments and -Xdoclint:-missing are added to reduce the number
of
irrelevant diagnostics in the output.
In conjunction with the fix for JDK-8152313, this will fix all javadoc tests on
the
LangTools exclude list.
-- Jon
JBS: https://bugs.openjdk.java.net/browse/JDK-8164597
Webrev: http://cr.openjdk.java.net/~jjg/8164597/webrev.00/
