[10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Prahalad kumar Narayanan
Hello Everyone

Good day to you.

Request your time in reviewing a fix for the bug
. JDK-8164971    PNG metadata does not handle ImageCreationTime

Root Cause:
. First, the PNGImageReader 's logic skips parsing of 'any' chunk once IDAT is found.
. Hence, if the ancilliary text chunks appear after IDAT chunk, they are not processed at all.
. Second, the parsing of text chunks does not check for 'Creation Time' keyword.
. As a result the image creation time is never retrieved from .png image.
. The converse is true as well- While writing a png image, the creation time is not written to text chunk

Details on the Fix:
. PNGImageReader
    . Logic has been fixed to continue parsing chunks until IEND chunk is found
    . Methods that process text chunks now check for the presence of 'Creation Time' and retrieve the time information.
. PNGMetadata:
    . New methods and variables to support image creation time in metadata.
    . Proper use of DateTimeFormatter.RFC_1123_DATE_TIME to decode time from text chunk and encode time to text as well.
    . Changes to existing methods (that allow node retrieval & merge) for reading and updating creation time.
. Test Case & Test Image
    . The test case- PngCreationTimeTest, checks the following use-cases
        . Decoding creation time from duke.png 's text chunk.
            . I created the image using gimp and added text chunk programmatically with Creation Time in it
        . Updating the image creation time using- mergeTree (nativeTree) and inspecting same value in standard Document node
        . Updating the image creation time using- mergeTree (standardTree) and inspecting same value in native tree's text entry.

Other Details:
. The changes were tested with Jtreg and JCK suites
. No regressions were seen.

Kindly review the changes at your convenience and provide your suggestions.

Review Link:
http://cr.openjdk.java.net/~pnarayanan/8164971/webrev.00/

Thank you for your time in review
Have a good day
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Jayathirth D v
Hello Prahalad,

Please find my inputs.
As per PNG Specification for text chunks http://libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.Anc-text . There can be multiple chunks with same keyword.

1) In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123. So if there are multiple text chunks and if the latest chunk doesn't follow RFC1123 while decoding it will result in "creation_time_present" to be false. In case where we are not able to decode the provided text, we should not update "creation_time_present" to false.

2) From the PNGMetadata. extractCreationTimeFromText() implementation I see that, if there are multiple text chunks following RFC1123 text we update our standard metadata node with last parsed chunk. This information should be covered properly in comments as it is specific to our implementation and it is not part of PNG specification.

3) Since we are maintaining standard metadata "ImageCreationTime" info from the last RFC1123 compliant text chunk while decoding. When an user adds new "ImageCreationTime" standard node which follows RFC1123 text to already present metadata, we should update the last text chunk from which we have captured creation time information while decoding. In the present iteration of code in PNGMetadata.encodeCreationTimeToText() we are updating the first available text chunk with the new information provided in stanrdardmetadata node.

4) Also when user adds new native metadata creation time node with RFC1123 compliance to already present list of creation time nodes. We should make sure that the newly added native time chunk is the one that should be updated when one more addition of  standard metadata "ImageCreationTime" node happens. Basically for 3 & 4 points we have to maintain what is the active native text chunk and what should be its corresponding creation time information in standard metadata.

5) One more question is about how are we planning to maintain IIOMetadata consistency between multiple decoding & encoding sequences. We decode the metadata of PNG file as text chunks appear but we encode multiple same text chunks collectively. So when an user gets IIOMetadata of an image and updates it with multiple native and standard creation time chunks and later encode it. How we will maintain that what is the primary native text chunk from where we have to update standard metadata creation time.

6) It's better to maintain /* */ format for multiple line comments then using multiple //.

Thanks,
Jay
-----Original Message-----
From: Prahalad Kumar Narayanan
Sent: Saturday, April 22, 2017 4:33 PM
To: [hidden email]
Subject: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Hello Everyone

Good day to you.

Request your time in reviewing a fix for the bug
. JDK-8164971    PNG metadata does not handle ImageCreationTime

Root Cause:
. First, the PNGImageReader 's logic skips parsing of 'any' chunk once IDAT is found.
. Hence, if the ancilliary text chunks appear after IDAT chunk, they are not processed at all.
. Second, the parsing of text chunks does not check for 'Creation Time' keyword.
. As a result the image creation time is never retrieved from .png image.
. The converse is true as well- While writing a png image, the creation time is not written to text chunk

Details on the Fix:
. PNGImageReader
    . Logic has been fixed to continue parsing chunks until IEND chunk is found
    . Methods that process text chunks now check for the presence of 'Creation Time' and retrieve the time information.
. PNGMetadata:
    . New methods and variables to support image creation time in metadata.
    . Proper use of DateTimeFormatter.RFC_1123_DATE_TIME to decode time from text chunk and encode time to text as well.
    . Changes to existing methods (that allow node retrieval & merge) for reading and updating creation time.
