JDK-8190919 : StaX buffers do not really close underlying buffers
  • Type: Bug
  • Component: xml
  • Sub-Component: jaxp
  • Affected Version: 8,9
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows
  • CPU: x86_64
  • Submitted: 2017-11-01
  • Updated: 2017-12-05
  • Resolved: 2017-11-17
Related Reports
Relates :  
JDK-6375901 - Zephyr closes the underlying OutputStream incorrectly
Description
FULL PRODUCT VERSION :
java version "1.8.0_152"
Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.3.9600]

A DESCRIPTION OF THE PROBLEM :
StAX XMLEventReader, XMLEventWriter, XMLStreamReader, XMLStreamWriter API close() method does not close uderlying resources.

This close() method should be propagated as in other java.io.* buffers!

REGRESSION.  Last worked in version 6u45

ADDITIONAL REGRESSION INFORMATION: 
http://bugs.java.com/view_bug.do?bug_id=6539065
http://bugs.java.com/view_bug.do?bug_id=6407860

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
xWriter = outputFactory.createXMLEventWriter(new BufferedOutputStream(new FileOutputStream(outputFile)), "UTF-8");

// use the writer normally

xWriter .close();

Files.delete(outputFile);

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
File can be deleted!
ACTUAL -
File are not deleted!

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception will be thrown indicating that file cannot be moved or deleted as it's locked.

REPRODUCIBILITY :
This bug can be reproduced always.
Comments
https://docs.oracle.com/javase/9/docs/api/javax/xml/stream/XMLStreamWriter.html#close-- https://docs.oracle.com/javase/9/docs/api/javax/xml/stream/XMLStreamReader.html#close-- Added links to the documentation that states "This method does not close the underlying input source."
05-12-2017
There had been for and against XMLStreamWriter/Reader closing the underlying stream during JDK 6 development, both had use cases. There is a legitimate argument that the XML writer/reader shall be consistent with java.io. However, the JSR 173 1.0 specification clearly required that the XMLStreamWriter/Reader "must not close the underlying output stream." Given the spec, I'm closing the issue as not-an-issue.
17-11-2017
To reproduce the issue, run the attached test case. JDK 6u45 - Fail JDK 8u151 - Fail JDK 9.0.1 - Fail Output on JDK 9.0.1: java.nio.file.FileSystemException: write_out.xml: The process cannot access the file because it is being used by another process. at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108) at java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:270) at java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105) at java.base/java.nio.file.Files.delete(Files.java:1134) at TestStandAlone.main(TestStandAlone.java:31)
08-11-2017