I think this is fine, but I noticed that some of the recently added comments have some grammar issues. It might be nice
to change the following:
565 // markers which do not contain length data
(doesn't => do not)
576 // markers which contain length
Hi Jay,
When I write javadoc suggestions I sometimes use the short-hand "{some text}" to indicate that it should be formatted
using javadoc protocols, typically that expands to "{@code some text}", but sometimes a link may be appropriate. It
looks like you copied and pasted a number of places
Having said that, MacOS preview is perfectly happy with opening thumbimg.jpg and displaying a big green rectangle (is
that what the file is supposed to look like?), so we should probably successfully read the image. Have we tried to open
it with any other file utilities to see if it is
That doesn't appear to be happening in this case. If you take the APP0 marker lengths at face value, there are 3 APP0
markers. The first has a length that brings you to the second one. The second one has a length that takes you 2 bytes
short of the next. The intervening bytes are 00,00 which
What does the compClip end up being in that case?
...jim
On 7/4/16 1:12 AM, Sergey Bylokhov wrote:
On 01.07.16 2:49, Jim Graham wrote:
How is it returning true? If the clip really is empty, then
intersectsQuickCheck() should never return true. Or are you saying that
Hi,
Thanks for your input Phil.
I have made changes just to parse "FF FF"(Like "FF 00" or any marker without
length)and not consider it as an invalid marker in skipImage() of
JPEGImageReader.java.
Also I have removed closed/javax/imageio/ReadAllThumbnailsTest.java from
ProblemList.txt as
Hi Jay,
Looks fine to me.
Thanks,
Brian
On Jul 12, 2016, at 5:03 AM, Jayathirth D V wrote:
> That’s very good thing to do as it will remove redundant f.delete().
> I have updated the webrev for review :
> http://cr.openjdk.java.net/~jdv/7059970/webrev.02/