. Test Case & Test Image
    . The test case- PngCreationTimeTest, checks the following use-cases
        . Decoding creation time from duke.png 's text chunk.
            . I created the image using gimp and added text chunk programmatically with Creation Time in it
        . Updating the image creation time using- mergeTree (nativeTree) and inspecting same value in standard Document node
        . Updating the image creation time using- mergeTree (standardTree) and inspecting same value in native tree's text entry.

Other Details:
. The changes were tested with Jtreg and JCK suites . No regressions were seen.

Kindly review the changes at your convenience and provide your suggestions.

Review Link:
http://cr.openjdk.java.net/~pnarayanan/8164971/webrev.00/

Thank you for your time in review
Have a good day
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Brian Burkhalter-2
Hi Jay,

On Jun 7, 2017, at 3:42 AM, Jayathirth D V <[hidden email]> wrote:

As per PNG Specification for text chunks http://libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.Anc-text . There can be multiple chunks with same keyword.

Yep: "Any number of text chunks can appear, and more than one with the same keyword is permissible."

1) In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123. So if there are multiple text chunks and if the latest chunk doesn't follow RFC1123 while decoding it will result in "creation_time_present" to be false. In case where we are not able to decode the provided text, we should not update "creation_time_present" to false.

I have not looked at the code but what I am wondering about is how it handles this part of the specification from the same section:

"For the Creation Time keyword, the date format defined in section 5.2.14 of RFC 1123 is suggested, but not required [RFC-1123]. Decoders should allow for free-format text associated with this or any other keyword.”  

Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123. What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50”?

If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary. One could for example use the value of the first one, the value of the last one, the oldest one, etc.

What examples of actual PNG “real world" files have been used for testing? For example ones from PngSuite [2] or those produced by typical user applications such as Apple’s “Preview” or the Windows program “IrfanView” [3] or other common image viewers?

Thanks,

Brian

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Prahalad kumar Narayanan
Hello Brian and Jay

Good day to you.
Thank you for your time and review suggestions.

Let me answer to each of your review suggestions here:

Brian:
> Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123.
> What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"?

    . I understand the suggestion that ISO 8601 is also a valid representation for the 'time' data.
    . Since there is no mention of using the ISO standard for time in the PNG Specification, I 'm not checking for this format in the encoded time data.
    . If required, we can attempt to check if our DateTimeFormatter.ISO_* decode time from the String.
    . But this only adds more complexity to the logic because tEXt chunks could contain date without the zone information Or date without time information etc.,
    . I 'm not sure how our JDK's DateTimeFormatter.ISO_* work. I will check and get back.

> If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary.
> One could for example use the value of the first one, the value of the last one, the oldest one, etc.

    . Yes. There is no mention about the logic to deploy in the PNG specification.
    . In the code changes, I 've used the last successfully decoded text chunk's information to set the value of Standard/ Document/ ImageCreationTime.
    . However, the reverse isn't true. Once decoding of image is complete, any update to metadata using Standard/ Document/ ImageCreationTime node updates the first available text chunk and not the last successfully decoded text chunk. (A bug in code change that Jay has pointed out.)

> What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2]

    . I manually created a PNG file with our Java logo in it and ImageCreationTime in the tEXt chunk.
    . But this is a good suggestion to use a test suite. I will check with images in the test suite and update.

Jay:
> In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123

    . Yes. This will be corrected.

> From the PNGMetadata. extractCreationTimeFromText() implementation I see that, if there are multiple text chunks following RFC1123 text we update our standard metadata node with last parsed chunk. This information should be covered properly in comments as it is specific to our implementation and it is not part of PNG specification.

    . I generally substantiate the logic with enough comments. Looks like I 've missed this one.
    . Since API documentations are implementation-independent, I will not update comments as part of APIs but only internal implementation within the PNGMetadata.
    . When I post the new webrev, this will be corrected.

> When an user adds new "ImageCreationTime" standard node which follows RFC1123 text to already present metadata, we should update the last text chunk from which we have captured creation time information while decoding

    . A correction. The Standard/ Document/ ImageCreationTime does not need to follow RFC1123.
    . The attributes are integers with year, month, day, hour, minutes, seconds.
    . It's the text chunks in the native metadata tree that 'may' conform to RFC1123 standard.

> In the present iteration of code in PNGMetadata.encodeCreationTimeToText() we are updating the first available text chunk with the new information provided in stanrdardmetadata node.

    . Yes. This is a very good find. Thank you.
    . I will be correct this in the next webrev.

> One more question is about how are we planning to maintain IIOMetadata consistency between multiple decoding & encoding sequences.

    . Well, We discussed on this in-detail. For the benefit of others in community, let me put the findings here-
    . Our PNG image writer writes all similar text chunks together. For Example: all tEXt chunks together, all iTXt chunks together etc.,
    . So if user adds multiple text chunks with Creation Time, the ordering is not ensured at the time of encoding.
    . Thus, we cannot guarantee consistency across the lifetime of decoder. (between multiple decode & encode sequences)
    . Any attempt to provide consistency will resemble a HACK and a messy code, which I don't wish to do now.
    . Besides, the PNG spec does not lay any logic to choose the creation time in these circumstances. Hence, I would prefer to leave the code as is.

