I was hoping that beta6 would be the last 3.1.0 beta, but due to the
serious Restricted Access bug in beta5, it seems like we should put out
a replacement ASAP and fix the remaining problems in beta7.
By my count, we’ve had no fewer than 26 bug fixes in the past 11 days
since 3.1.0-beta5 was released, which I think is an outstanding effort
on our part. Once we finally do release 3.1.0, it should be the most
robust release we’ve had in a long time.
In the meantime, if you’re not already working on a bug, please Adopt a
Bug and find a fix for it.
There is one last thing I would like to squeeze into beta6.
The Drag and Drop bug is driving me absolutely batty. I have 2 theories at the moment:
An intermittent Java bug generating a spurious second DragGesture
A race condition where on a heavily loaded system, then end of a drag is not completely processed before the user tries a new drag.
I’d like to catch the InvalidDnDException and dump a bunch of debug info about the current and previous drags and then rethrow the exception. I’ll try it get it done today.
I’m worried about the design of the AbstractMetaData class. It seems
like whenever we add a new subclass, we have to make changes to it.
Shouldn’t those things be handled by polymorphism rather than by packing
cast structures into the parent class?
The buildMetaData() Factory method can’t really help it, but I’m happy to get rid of the enum (I thought you added that?) and the isXXXXXdata() methods (they are mine).
Have a look at swampwallaby-work@4526 ,it breaks out the factory, and removes the ENUM and the isXXXXdata() methods and replaces them with if (xxx instanceof xxxxMetaData). AbstractMetaData should be pure now.
Also, might be time to move all of the metadata classes to their own package?
I spent all night trying to figure out why yet more PNGs weren’t loading
properly after my transparency fix. My original fix was to have ImageIO
read the PNG metadata to see if the image was of the offending type, and
then hand it off to Toolkit if so. What I didn’t account for was that the
standard ImageIO reader doesn’t read the ancillary PNG chunks at all, and
if you force it to then PNGs with malformed ancillary chunks won’t load
anymore. As it happens, the PNGs in the Successors III module are screwed
up in this way, and so my previous fix makes many of them fail to load.
So, what I did was write a simple PNG decoder which goes hunting for the
IHDR and tRNS chunks to see if the PNG in question is the type we want
to use Toolkit to load. This way, we don’t force ImageIO to load the PNG
metadata, so it will happily load PNGs with malformed metadata again.
I did all the png’s in Successor III mod using Fireworks in the Adobe CS3
suite - maybe it is something Adobe does with their png files. Are you
saying that Adobe, one of the industry standard bearers for graphic programs
are taking a page from microshaft (ala the w3c trick) in not conforming to
standards where it comes to their graphic file formats?
You will need to merge 4509 first to make sense of 4526.
Also, swampwallaby-work@4529 has a fix for
Bug [2340311] Edit All pieces, no change, should not update pieces
and also fixes missing Cancel button and Close Window handling in components using ConfigurerWindow (Edit all contained, Dice Buttons, Random Text button).
ImageIO’s decoder is throwing an IIOException while reading a tEXt chunk,
yes. It might be an ImageIO bug. If it is, I’d like to know so that I can
file another ImageIO bug report.
public class Test {
public static void main(String args) throws Exception {
final FileImageInputStream in = new FileImageInputStream(new File(args[0]));
final ImageReader reader = ImageIO.getImageReaders(in).next();
reader.setInput(in);
final IIOMetadata md = reader.getImageMetadata(0);
}
}
If you run this on any of the City images, e.g., City-Miletus.png, you’ll
get an exception from PNGImageReader.parse_iTXt_chunk():
Exception in thread “main” javax.imageio.IIOException: Error reading PNG metadata
at com.sun.imageio.plugins.png.PNGImageReader.readMetadata(PNGImageReader.java:761)
at com.sun.imageio.plugins.png.PNGImageReader.getImageMetadata(PNGImageReader.java:1542)
at Test.main(Test.java:17)
Caused by: java.io.UTFDataFormatException: malformed input around byte 12737
at java.io.DataInputStream.readUTF(DataInputStream.java:634)
at javax.imageio.stream.ImageInputStreamImpl.readUTF(ImageInputStreamImpl.java:332)
at com.sun.imageio.plugins.png.PNGImageReader.parse_iTXt_chunk(PNGImageReader.java:469)
at com.sun.imageio.plugins.png.PNGImageReader.readMetadata(PNGImageReader.java:709)
… 2 more
The problem is that ImageInputStreamImpl is using DataInputStream.readUTF(),
which expects there to be two bytes at the head of the input stream
indicating the length of the UTF to decode. However, according to the PNG
standard, the UTF-8 text block in the iTXt chunk just starts without any
length information. Therefore, ImageIO will never correctly read an iTXt
chunk.
This tells me that this code was NEVER tested by anyone at Sun, because
it cannot possibly work correctly. GRRRRR!!! ARGH!!!
However, because of the way that JREs are released for MacOS, we’ll be
waiting for this bug to be fixed there pretty much forever, which means
that we’re stuck with the workaround code indefinitely.
I’ve picked this and Michael’s last ADC2 change up in trunk@4549, though it
was rather a rough merge so you and Michael should check that everything is
ok.
