RFR: [test,16] JDK-8164597 : TestIOException.java fails after push for JDK-8164130.

[Jonathan Gibbons]

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.gibbons at 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/
>>