> It's better to maintain /* */ format for multiple line comments then using multiple //.

    . In this regard, I 've used the file's existing code-comment style so that changes are consistent and ensures code readability.
    . Refer to Line 254 (existing code)
            254     // tRNS chunk
            255     // If external (non-PNG sourced) data has red = green = blue,
            256     // always store it as gray and promote when writing

    . In my view, code readability gets affected if the existing code // multi-line comments were preceded by comments like
            237     /*
            238      * creation_time_present- Indicates that the native metadata contains
            239      * the image creation time initialized in its variables. The flag is set
            240      * true after successfully decoding the time represented as string in the
            241      * text chunks or when user explicitly provides the creation time by
            242      * manipulating the node tree.
            243      */
    . I would like to receive the suggestion from others as well on this before I continue to modify the comment style in my code changes.

Thank you once again for your time in review and detailed suggestions.

I will get back with changes soon.

Thank you
Have a good day

Prahalad N.

---------------------------------------
From: Brian Burkhalter
Sent: Thursday, June 08, 2017 4:20 AM
To: Jayathirth D V
Cc: Prahalad Kumar Narayanan; [hidden email]
Subject: Re: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Hi Jay,

On Jun 7, 2017, at 3:42 AM, Jayathirth D V <[hidden email]> wrote:


As per PNG Specification for text chunks http://libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.Anc-text . There can be multiple chunks with same keyword.

Yep: "Any number of text chunks can appear, and more than one with the same keyword is permissible."


1) In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123. So if there are multiple text chunks and if the latest chunk doesn't follow RFC1123 while decoding it will result in "creation_time_present" to be false. In case where we are not able to decode the provided text, we should not update "creation_time_present" to false.

I have not looked at the code but what I am wondering about is how it handles this part of the specification from the same section:

"For the Creation Time keyword, the date format defined in section 5.2.14 of RFC 1123 is suggested, but not required [RFC-1123]. Decoders should allow for free-format text associated with this or any other keyword."  

Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123. What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"?

If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary. One could for example use the value of the first one, the value of the last one, the oldest one, etc.

What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2] or those produced by typical user applications such as Apple's "Preview" or the Windows program "IrfanView" [3] or other common image viewers?

Thanks,

Brian

[1] https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations
[2] http://www.schaik.com/pngsuite/pngsuite.html
[3] https://en.wikipedia.org/wiki/IrfanView
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Prahalad kumar Narayanan
Hello Everyone

Good day to you.

This is a follow-up to the bug fix for
    [JDK-8164971]    PNG Metadata does not handle image creation time.

First, Thanks to Brian and Jay for their time in review & feedback.
    . I 've addressed the review suggestions and the updated code is available for review.
    . Webrev Link: http://cr.openjdk.java.net/~pnarayanan/8164971/webrev.01/

Description on changes are as follows:

Brian's Suggestions:
> Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123.
> What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"?
    . Update:
    . The logic supports decoding combined Date Time based on RFC1123 and ISO Formats.
    . This has been realized with JDK's inbuilt DateTimeFormatter objects.

> If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary.
> One could for example use the value of the first one, the value of the last one, the oldest one, etc.
    . Update:
    . The logic uses the time retrieved from the last decoded text chunk (tEXt, iTXt, or zTXt) with Creation Time to initialize Standard/Document/ImageCreationTime.
    . Similarly, when metadata is updated with Standard/Document/ImageCreationTime, the same is encoded within the last decoded text chunk.

> What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2]
    . Update:
    . I checked the PNG files of the test suite. Unfortunately none contain ancillary text chunk with 'Creation Time'
    . Hence, I manually created a PNG file with tEXt chunk containing Creation Time to test the changes.

Jay's Suggestions:
> In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123
    . Update:
    . This has been corrected.
    . Please Note: The method name in the internal PNGMetadata class has been changed to decodedImageCreationTimeFromTextChunk

> I see that, if there are multiple text chunks following RFC1123 text we update our standard metadata node with last parsed chunk. This information should be covered properly in comments as it is specific to our implementation and it is not part of PNG specification.
    . Update:
    . This has been addressed. The logic is substantiated with comments.

> In the present iteration of code in PNGMetadata.encodeCreationTimeToText() we are updating the first available text chunk with the new information provided in stanrdardmetadata node.
    . Update:
    . Yes. This is a very good find. Thank you.
    . The logic has been corrected to update the encoded time in the last decoded text chunk.

> It's better to maintain /* */ format for multiple line comments then using multiple //.
    . Update:
    . I had initially used // to keep my changes in synch with the existing code that uses // for multiline comments.
    . I 've reverted to /* */ to comply with guidelines.

Other Information:
    . The code changes have been run through Jtreg and JCK test suites. No new regressions were seen.
    . Besides, the test case available with the webrev is comprehensive and tests the following scenarios-
        . Proper decoding of text chunks with 'Creation Time' from the test image.
        . Proper decoding of time in RFC1123 and ISO format. (Test provides incorrect values as well and code doesn't crash)
        . Proper values in Native tree's text chunks after updating metadata with Standard/Document/ImageCreationTime.
        . Proper values in Standard/Document/ImageCreationTime after updating metadata with text chunks using Native tree.

Kindly review the changes when your time permits and provide your feedback.

Thank you
Have a good day

Prahalad N.

---------------------------------------
From: Brian Burkhalter
Sent: Thursday, June 08, 2017 4:20 AM
To: Jayathirth D V
Cc: Prahalad Kumar Narayanan; [hidden email]
Subject: Re: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Hi Jay,

On Jun 7, 2017, at 3:42 AM, Jayathirth D V <[hidden email]> wrote:


As per PNG Specification for text chunks http://libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.Anc-text . There can be multiple chunks with same keyword.

Yep: "Any number of text chunks can appear, and more than one with the same keyword is permissible."


1) In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123. So if there are multiple text chunks and if the latest chunk doesn't follow RFC1123 while decoding it will result in "creation_time_present" to be false. In case where we are not able to decode the provided text, we should not update "creation_time_present" to false.

I have not looked at the code but what I am wondering about is how it handles this part of the specification from the same section:

"For the Creation Time keyword, the date format defined in section 5.2.14 of RFC 1123 is suggested, but not required [RFC-1123]. Decoders should allow for free-format text associated with this or any other keyword."  

Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123. What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"?

If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary. One could for example use the value of the first one, the value of the last one, the oldest one, etc.

What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2] or those produced by typical user applications such as Apple's "Preview" or the Windows program "IrfanView" [3] or other common image viewers?

Thanks,

Brian

[1] https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations
[2] http://www.schaik.com/pngsuite/pngsuite.html
[3] https://en.wikipedia.org/wiki/IrfanView
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Jayathirth D v
Hello Prahalad,

The decoding and encoding of creation time is happening from last text chunk and they are in sync.
Also PNGMetadata code is very well structured for decodeImageCreationTimeFromTextChunk() and encodeImageCreationTimeToTextChunk() code flow.

Changes are fine.

Thanks,
Jay
-----Original Message-----
From: Prahalad Kumar Narayanan
Sent: Thursday, July 20, 2017 7:57 PM
To: Brian Burkhalter; Jayathirth D V; [hidden email]
Subject: RE: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Hello Everyone

Good day to you.

This is a follow-up to the bug fix for
    [JDK-8164971]    PNG Metadata does not handle image creation time.

First, Thanks to Brian and Jay for their time in review & feedback.
    . I 've addressed the review suggestions and the updated code is available for review.
    . Webrev Link: http://cr.openjdk.java.net/~pnarayanan/8164971/webrev.01/

Description on changes are as follows:

Brian's Suggestions:
> Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123.
> What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"?
    . Update:
    . The logic supports decoding combined Date Time based on RFC1123 and ISO Formats.
    . This has been realized with JDK's inbuilt DateTimeFormatter objects.

> If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary.
> One could for example use the value of the first one, the value of the last one, the oldest one, etc.
    . Update:
    . The logic uses the time retrieved from the last decoded text chunk (tEXt, iTXt, or zTXt) with Creation Time to initialize Standard/Document/ImageCreationTime.
    . Similarly, when metadata is updated with Standard/Document/ImageCreationTime, the same is encoded within the last decoded text chunk.

> What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2]
    . Update:
    . I checked the PNG files of the test suite. Unfortunately none contain ancillary text chunk with 'Creation Time'
    . Hence, I manually created a PNG file with tEXt chunk containing Creation Time to test the changes.

Jay's Suggestions:
> In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123
    . Update:
    . This has been corrected.
    . Please Note: The method name in the internal PNGMetadata class has been changed to decodedImageCreationTimeFromTextChunk

> I see that, if there are multiple text chunks following RFC1123 text we update our standard metadata node with last parsed chunk. This information should be covered properly in comments as it is specific to our implementation and it is not part of PNG specification.
    . Update:
    . This has been addressed. The logic is substantiated with comments.

> In the present iteration of code in PNGMetadata.encodeCreationTimeToText() we are updating the first available text chunk with the new information provided in stanrdardmetadata node.
    . Update:
    . Yes. This is a very good find. Thank you.
    . The logic has been corrected to update the encoded time in the last decoded text chunk.

> It's better to maintain /* */ format for multiple line comments then using multiple //.
    . Update:
    . I had initially used // to keep my changes in synch with the existing code that uses // for multiline comments.
    . I 've reverted to /* */ to comply with guidelines.

