On 25/01/2010 16:59, Tim Ellison wrote:
On 25/Jan/2010 16:09, Oliver Deakin wrote:
Looks like this is caused by DTD.java's use of available() again. This
time the test is failing because RAFStream.available() is being called
by DTD.read() and its return value is expected to be a true indication
of the number of bytes available. However, the RAFStream.available()
call will only return 0 or 1 in our implementation which causes the
DTD.read() to only read a single byte rather than the whole DTD. I
hacked RAFStream.available() to return (mLength-mOffset) and this makes
the test pass, but twe really need to fix the DTD.read() method to not
use available() at all I think.
It looks like both need fixing then. I thought we had done all these
already?
RAFStream should return the actual number of bytes available, and
DTD.read() should not use available, but read until it gets EOF (-1).
Agreed. Perhaps something along the lines of the patch below. I have not
fully tested it yet, but this certainly fixes the test case in question.
Regards,
Oliver
Index: modules/archive/src/main/java/java/util/zip/ZipFile.java
===================================================================
--- modules/archive/src/main/java/java/util/zip/ZipFile.java
(revision 901661)
+++ modules/archive/src/main/java/java/util/zip/ZipFile.java (working
copy)
@@ -378,7 +378,15 @@
@Override
public int available() throws IOException {
- return (mOffset < mLength ? 1 : 0);
+ if (mOffset < mLength) {
+ if (mOffset - mLength < Integer.MAX_VALUE) {
+ return (int)(mLength-mOffset);
+ } else {
+ return Integer.MAX_VALUE;
+ }
+ } else {
+ return 0;
+ }
}
@Override
Index:
modules/swing/src/main/java/common/javax/swing/text/html/parser/DTD.java
===================================================================
---
modules/swing/src/main/java/common/javax/swing/text/html/parser/DTD.java
(revision 901661)
+++
modules/swing/src/main/java/common/javax/swing/text/html/parser/DTD.java
(working copy)
@@ -16,6 +16,7 @@
*/
package javax.swing.text.html.parser;
+import java.io.ByteArrayOutputStream;
import java.io.DataInputStream;
import java.io.IOException;
import java.util.BitSet;
@@ -142,9 +143,18 @@
public void read(final DataInputStream stream) throws IOException {
// converts from DataInputStream into a byte array
- byte[] enc = new byte[stream.available()];
- stream.read(enc);
+ byte[] enc = new byte[1024];
+ ByteArrayOutputStream bs = new ByteArrayOutputStream();
+ int iRead = 0;
+ while (iRead != -1) {
+ iRead = stream.read(enc, 0, enc.length);
+ if (iRead > 0) {
+ bs.write(enc, 0, iRead);
+ }
+ }
+ enc = bs.toByteArray();
+
// decode the byte array
Asn1Dtd asn1 = new Asn1Dtd(enc);
Regards,
Tim
On 25/01/2010 13:15, Oliver Deakin wrote:
Hi Ray,
Thanks for the information - from your results it seems that there
must be a difference in common classes between java 5 and 6 that are
causing the failures. I see the same result - with the java5 M12a
swing.jar the test passes 100% and with the java6 swing.jar it fails
100%.
I'll dig a little deeper at the code differences between the modules.
Regards,
Oliver
On 25/01/2010 12:10, Ray Chen wrote:
Hi Oliver,
I have done some investigation for this issue before, and disscussed
it on the 6.0 Milestone1 thread.
I compared two swing.jar of trunk and java6, the only difference
between them is that java6 added some new classes:
javax\swing\event\RowSorterEvent$Type.class
javax\swing\event\RowSorterEvent.class
javax\swing\event\RowSorterListener.class
javax\swing\filechooser\FileNameExtensionFilter.class
javax\swing\RowSorter$SortKey.class
javax\swing\RowSorter.class
javax\swing\SortOrder.class
I think these classes are not related to this test. However, even
after I removed these new added classes or replaced trunk's swing.jar
with java6's swing.jar and run the test on the modified trunk , the
test still failed.
And trunk's swing.jar works well in both trunk and java6 to run this
test.
So I am a little confused, same classes, same vm, why different result?
On Mon, Jan 25, 2010 at 7:03 PM, Oliver Deakin
(JIRA)<j...@apache.org> wrote:
[
https://issues.apache.org/jira/browse/HARMONY-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804502#action_12804502
]
Oliver Deakin commented on HARMONY-6392:
----------------------------------------
This issue has been fixed in java5 M12, but still persists in the
java6 branch.
[classlib][swing] Test failures in
javax.swing.text.html.HTMLDocument_Reader_ActionsTest
----------------------------------------------------------------------------------------
Key: HARMONY-6392
URL:
https://issues.apache.org/jira/browse/HARMONY-6392
Project: Harmony
Issue Type: Bug
Components: Classlib
Affects Versions: 6.0M1, 5.0M12
Environment: Windows x86
Reporter: Oliver Deakin
Fix For: 5.0M12
I see 1 failure and 1 error.
javax.swing.text.html.HTMLDocument_Reader_ActionsTest.testHarmony_4582
fails with output:
N/A
java.lang.NullPointerException
at
javax.swing.text.html.HTMLDocument_Reader_ActionsTest.testHarmony_4582(HTMLDocument_Reader_ActionsTest.java:584)
at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
at
javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:116)
at
javax.swing.BasicSwingTestCase.runBareImpl(BasicSwingTestCase.java:121)
at javax.swing.BasicSwingTestCase$1.run(BasicSwingTestCase.java:135)
at java.lang.Thread.run(Thread.java:669)
javax.swing.text.html.HTMLDocument_Reader_ActionsTest.testHarmony_4615
fails with output:
null expected:<[line4 line4]> but was:<[ line4 line]>
junit.framework.ComparisonFailure: null expected:<[line4 line4]>
but was:<[line4 line]>
at
javax.swing.text.html.HTMLDocument_Reader_ActionsTest.testHarmony_4615(HTMLDocument_Reader_ActionsTest.java:601)
at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
at
javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:116)
at
javax.swing.BasicSwingTestCase.runBareImpl(BasicSwingTestCase.java:121)
at javax.swing.BasicSwingTestCase$1.run(BasicSwingTestCase.java:135)
at java.lang.Thread.run(Thread.java:669)
These tests pass for me against M11.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
--
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
