On 26/Nov/2009 17:00, Oliver Deakin wrote:
> A little more progress.
> It looks like we're reading javax\swing\text\html\parser\html32.bdtd
> (which is where the ZipFile/ZipEntry classes come in). I see that with
> the M12 version of those classes we end up throwing an ASN1Exception at
> line 886 of BerInputStream.java (right at the start of it's read()
> method). This unravels the stack up to ParserDelegator.createDTD() which
> has a "try ... catch(Exception e) { // do nothing }" around the DTD
> read. The exception is ignored and we carry on, but the DTD has not been
> fully populated and it looks like this is the cause of the html not
> being processed correctly and the tests failing. Needless to say, this
> exception is not thrown with the M11 version of ZipFile/ZipEntry.
>
> The question now is why offset==buffer.length at the start of the
> BerInputStream.read() call with the new ZipFile/ZipEntry classes. Ill
> keep digging.
I'll bet you a beer that it is our friend available() again...
Consider this:
static final String NAME = "javax/swing/text/html/parser/html32.bdtd";
public void test() throws IOException {
JarFile jar = new JarFile("swing.jar");
ZipEntry ze = jar.getEntry(NAME);
InputStream is = jar.getInputStream(ze);
System.out.println("Size = " + ze.getSize());
System.out.println("Available = " + is.available());
jar.close();
}
On Harmony it prints:
Size = 51140
Available = 1
On the RI it prints:
Size = 51140
Available = 51140
I know the arguments that say available() should not be used to judge
the total number of bytes that can be read, but it seems that a number
of applications (including our generated parser?) use it in this way.
I haven't tried changing it yet[1], but I'll take that bet if you want :-)
Regards,
Tim
[1] I'm supposed to be packing for a long weekend away, so I'll be quiet
for the next few days.