Other Information:
    . The code changes have been run through Jtreg and JCK test suites. No new regressions were seen.
    . Besides, the test case available with the webrev is comprehensive and tests the following scenarios-
        . Proper decoding of text chunks with 'Creation Time' from the test image.
        . Proper decoding of time in RFC1123 and ISO format. (Test provides incorrect values as well and code doesn't crash)
        . Proper values in Native tree's text chunks after updating metadata with Standard/Document/ImageCreationTime.
        . Proper values in Standard/Document/ImageCreationTime after updating metadata with text chunks using Native tree.

Kindly review the changes when your time permits and provide your feedback.

Thank you
Have a good day

Prahalad N.

---------------------------------------
From: Brian Burkhalter
Sent: Thursday, June 08, 2017 4:20 AM
To: Jayathirth D V
Cc: Prahalad Kumar Narayanan; [hidden email]
Subject: Re: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Hi Jay,

On Jun 7, 2017, at 3:42 AM, Jayathirth D V <[hidden email]> wrote:


As per PNG Specification for text chunks http://libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.Anc-text . There can be multiple chunks with same keyword.

Yep: "Any number of text chunks can appear, and more than one with the same keyword is permissible."


1) In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123. So if there are multiple text chunks and if the latest chunk doesn't follow RFC1123 while decoding it will result in "creation_time_present" to be false. In case where we are not able to decode the provided text, we should not update "creation_time_present" to false.

I have not looked at the code but what I am wondering about is how it handles this part of the specification from the same section:

"For the Creation Time keyword, the date format defined in section 5.2.14 of RFC 1123 is suggested, but not required [RFC-1123]. Decoders should allow for free-format text associated with this or any other keyword."  

Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123. What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"?

If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary. One could for example use the value of the first one, the value of the last one, the oldest one, etc.

What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2] or those produced by typical user applications such as Apple's "Preview" or the Windows program "IrfanView" [3] or other common image viewers?

Thanks,

Brian

[1] https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations
[2] http://www.schaik.com/pngsuite/pngsuite.html
[3] https://en.wikipedia.org/wiki/IrfanView
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Philip Race
2038 //                  } else if (childName.equals("ImageCreationTime")) {
2039                     } else if (childName.equals("ImageCreationTime")) {
2038 can go
2278         // tIME chunk with Image modificaiton time

spelling mistake ..

other than that looks good to me.

-phil.

On 07/31/2017 10:23 PM, Jayathirth D V wrote:
Hello Prahalad,

The decoding and encoding of creation time is happening from last text chunk and they are in sync.
Also PNGMetadata code is very well structured for decodeImageCreationTimeFromTextChunk() and encodeImageCreationTimeToTextChunk() code flow.

Changes are fine.

Thanks,
Jay
-----Original Message-----
From: Prahalad Kumar Narayanan 
Sent: Thursday, July 20, 2017 7:57 PM
To: Brian Burkhalter; Jayathirth D V; [hidden email]
Subject: RE: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Hello Everyone

Good day to you.

This is a follow-up to the bug fix for
    [JDK-8164971]    PNG Metadata does not handle image creation time. 

First, Thanks to Brian and Jay for their time in review & feedback.
    . I 've addressed the review suggestions and the updated code is available for review.
    . Webrev Link: http://cr.openjdk.java.net/~pnarayanan/8164971/webrev.01/

Description on changes are as follows:

Brian's Suggestions:
Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123. 
What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"?
    . Update:
    . The logic supports decoding combined Date Time based on RFC1123 and ISO Formats.
    . This has been realized with JDK's inbuilt DateTimeFormatter objects.

If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary.
One could for example use the value of the first one, the value of the last one, the oldest one, etc.
    . Update:
    . The logic uses the time retrieved from the last decoded text chunk (tEXt, iTXt, or zTXt) with Creation Time to initialize Standard/Document/ImageCreationTime.
    . Similarly, when metadata is updated with Standard/Document/ImageCreationTime, the same is encoded within the last decoded text chunk.

What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2]
    . Update:
    . I checked the PNG files of the test suite. Unfortunately none contain ancillary text chunk with 'Creation Time'
    . Hence, I manually created a PNG file with tEXt chunk containing Creation Time to test the changes.

Jay's Suggestions:
In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123
    . Update:
    . This has been corrected. 
    . Please Note: The method name in the internal PNGMetadata class has been changed to decodedImageCreationTimeFromTextChunk

I see that, if there are multiple text chunks following RFC1123 text we update our standard metadata node with last parsed chunk. This information should be covered properly in comments as it is specific to our implementation and it is not part of PNG specification.
    . Update:
    . This has been addressed. The logic is substantiated with comments.

In the present iteration of code in PNGMetadata.encodeCreationTimeToText() we are updating the first available text chunk with the new information provided in stanrdardmetadata node. 
    . Update:
    . Yes. This is a very good find. Thank you.
    . The logic has been corrected to update the encoded time in the last decoded text chunk.

It's better to maintain /* */ format for multiple line comments then using multiple //.
    . Update:
    . I had initially used // to keep my changes in synch with the existing code that uses // for multiline comments.
    . I 've reverted to /* */ to comply with guidelines.

