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.
Regards,
Oliver
Oliver Deakin wrote:
I've found that if I prepend the classpath with the M11 versions of
ZipEntry and ZipFile and run using the M11 hyarchive.dll both the
failing swing tests pass. If I run the post-r822846 version of those
classes, still on the M11 natives, then the tests fail again which
seems to indicate that the breaking change was in the commit to
ZipEntry.java or ZipFile.java.
Regards,
Oliver
Tim Ellison wrote:
On 26/Nov/2009 13:14, Mark Hindess wrote:
In message
<200911261245.naqcjwbj010...@d06av01.portsmouth.uk.ibm.com>, Mark
Hindess writes:
In message <4b0e6f23.8070...@googlemail.com>, Oliver Deakin writes:
I have updated this morning and I only see 1 consistent failure on
Windows x86 now:
Name
Tests Errors Failures
javax.swing.text.html.HTMLDocument_Reader_ActionsTest
58 1 1
The bad news is that running this test against the M11 build passes
for me, so it's something we have broken since the last milestone. I
have created HARMONY-6392 for these failures.
I see this on Linux too. I'm running a binary chop to try to narrow
down the breaking commit. It is currently testing r822219 which fails
between r820621 (which passes) and r823576 (which fails).
It has finished running now and shows the bad commit as:
r822846 | tellison | 2009-10-07 19:54:08 +0100 (Wed, 07 Oct 2009)
| 2 lines
Apply part of patch from HARMONY-6346 ([classlib] [archive]
Several archive bugfixes and optimizations)
Thanks Mark. It's not immediately clear how that is connected to the
failure, so running debug now.
The simple reproducer is:
public void test() throws IOException, BadLocationException {
StringReader sr = new StringReader("<html><body><pre>line1\n"
+ "<font color='red'>line2 \n line3</font>"
+ "line3</pre>line4 \n line4</body></html>");
HTMLDocument doc = new HTMLDocument();
new HTMLEditorKit().read(sr, doc, 0);
String range = doc.getText(26, 11);
assertEquals("line4 line4", range);
}
which passes on the RI, but on Harmony the range is returned as
"\nline4 line"
Regards,
Tim
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU