JDK-8158735 : Unmarshal an image/png type JAXBElement from an xml file and then marshal back to xml, the png content is changed
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.imageio
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2016-02-10
  • Updated: 2017-02-04
  • Resolved: 2017-01-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Relates :  
JDK-6488522 - PNG writer should permit setting compression level and iDAT chunk maximum size
Description
Create unmarshaller with the following xsd:
<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:xmime="http://www.w3.org/2005/05/xmlmime">
        <xs:import namespace="http://www.w3.org/2005/05/xmlmime" schemaLocation="xmime.xsd"/>       
        <!-- as a value of JAXBElement -->
        <xs:element name="png" type="xs:base64Binary" xmime:expectedContentTypes="image/png"/>    
</xs:schema>

and unmarshal the following xml:
<?xml version="1.0" encoding="UTF-8"?>
      <png xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:xmime="http://www.w3.org/2005/05/xmlmime">iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAkElEQVR42qWT0Q3AIAhEGcRBXMRBHMRFHMRBXITmkmosRTHhEj6qxwtQJCJiZxDXWnkVvldTSomleu8cQrABRvIZABPMh+Q94DJ5D5BnENq5GuJOMUYfAC24AFDO+R6gnStV6IDxK7U7UcXf1FqbBgzOqMJeZQClSin3AK0KaL4F9DSWB6FM+nM/4l0s33N+AJVplWD8cBu5AAAAAElFTkSuQmCC</png>

and then marshal back, but got png content:
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAmElEQVR4XqWT0Q3AIAhEGcRBXMRBHMRFHMRBXITmktIoYtV4CR+V4wlqiYj4MohzztwK360phNDloVorO+fWgEXxPwAmmFup4jlgs3gO0GsQxlHFNmAm770uPgNghCsAFGPcB1jrRhc2QK7SyqkuRlMp5TPg4LRUFyNAdpcAUCultA+wuoC+fwEzyeNBGCfd5SXeh9UbT+MBlWmVYI2LyuwAAAAASUVORK5CYII=
Comments
Attached Bug8158735.java sets proper PNGImageWriter param so that deflater value will be 9 with latest JDK PNGImageWriter code. In this test case original encoded stream and JDK PNGImageWriter decoded-encoded stream will be same.
25-01-2017
The default deflater level for the PNGImageWriter in JDK9 is now 4. This was part of the fix JDK-6499522. Before this change it used deflaterLevel 9 by default. After this change it calculates deflaterLevel based on compression quality values provided in PNGImageWriteParam, if PNGImageWriteParam is null it will use deflaterLevel 4. In the present implementation of JDK9 if the application specifies compression values that result in deflaterLevel 9 the test case that is failing in this bug will pass again. So we can assume that original encoded data was also at deflaterLevel of 9. This suggests there is a strong likelihood that the png was originally encoded by this JDK PNGImageWriter before JDK-6499522 since a different writer may have different defaults. There is no specification or guarantee of what compression level will be used by default but that is just one example of something that may make this JAXB test fail, even if it is the cause in this case. Relying on making byte to byte comparison between two encoded stream of png image data is fragile. An image encoder may choose (nor not choose) to include many pieces of information, for example metadata documenting creation time. So the result is that you cannot make this assumption even if you do encode-decode-re-encode in the same VM since that creation time will change. The conclusion of the above is that this is "not an issue".
25-01-2017
The best way to compare between two encoded streams is to decode them and get BufferedImage and compare pixels values, we never should be comparing byte to byte encoded stream of data.
25-01-2017
This issue is introduced in b105 build of JDK9. And specifically the png content change is visible only after the changes done under JDK-6488522.
18-01-2017
Changed the component to imageio according to David's analysis.
17-01-2017
Copy developer's comment: Looking at the test failure, it doesn't seem to me that the change should couse such error - the patch basically fixes case when JAX-B fails to load at all. The failure looks really suspicious and I have no idea what could be a cause
20-05-2016