Other Information:
    . The code changes have been run through Jtreg and JCK test suites. No new regressions were seen.
    . Besides, the test case available with the webrev is comprehensive and tests the following scenarios-
        . Proper decoding of text chunks with 'Creation Time' from the test image.
        . Proper decoding of time in RFC1123 and ISO format. (Test provides incorrect values as well and code doesn't crash)
        . Proper values in Native tree's text chunks after updating metadata with Standard/Document/ImageCreationTime.
        . Proper values in Standard/Document/ImageCreationTime after updating metadata with text chunks using Native tree.

Kindly review the changes when your time permits and provide your feedback.

Thank you
Have a good day

Prahalad N.

---------------------------------------
From: Brian Burkhalter 
Sent: Thursday, June 08, 2017 4:20 AM
To: Jayathirth D V
Cc: Prahalad Kumar Narayanan; [hidden email]
Subject: Re: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Hi Jay,

On Jun 7, 2017, at 3:42 AM, Jayathirth D V [hidden email] wrote:


As per PNG Specification for text chunks http://libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.Anc-text . There can be multiple chunks with same keyword.

Yep: "Any number of text chunks can appear, and more than one with the same keyword is permissible."


1) In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123. So if there are multiple text chunks and if the latest chunk doesn't follow RFC1123 while decoding it will result in "creation_time_present" to be false. In case where we are not able to decode the provided text, we should not update "creation_time_present" to false.

I have not looked at the code but what I am wondering about is how it handles this part of the specification from the same section:

"For the Creation Time keyword, the date format defined in section 5.2.14 of RFC 1123 is suggested, but not required [RFC-1123]. Decoders should allow for free-format text associated with this or any other keyword."  

Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123. What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"?

If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary. One could for example use the value of the first one, the value of the last one, the oldest one, etc.

What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2] or those produced by typical user applications such as Apple's "Preview" or the Windows program "IrfanView" [3] or other common image viewers?

Thanks,

Brian

[1] https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations
[2] http://www.schaik.com/pngsuite/pngsuite.html
[3] https://en.wikipedia.org/wiki/IrfanView

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Prahalad kumar Narayanan
Hello Everyone

Thanks to Phil for his time in reviewing the fix.

I 've updated the code with suggested changes & modified code can be reviewed at
http://cr.openjdk.java.net/~pnarayanan/8164971/webrev.02/

Changes since previous revision are:
    . Comment statement at line: 2038 has been removed
    . Spelling mistake at line: 2278 has been corrected.

The changes are minimal but felt it would be good to raise the review.
Kindly provide your review feedback at your convenience.

Thank you for your time
Have a good day

Prahalad N.

-----Original Message-----
From: Phil Race
Sent: Saturday, August 12, 2017 2:38 AM
To: Jayathirth D V; Prahalad Kumar Narayanan
Cc: [hidden email]
Subject: Re: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

2038 //                  } else if (childName.equals("ImageCreationTime")) {
2039                     } else if (childName.equals("ImageCreationTime")) {
2038 can go
2278         // tIME chunk with Image modificaiton time

spelling mistake ..

other than that looks good to me.

-phil.

On 07/31/2017 10:23 PM, Jayathirth D V wrote:
Hello Prahalad,

The decoding and encoding of creation time is happening from last text chunk and they are in sync.
Also PNGMetadata code is very well structured for decodeImageCreationTimeFromTextChunk() and encodeImageCreationTimeToTextChunk() code flow.

Changes are fine.

Thanks,
Jay

-----Original Message-----
From: Prahalad Kumar Narayanan
Sent: Thursday, July 20, 2017 7:57 PM
To: Brian Burkhalter; Jayathirth D V; [hidden email]
Subject: RE: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Hello Everyone

Good day to you.

This is a follow-up to the bug fix for
    [JDK-8164971]    PNG Metadata does not handle image creation time.

First, Thanks to Brian and Jay for their time in review & feedback.
    . I 've addressed the review suggestions and the updated code is available for review.
    . Webrev Link: http://cr.openjdk.java.net/~pnarayanan/8164971/webrev.01/

Description on changes are as follows:

Brian's Suggestions:
Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123.
What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"?
    . Update:
    . The logic supports decoding combined Date Time based on RFC1123 and ISO Formats.
    . This has been realized with JDK's inbuilt DateTimeFormatter objects.

If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary.
One could for example use the value of the first one, the value of the last one, the oldest one, etc.
    . Update:
    . The logic uses the time retrieved from the last decoded text chunk (tEXt, iTXt, or zTXt) with Creation Time to initialize Standard/Document/ImageCreationTime.
    . Similarly, when metadata is updated with Standard/Document/ImageCreationTime, the same is encoded within the last decoded text chunk.

What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2]
    . Update:
    . I checked the PNG files of the test suite. Unfortunately none contain ancillary text chunk with 'Creation Time'
    . Hence, I manually created a PNG file with tEXt chunk containing Creation Time to test the changes.

Jay's Suggestions:
In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123
    . Update:
    . This has been corrected.
    . Please Note: The method name in the internal PNGMetadata class has been changed to decodedImageCreationTimeFromTextChunk

I see that, if there are multiple text chunks following RFC1123 text we update our standard metadata node with last parsed chunk. This information should be covered properly in comments as it is specific to our implementation and it is not part of PNG specification.
    . Update:
    . This has been addressed. The logic is substantiated with comments.

In the present iteration of code in PNGMetadata.encodeCreationTimeToText() we are updating the first available text chunk with the new information provided in stanrdardmetadata node.
    . Update:
    . Yes. This is a very good find. Thank you.
    . The logic has been corrected to update the encoded time in the last decoded text chunk.

It's better to maintain /* */ format for multiple line comments then using multiple //.
    . Update:
    . I had initially used // to keep my changes in synch with the existing code that uses // for multiline comments.
    . I 've reverted to /* */ to comply with guidelines.

Other Information:
    . The code changes have been run through Jtreg and JCK test suites. No new regressions were seen.
    . Besides, the test case available with the webrev is comprehensive and tests the following scenarios-
        . Proper decoding of text chunks with 'Creation Time' from the test image.
        . Proper decoding of time in RFC1123 and ISO format. (Test provides incorrect values as well and code doesn't crash)
        . Proper values in Native tree's text chunks after updating metadata with Standard/Document/ImageCreationTime.
        . Proper values in Standard/Document/ImageCreationTime after updating metadata with text chunks using Native tree.

Kindly review the changes when your time permits and provide your feedback.

Thank you
Have a good day

Prahalad N.

---------------------------------------
From: Brian Burkhalter
Sent: Thursday, June 08, 2017 4:20 AM
To: Jayathirth D V
Cc: Prahalad Kumar Narayanan; [hidden email]
Subject: Re: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Hi Jay,

On Jun 7, 2017, at 3:42 AM, Jayathirth D V <[hidden email]> wrote:


As per PNG Specification for text chunks http://libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.Anc-text . There can be multiple chunks with same keyword.

Yep: "Any number of text chunks can appear, and more than one with the same keyword is permissible."


1) In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123. So if there are multiple text chunks and if the latest chunk doesn't follow RFC1123 while decoding it will result in "creation_time_present" to be false. In case where we are not able to decode the provided text, we should not update "creation_time_present" to false.

I have not looked at the code but what I am wondering about is how it handles this part of the specification from the same section:

"For the Creation Time keyword, the date format defined in section 5.2.14 of RFC 1123 is suggested, but not required [RFC-1123]. Decoders should allow for free-format text associated with this or any other keyword."  

Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123. What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"?

If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary. One could for example use the value of the first one, the value of the last one, the oldest one, etc.

What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2] or those produced by typical user applications such as Apple's "Preview" or the Windows program "IrfanView" [3] or other common image viewers?

Thanks,

Brian

[1] https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations
[2] http://www.schaik.com/pngsuite/pngsuite.html
[3] https://en.wikipedia.org/wiki/IrfanView
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Philip Race
I am OK with this. It would be good if Brian could look at it too
to make sure it functions as he expects since he
was the original reporter and requestor here ..

-phil.

On 8/15/17, 2:57 AM, Prahalad Kumar Narayanan wrote:

> Hello Everyone
>
> Thanks to Phil for his time in reviewing the fix.
>
> I 've updated the code with suggested changes&  modified code can be reviewed at
> http://cr.openjdk.java.net/~pnarayanan/8164971/webrev.02/
>
> Changes since previous revision are:
>      . Comment statement at line: 2038 has been removed
>      . Spelling mistake at line: 2278 has been corrected.
>
> The changes are minimal but felt it would be good to raise the review.
> Kindly provide your review feedback at your convenience.
>
> Thank you for your time
> Have a good day
>
> Prahalad N.
>
> -----Original Message-----
> From: Phil Race
> Sent: Saturday, August 12, 2017 2:38 AM
> To: Jayathirth D V; Prahalad Kumar Narayanan
> Cc: [hidden email]
> Subject: Re: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime
>
> 2038 //                  } else if (childName.equals("ImageCreationTime")) {
> 2039                     } else if (childName.equals("ImageCreationTime")) {
> 2038 can go
> 2278         // tIME chunk with Image modificaiton time
>
> spelling mistake ..
>
> other than that looks good to me.
>
> -phil.
>
> On 07/31/2017 10:23 PM, Jayathirth D V wrote:
> Hello Prahalad,
>
> The decoding and encoding of creation time is happening from last text chunk and they are in sync.
> Also PNGMetadata code is very well structured for decodeImageCreationTimeFromTextChunk() and encodeImageCreationTimeToTextChunk() code flow.
>
> Changes are fine.
>
> Thanks,
> Jay
>
> -----Original Message-----
> From: Prahalad Kumar Narayanan
> Sent: Thursday, July 20, 2017 7:57 PM
> To: Brian Burkhalter; Jayathirth D V; [hidden email]
> Subject: RE: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime
>
> Hello Everyone
>
> Good day to you.
>
> This is a follow-up to the bug fix for
>      [JDK-8164971]    PNG Metadata does not handle image creation time.
>
> First, Thanks to Brian and Jay for their time in review&  feedback.
>      . I 've addressed the review suggestions and the updated code is available for review.
>      . Webrev Link: http://cr.openjdk.java.net/~pnarayanan/8164971/webrev.01/
>
> Description on changes are as follows:
>
> Brian's Suggestions:
> Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123.
> What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"?
>      . Update:
>      . The logic supports decoding combined Date Time based on RFC1123 and ISO Formats.
>      . This has been realized with JDK's inbuilt DateTimeFormatter objects.
>
> If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary.
> One could for example use the value of the first one, the value of the last one, the oldest one, etc.
>      . Update:
>      . The logic uses the time retrieved from the last decoded text chunk (tEXt, iTXt, or zTXt) with Creation Time to initialize Standard/Document/ImageCreationTime.
>      . Similarly, when metadata is updated with Standard/Document/ImageCreationTime, the same is encoded within the last decoded text chunk.
>
> What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2]
>      . Update:
>      . I checked the PNG files of the test suite. Unfortunately none contain ancillary text chunk with 'Creation Time'
>      . Hence, I manually created a PNG file with tEXt chunk containing Creation Time to test the changes.
>
> Jay's Suggestions:
> In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123
>      . Update:
>      . This has been corrected.
>      . Please Note: The method name in the internal PNGMetadata class has been changed to decodedImageCreationTimeFromTextChunk
>
> I see that, if there are multiple text chunks following RFC1123 text we update our standard metadata node with last parsed chunk. This information should be covered properly in comments as it is specific to our implementation and it is not part of PNG specification.
>      . Update:
>      . This has been addressed. The logic is substantiated with comments.
>
> In the present iteration of code in PNGMetadata.encodeCreationTimeToText() we are updating the first available text chunk with the new information provided in stanrdardmetadata node.
>      . Update:
>      . Yes. This is a very good find. Thank you.
>      . The logic has been corrected to update the encoded time in the last decoded text chunk.
>
> It's better to maintain /* */ format for multiple line comments then using multiple //.
>      . Update:
>      . I had initially used // to keep my changes in synch with the existing code that uses // for multiline comments.
>      . I 've reverted to /* */ to comply with guidelines.
>
> Other Information:
>      . The code changes have been run through Jtreg and JCK test suites. No new regressions were seen.
>      . Besides, the test case available with the webrev is comprehensive and tests the following scenarios-
>          . Proper decoding of text chunks with 'Creation Time' from the test image.
>          . Proper decoding of time in RFC1123 and ISO format. (Test provides incorrect values as well and code doesn't crash)
>          . Proper values in Native tree's text chunks after updating metadata with Standard/Document/ImageCreationTime.
>          . Proper values in Standard/Document/ImageCreationTime after updating metadata with text chunks using Native tree.
>
> Kindly review the changes when your time permits and provide your feedback.
>
> Thank you
> Have a good day
>
> Prahalad N.
>
> ---------------------------------------
> From: Brian Burkhalter
> Sent: Thursday, June 08, 2017 4:20 AM
> To: Jayathirth D V
> Cc: Prahalad Kumar Narayanan; [hidden email]
> Subject: Re: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime
>
> Hi Jay,
>
> On Jun 7, 2017, at 3:42 AM, Jayathirth D V<[hidden email]>  wrote:
>
>
> As per PNG Specification for text chunks http://libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.Anc-text . There can be multiple chunks with same keyword.
>
> Yep: "Any number of text chunks can appear, and more than one with the same keyword is permissible."
>
>
> 1) In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123. So if there are multiple text chunks and if the latest chunk doesn't follow RFC1123 while decoding it will result in "creation_time_present" to be false. In case where we are not able to decode the provided text, we should not update "creation_time_present" to false.
>
> I have not looked at the code but what I am wondering about is how it handles this part of the specification from the same section:
>
> "For the Creation Time keyword, the date format defined in section 5.2.14 of RFC 1123 is suggested, but not required [RFC-1123]. Decoders should allow for free-format text associated with this or any other keyword."  
>
> Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123. What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"?
>
> If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary. One could for example use the value of the first one, the value of the last one, the oldest one, etc.
>
> What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2] or those produced by typical user applications such as Apple's "Preview" or the Windows program "IrfanView" [3] or other common image viewers?
>
> Thanks,
>
> Brian
>
> [1] https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations
> [2] http://www.schaik.com/pngsuite/pngsuite.html
> [3] https://en.wikipedia.org/wiki/IrfanView
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime

Brian Burkhalter-2
In reply to this post by Prahalad kumar Narayanan
Hello Prahalad,

This review is with respect to [1]. Picky comments:

PNGImageReader:
479, 570, 667: Add space around the “-“ signs.
741, 752, 757 and in other files: In general, comments starting with “/*” should be blank after the “/*” with the actual verbiage starting on the next line.

What about the PNG ImageWriter? The description in the issue [2] implies that the the ImageCreationTime should be used to set the Creation Time in the text chunk(s). Or is this already happening?

Thanks,

Brian


On Jul 20, 2017, at 7:27 AM, Prahalad Kumar Narayanan <[hidden email]> wrote:

First, Thanks to Brian and Jay for their time in review & feedback.
   . I 've addressed the review suggestions and the updated code is available for review.
   . Webrev Link: http://cr.openjdk.java.net/~pnarayanan/8164971/webrev.01/

Loading...