[jira] Created: (HARMONY-173) java.nio.charset.CharsetEncoder.encode method does not reserve remaining bytes for next invocation.
java.nio.charset.CharsetEncoder.encode method does not reserve remaining bytes for next invocation. --- Key: HARMONY-173 URL: http://issues.apache.org/jira/browse/HARMONY-173 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Method public final CoderResult encode(CharBuffer in, ByteBuffer out, boolean endOfInput) Considering that there is a supplemental character which represents by 4 bytes like \ud800\udc00, and it was divided into two input buffers. e.g. \ud800 is at the end of input1 and the \udc00 is at the begining of input2. when invoking the method encode(input1,out,false), it deals with \ud800 as a malformed charactor and I think it should be reversed for next invocation like encode(input2,out,true). And it aslo must be handled correspondingly in method public final ByteBuffer encode(CharBuffer in). ===Test segment to reproduce the bug (fail on RI 5.0 and Harmony. I think it's also a bug for RI 5.0) CharsetEncoder encoder = Charset.forName(utf-8).newEncoder(); CharBuffer in1 = CharBuffer.wrap(\ud800); CharBuffer in2 = CharBuffer.wrap(\udc00); ByteBuffer out = ByteBuffer.allocate(4); encoder.reset(); CoderResult result = encoder.encode(in1, out, false); assertEquals(4, out.remaining()); assertTrue(result.isUnderflow()); result = encoder.encode(in2, out, true); assertEquals(0, out.remaining()); assertTrue(result.isUnderflow()); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-182) java.nio.charset.Charset.encode(in) doesn't use the same cached encoder.
java.nio.charset.Charset.encode(in) doesn't use the same cached encoder.
Key: HARMONY-182
URL: http://issues.apache.org/jira/browse/HARMONY-182
Project: Harmony
Type: Bug
Reporter: Richard Liang
As spec says, An invocation of this method upon a charset cs returns the same
result as the expression cs.newEncoder()
.onMalformedInput(CodingErrorAction.REPLACE)
.onUnmappableCharacter(CodingErrorAction.REPLACE) .decode(bb); except that it
is potentially more efficient because it can cache encoders between successive
invocations.
RI always uses the same cached encoder (the same reference) for the charsets
with same name.
The following test case pass on RI 5.0, but fail on Harmony.
/*
* test cached encoder
*/
public void testCachedEncoder() throws Exception {
MockCachedCharset cs1 = new MockCachedCharset(CachedCharset,
null);
MockCachedCharset cs2 = new MockCachedCharset(CachedCharset,
null);
CharBuffer in = CharBuffer.wrap(A);
cs1.encode(in);
in.flip();
cs2.encode(in);
}
/*
* Mock Charset for cached encoder test
*/
static class MockCachedCharset extends Charset {
public MockCachedCharset(String canonicalName, String[]
aliases) {
super(canonicalName, aliases);
}
public boolean contains(Charset charset) {
return false;
}
public CharsetDecoder newDecoder() {
return new MockCachedDecoder(this);
}
public CharsetEncoder newEncoder() {
return new MockCachedEncoder(this);
}
}
/*
* Mock encoder. Only one caller is permitted.
*/
static class MockCachedEncoder extends CharsetEncoder {
static MockCachedEncoder caller = null;
public MockCachedEncoder(Charset cs) {
super(cs, 1, 10);
}
/*
* Only one caller is permitted.
*/
protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out)
{
if (null == caller) {
caller = this;
} else {
if (caller != this) {
// Another instance
fail(should use same instance);
}
}
return CoderResult.UNDERFLOW;
}
}
/*
* Mock decoder.
*/
static class MockCachedDecoder extends CharsetDecoder {
static MockCachedEncoder caller = null;
public MockCachedDecoder(Charset cs) {
super(cs, 1, 10);
}
protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out)
{
in.position(in.limit());
return CoderResult.UNDERFLOW;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-92) Suggestion: Move com.ibm.platform from NIO to LUNI
[ http://issues.apache.org/jira/browse/HARMONY-92?page=comments#action_12369166 ] Richard Liang commented on HARMONY-92: -- Hello Mark, I think your patch is what I can though I just re-play your patch manually because I have no permission to check-in :-) Thanks a lot. Suggestion: Move com.ibm.platform from NIO to LUNI -- Key: HARMONY-92 URL: http://issues.apache.org/jira/browse/HARMONY-92 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Attachments: 06.remove-obsolete.sh, new.refactor.tar.gz, refactor_platform.zip Hello Tim, As we discussed in JIRA 27 and JIRA 42, I suggest we move the packages com.ibm.platform and com.ibm.platform.struct from NIO to LUNI component. As these packages are used by java.net, as well as java.nio.channels. I will post the proposed fix soon :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-170) java.nio.charset.CharsetEncoder.encode method does not handle the unexpected exception
java.nio.charset.CharsetEncoder.encode method does not handle the unexpected exception -- Key: HARMONY-170 URL: http://issues.apache.org/jira/browse/HARMONY-170 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang public final CoderResult encode(CharBuffer in, ByteBuffer out, boolean endOfInput) As spec says, the method throws CoderMalfunctionError if an invocation of the decodeLoop method threw an unexpected exception. However, Harmony doesn't throws CoderMalfunctionError when decodeLoop method threw an unexpected exception. The attached test cases pass on RI , but fail on Harmony. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-170) java.nio.charset.CharsetEncoder.encode method does not handle the unexpected exception
[ http://issues.apache.org/jira/browse/HARMONY-170?page=all ] Richard Liang updated HARMONY-170: -- Attachment: CharsetEncoder_patch.txt CharsetEncoderTest_patch.txt Hello Tim, Please try my patch and the proposed test cases. Thanks a lot. java.nio.charset.CharsetEncoder.encode method does not handle the unexpected exception -- Key: HARMONY-170 URL: http://issues.apache.org/jira/browse/HARMONY-170 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Attachments: CharsetEncoderTest_patch.txt, CharsetEncoder_patch.txt public final CoderResult encode(CharBuffer in, ByteBuffer out, boolean endOfInput) As spec says, the method throws CoderMalfunctionError if an invocation of the decodeLoop method threw an unexpected exception. However, Harmony doesn't throws CoderMalfunctionError when decodeLoop method threw an unexpected exception. The attached test cases pass on RI , but fail on Harmony. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments
[ http://issues.apache.org/jira/browse/HARMONY-141?page=comments#action_12368684 ] Richard Liang commented on HARMONY-141: --- Tim, The fix is good. Please close this issue. Thanks a lot. Constructors of java.nio.charset.CharsetEncoder do not validate arguments - Key: HARMONY-141 URL: http://issues.apache.org/jira/browse/HARMONY-141 Project: Harmony Type: Bug Reporter: Richard Liang Assignee: Tim Ellison Attachments: CharsetEncoder_patch.txt Constructors of java.nio.charset.CharsetEncoder should throw IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-142) java.nio.charset.CharsetDecoder constructor doesn't throw IllegalArgumentException when averageCharsPerByte is greater than maxCharsPerByte.
[ http://issues.apache.org/jira/browse/HARMONY-142?page=comments#action_12368691 ] Richard Liang commented on HARMONY-142: --- Thanks a lot. The fix looks good. java.nio.charset.CharsetDecoder constructor doesn't throw IllegalArgumentException when averageCharsPerByte is greater than maxCharsPerByte. Key: HARMONY-142 URL: http://issues.apache.org/jira/browse/HARMONY-142 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Attachments: CharsetDecoder_patch.txt As spec says, constructor throws IllegalArgumentException when parameters are illegal. It should be considered as illegal parameters when averageCharsPerByte is greater than maxCharsPerByte. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-148) java.nio.charset.CharsetDecoder: decode(in,out,endOfInput) method doesn't preserve replace string for successive decode invocation while out doesn't have engouh space f
[ http://issues.apache.org/jira/browse/HARMONY-148?page=all ]
Richard Liang updated HARMONY-148:
--
Attachment: CharsetDecoder_patch_148.txt
This patch fixes bug Harmony 148. Would you please have a try ?
The patch could be simply applied by clicking team-apply patch
Thank you very much!
java.nio.charset.CharsetDecoder: decode(in,out,endOfInput) method doesn't
preserve replace string for successive decode invocation while out doesn't
have engouh space for replace string.
Key: HARMONY-148
URL: http://issues.apache.org/jira/browse/HARMONY-148
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Priority: Minor
Attachments: CharsetDecoder_patch_148.txt
Consider following senario:
During the invocation of method
java.nio.charset.CharsetDecoder.decode(in,out,false), method decodeLoop
returns malformed CoderResult, and the action is set as
CodingErrorAction.REPLACE. So replace action should be taken, but out
doesn't hold enough space for the replace string. Therefore,
CoderResult.OVERFLOW should be returned. Harmony does return OVERFLOW
currently, but the replace string won't put into new allocated output any
more. In other words, the replace string is missing from the view of stream
decoding. Therefore, replace string should be preserved for successive
decode(in,out,endOfInput) invacation.
Both RI5.0 and Harmony fails on the following test case. However, according
to the spec, we think it is a defect of RI5.0.
== Test Case==
/*
* Test the method decode(ByteBuffer) .
*/
public void testDecode_ReplaceOverflow() throws Exception {
String replaceString = a;
Charset cs = Charset.forName(UTF-8);
MockMalformedDecoder decoder = new MockMalformedDecoder(cs);
decoder.onMalformedInput(CodingErrorAction.REPLACE);
decoder.replaceWith(replaceString);
CharBuffer out = CharBuffer.allocate(1);
// MockMalformedDecoder treats the second byte '0x38' as
malformed,
// but out doesn't have enough space for replace string.
ByteBuffer in = ByteBuffer.wrap(new
byte[]{0x45,0x38,0x45,0x45});
CoderResult result = decoder.decode(in,out,false);
assertTrue(result.isOverflow());
// allocate enough space for out
out = CharBuffer.allocate(10);
// replace string should be put into out firstly,
// and then decode in.
result =decoder.decode(in,out,true);
out.flip();
assertTrue(result.isUnderflow());
assertEquals(abb,out.toString());
}
/*
* Mock decoder. It treats byte whose value is less than 0x40 as
malformed.
*/
static class MockMalformedDecoder extends
java.nio.charset.CharsetDecoder {
public MockMalformedDecoder(Charset cs) {
super(cs, 1, 10);
}
/*
* It treats byte whose value is less than 0x40 as malformed.
* Otherwise, it's decoded as 'b'.
*/
protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out)
{
System.out.println(Using MockMalformedDecoder);
while (in.hasRemaining()) {
byte b = in.get();
if(b 0x40){
return
CoderResult.malformedForLength(1);
}
if(!out.hasRemaining()){
return CoderResult.OVERFLOW;
}
out.put((char)'b');
}
return CoderResult.UNDERFLOW;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-149) java.nio.charset.Charset.forName(name) return different reference value when requiring the same Charset.
[ http://issues.apache.org/jira/browse/HARMONY-149?page=all ]
Richard Liang updated HARMONY-149:
--
Attachment: Charset_patch_149.txt
Would you please have a try and apply the patch on Charset.java ? Thanks a lot!
To apply patch, simply click Team-Apply patch
java.nio.charset.Charset.forName(name) return different reference value when
requiring the same Charset.
Key: HARMONY-149
URL: http://issues.apache.org/jira/browse/HARMONY-149
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Attachments: Charset_patch_149.txt
java.nio.charset.Charset.forName(name) returns different reference value when
requiring the same Charset.
However, RI always returns the same reference for the same Charset, no matter
using alias or canonical name as parameter.
RI 5.0 passes the following test case, while Harmony fails.
=== Test case
/*
* test forName: invoke forName two times with the same canonical name,
* it should return the same reference.
*/
public void testForName_TwoSameRef1(){
Charset cs1 = Charset.forName(UTF-8);
Charset cs2 = Charset.forName(UTF-8);
assertSame(cs1,cs2);
}
/*
* test forName: invoke forName two times for the same Charset using
canonical name and alias,
* it should return the same reference.
*/
public void testForName_TwoSameRef2(){
Charset cs1 = Charset.forName(ASCII);
Charset cs2 = Charset.forName(US-ASCII);
assertSame(cs1,cs2);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-148) java.nio.charset.CharsetDecoder: decode(in,out,endOfInput) method doesn't preserve replace string for successive decode invocation while out doesn't have engouh space f
java.nio.charset.CharsetDecoder: decode(in,out,endOfInput) method doesn't
preserve replace string for successive decode invocation while out doesn't
have engouh space for replace string.
Key: HARMONY-148
URL: http://issues.apache.org/jira/browse/HARMONY-148
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Priority: Minor
Consider following senario:
During the invocation of method
java.nio.charset.CharsetDecoder.decode(in,out,false), method decodeLoop
returns malformed CoderResult, and the action is set as
CodingErrorAction.REPLACE. So replace action should be taken, but out
doesn't hold enough space for the replace string. Therefore,
CoderResult.OVERFLOW should be returned. Harmony does return OVERFLOW
currently, but the replace string won't put into new allocated output any more.
In other words, the replace string is missing from the view of stream
decoding. Therefore, replace string should be preserved for successive
decode(in,out,endOfInput) invacation.
Both RI5.0 and Harmony fails on the following test case. However, according to
the spec, we think it is a defect of RI5.0.
== Test Case==
/*
* Test the method decode(ByteBuffer) .
*/
public void testDecode_ReplaceOverflow() throws Exception {
String replaceString = a;
Charset cs = Charset.forName(UTF-8);
MockMalformedDecoder decoder = new MockMalformedDecoder(cs);
decoder.onMalformedInput(CodingErrorAction.REPLACE);
decoder.replaceWith(replaceString);
CharBuffer out = CharBuffer.allocate(1);
// MockMalformedDecoder treats the second byte '0x38' as
malformed,
// but out doesn't have enough space for replace string.
ByteBuffer in = ByteBuffer.wrap(new
byte[]{0x45,0x38,0x45,0x45});
CoderResult result = decoder.decode(in,out,false);
assertTrue(result.isOverflow());
// allocate enough space for out
out = CharBuffer.allocate(10);
// replace string should be put into out firstly,
// and then decode in.
result =decoder.decode(in,out,true);
out.flip();
assertTrue(result.isUnderflow());
assertEquals(abb,out.toString());
}
/*
* Mock decoder. It treats byte whose value is less than 0x40 as
malformed.
*/
static class MockMalformedDecoder extends
java.nio.charset.CharsetDecoder {
public MockMalformedDecoder(Charset cs) {
super(cs, 1, 10);
}
/*
* It treats byte whose value is less than 0x40 as malformed.
* Otherwise, it's decoded as 'b'.
*/
protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out)
{
System.out.println(Using MockMalformedDecoder);
while (in.hasRemaining()) {
byte b = in.get();
if(b 0x40){
return
CoderResult.malformedForLength(1);
}
if(!out.hasRemaining()){
return CoderResult.OVERFLOW;
}
out.put((char)'b');
}
return CoderResult.UNDERFLOW;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-142) java.nio.charset.CharsetDecoder constructor doesn't throw IllegalArgumentException when averageCharsPerByte is greater than maxCharsPerByte.
[ http://issues.apache.org/jira/browse/HARMONY-142?page=all ] Richard Liang updated HARMONY-142: -- Attachment: CharsetDecoder_patch.txt Please try my patch. Thanks a lot! java.nio.charset.CharsetDecoder constructor doesn't throw IllegalArgumentException when averageCharsPerByte is greater than maxCharsPerByte. Key: HARMONY-142 URL: http://issues.apache.org/jira/browse/HARMONY-142 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Attachments: CharsetDecoder_patch.txt As spec says, constructor throws IllegalArgumentException when parameters are illegal. It should be considered as illegal parameters when averageCharsPerByte is greater than maxCharsPerByte. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-149) java.nio.charset.Charset.forName(name) return different reference value when requiring the same Charset.
java.nio.charset.Charset.forName(name) return different reference value when
requiring the same Charset.
Key: HARMONY-149
URL: http://issues.apache.org/jira/browse/HARMONY-149
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
java.nio.charset.Charset.forName(name) returns different reference value when
requiring the same Charset.
However, RI always returns the same reference for the same Charset, no matter
using alias or canonical name as parameter.
RI 5.0 passes the following test case, while Harmony fails.
=== Test case
/*
* test forName: invoke forName two times with the same canonical name,
* it should return the same reference.
*/
public void testForName_TwoSameRef1(){
Charset cs1 = Charset.forName(UTF-8);
Charset cs2 = Charset.forName(UTF-8);
assertSame(cs1,cs2);
}
/*
* test forName: invoke forName two times for the same Charset using
canonical name and alias,
* it should return the same reference.
*/
public void testForName_TwoSameRef2(){
Charset cs1 = Charset.forName(ASCII);
Charset cs2 = Charset.forName(US-ASCII);
assertSame(cs1,cs2);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-137) CharsetDecoder should replace undefined bytes with replacement string
[
http://issues.apache.org/jira/browse/HARMONY-137?page=comments#action_12368087
]
Richard Liang commented on HARMONY-137:
---
Please see the bug info in ICU bug system:
http://bugs.icu-project.org/cgi-bin/icu-bugs?findid=5085go=Go
And attached here is ICU team's response to this bug:
You are expecting incorrect behavior from cp1250. Both Microsoft's conversion
APIs and IBM mapping tables convert byte 81 to Unicode character 0081. This
conversion behavior will not change. The tables on unicode.org may tell you
about the official mappings, but there are other mappings that are commonly
expected.
More details about ICU charset conversion can be found on this page:
http://icu.sourceforge.net/charts/charset/
This charset conversion works as expected.
CharsetDecoder should replace undefined bytes with replacement string
-
Key: HARMONY-137
URL: http://issues.apache.org/jira/browse/HARMONY-137
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Priority: Minor
Corresponding to cp1250 mapping table, 0x81 byte is undefined. See
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1250.TXT
So, charset decoder should replace undefined bytes with default replacement,
i.e. 0xFFFD.
Testcase for reproducing this issue:
import java.nio.charset.*;
import java.nio.*;
public class Harmony137 {
public static void main(String[] args) throws Exception {
ByteBuffer bb = ByteBuffer.allocate(5);
bb.put((byte)0x81); bb.flip();
Charset cp1250 = Charset.forName(cp1250);
CharBuffer cb =
cp1250.newDecoder().onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE).decode(bb);
if(cb.get(0)!=65533) {
System.out.println(FAIL: expected 0xFFFD but result is:
0x+Integer.toHexString(cb.get(0)).toUpperCase());
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments
Constructors of java.nio.charset.CharsetEncoder do not validate arguments - Key: HARMONY-141 URL: http://issues.apache.org/jira/browse/HARMONY-141 Project: Harmony Type: Bug Reporter: Richard Liang Constructors of java.nio.charset.CharsetEncoder should throw IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments
[
http://issues.apache.org/jira/browse/HARMONY-141?page=comments#action_12368097
]
Richard Liang commented on HARMONY-141:
---
Here are the test cases which will pass on RI but fail on Harmony.
public void testConstructorIlegalAverageBytesPerChar() {
try {
Charset cs = Charset.forName(UTF-8); //$NON-NLS-1$
CharsetEncoder encoder = new MockCharsetEncoderForHarmony141(cs,
1.1f, 1);
fail(Should throw IllegalArgumentException.); //$NON-NLS-1$
} catch (IllegalArgumentException e) {
// expected
}
}
public void testConstructorIlegalAverageBytesPerChar2() {
try {
Charset cs = Charset.forName(ISO8859-1); //$NON-NLS-1$
CharsetEncoder encoder = new MockCharsetEncoderForHarmony141(cs,
1.1f, 1,
new byte[] { 0x1a});
fail(Should throw IllegalArgumentException.); //$NON-NLS-1$
} catch (IllegalArgumentException e) {
// expected
}
}
public static class MockCharsetEncoderForHarmony141 extends CharsetEncoder {
protected MockCharsetEncoderForHarmony141(Charset cs, float
averageBytesPerChar,
float maxBytesPerChar) {
super(cs, averageBytesPerChar, maxBytesPerChar);
}
public MockCharsetEncoderForHarmony141(Charset cs, float
averageBytesPerChar,
float maxBytesPerChar, byte[] replacement) {
super(cs, averageBytesPerChar, maxBytesPerChar, replacement);
}
protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out) {
return null;
}
}
Constructors of java.nio.charset.CharsetEncoder do not validate arguments
-
Key: HARMONY-141
URL: http://issues.apache.org/jira/browse/HARMONY-141
Project: Harmony
Type: Bug
Reporter: Richard Liang
Constructors of java.nio.charset.CharsetEncoder should throw
IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments
[ http://issues.apache.org/jira/browse/HARMONY-141?page=all ] Richard Liang updated HARMONY-141: -- Attachment: CharsetEncoder_patch.txt Please try my patch. Thanks a lot. :-) Constructors of java.nio.charset.CharsetEncoder do not validate arguments - Key: HARMONY-141 URL: http://issues.apache.org/jira/browse/HARMONY-141 Project: Harmony Type: Bug Reporter: Richard Liang Attachments: CharsetEncoder_patch.txt Constructors of java.nio.charset.CharsetEncoder should throw IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-136) Cannot make libvmi.so and libhytext.so on linux
[ http://issues.apache.org/jira/browse/HARMONY-136?page=comments#action_12368099 ] Richard Liang commented on HARMONY-136: --- Thanks Tim. The fix looks good. Please close this issue. Cannot make libvmi.so and libhytext.so on linux --- Key: HARMONY-136 URL: http://issues.apache.org/jira/browse/HARMONY-136 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Attachments: readme_patch.txt Hello, When trying to build Harmony native code on my redhat linux (RHEL 3), I fail to make the libvmi.so. But after I convert the makefile(revision=379478) to unix format using dos2unix, the make is successful. The same problem occurs in module text. in /native-src/linux.IA32/vmi/ issue command: make output: cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -I../include-c -o vmi_copyright.o vmi_copyright.c cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -I../include-c -o vmi.o vmi.c cc -shared -Wl,-Map=vmi.map \ -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ -L. -L../lib -L.. -o ../libvmi.so \ vmi_copyright.o vmi.o -Xlinker --start-group \ : No such file or directory make: *** [../libvmi.so] Error 1 issue command: dos2unix makefile issue command: make output: cc -shared -Wl,-Map=vmi.map \ -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ -L. -L../lib -L.. -o ../libvmi.so \ vmi_copyright.o vmi.o -Xlinker --start-group \ -lhyzip \ -lhypool -Xlinker --end-group -lc -lm -ldl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-124) java.nio.charset.CharsetDecoder doesn't throw CoderMalfunctionError exception when decodeLoop threw unexpected exception.
[
http://issues.apache.org/jira/browse/HARMONY-124?page=comments#action_12368195
]
Richard Liang commented on HARMONY-124:
---
Yes, Tim. The fix looks good. Please close this issue.
Thanks a lot.
java.nio.charset.CharsetDecoder doesn't throw CoderMalfunctionError exception
when decodeLoop threw unexpected exception.
-
Key: HARMONY-124
URL: http://issues.apache.org/jira/browse/HARMONY-124
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Attachments: CharsetDecoder_patch.txt, Charset_patch.txt
public final CoderResult decode(ByteBuffer in, CharBuffer out, boolean
endOfInput)
As spec says, the method throws CoderMalfunctionError if an invocation of the
decodeLoop method threw an unexpected exception.
However, Harmony doesn't throws CoderMalfunctionError when decodeLoop method
threw an unexpected exception.
The following test cases pass on RI , but fail on Harmony.
/*
* Test malfunction decode(ByteBuffer)
*/
public void testDecode_CoderMalfunctionError() throws Exception {
MockMalfunctionCharset cs = new MockMalfunctionCharset(mock,
null);
try{
cs.newDecoder().onMalformedInput(CodingErrorAction.REPLACE)
.onUnmappableCharacter(CodingErrorAction.REPLACE).decode(ByteBuffer.wrap(new
byte[]{0x00,0x11}));
fail(should throw CoderMalfunctionError);//NON-NLS-1$
}catch(CoderMalfunctionError e){
//expected
}
}
/*
* Test malfunction decode(ByteBuffer)
*/
public void testDecode_NoCoderMalfunctionError() throws Exception {
MockMalfunctionCharset cs = new MockMalfunctionCharset(mock,
null);
try{
cs.decode(ByteBuffer.wrap(new byte[]{0x00,0x11}));
}catch(CoderMalfunctionError e){
fail(Charset.decode should return
silently);//NON-NLS-1
}
}
/*
* Mock charset class with malfunction decode encode.
*/
static final class MockMalfunctionCharset extends Charset {
public MockMalfunctionCharset(String canonicalName, String[]
aliases) {
super(canonicalName, aliases);
}
public boolean contains(Charset cs) {
return false;
}
public CharsetDecoder newDecoder() {
return new MockMalfunctionDecoder(this);
}
public CharsetEncoder newEncoder() {
return new MockMalfunctionEncoder(this);
}
}
/*
* Mock decoder. decodeLoop always throws unexpected exception.
*/
static class MockMalfunctionDecoder extends
java.nio.charset.CharsetDecoder {
public MockMalfunctionDecoder(Charset cs) {
super(cs, 1, 10);
}
protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out)
{
throw new BufferOverflowException();
}
}
/*
* Mock encoder. encodeLoop always throws unexpected exception.
*/
static class MockMalfunctionEncoder extends
java.nio.charset.CharsetEncoder {
public MockMalfunctionEncoder(Charset cs) {
super(cs, 1, 3, new byte[] { (byte) '?' });
}
protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out)
{
throw new BufferOverflowException();
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments
[ http://issues.apache.org/jira/browse/HARMONY-141?page=comments#action_12368197 ] Richard Liang commented on HARMONY-141: --- Again I forget something: The test cases pass on RI 5.0 and fail on Harmony and RI 1.4.2. This may be an improvement of RI 5.0 :-) Constructors of java.nio.charset.CharsetEncoder do not validate arguments - Key: HARMONY-141 URL: http://issues.apache.org/jira/browse/HARMONY-141 Project: Harmony Type: Bug Reporter: Richard Liang Attachments: CharsetEncoder_patch.txt Constructors of java.nio.charset.CharsetEncoder should throw IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-142) java.nio.charset.CharsetDecoder constructor doesn't throw IllegalArgumentException when averageCharsPerByte is greater than maxCharsPerByte.
[
http://issues.apache.org/jira/browse/HARMONY-142?page=comments#action_12368204
]
Richard Liang commented on HARMONY-142:
---
Here is the testcases which pass on RI 5.0 and fail on both Haromny and RI 1.4.2
Thanks a lot.
/*
* test constructor: averBytesPerChar maxBytesPerChar
*/
public void testConstructorIlegalAverageBytesPerChar() {
try {
Charset cs = Charset.forName(UTF-8); //$NON-NLS-1$
CharsetDecoder decoder = new MockCharsetDecoderForHarmony142(cs,
1.1f, 1);
fail(Should throw IllegalArgumentException.); //$NON-NLS-1$
} catch (IllegalArgumentException e) {
// expected
}
}
/*
* MockCharsetDecoderForHarmony142: for constructor test
*/
static class MockCharsetDecoderForHarmony142 extends CharsetDecoder {
protected MockCharsetDecoderForHarmony142(Charset cs,
float averageBytesPerChar, float maxBytesPerChar) {
super(cs, averageBytesPerChar, maxBytesPerChar);
}
protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out) {
return null;
}
}
java.nio.charset.CharsetDecoder constructor doesn't throw
IllegalArgumentException when averageCharsPerByte is greater than
maxCharsPerByte.
Key: HARMONY-142
URL: http://issues.apache.org/jira/browse/HARMONY-142
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
As spec says, constructor throws IllegalArgumentException when parameters are
illegal. It should be considered as illegal parameters when
averageCharsPerByte is greater than maxCharsPerByte.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-136) Cannot make libvmi.so and libhytext.so on linux
[ http://issues.apache.org/jira/browse/HARMONY-136?page=comments#action_12367950 ] Richard Liang commented on HARMONY-136: --- Thank you, Mark. Maybe we should document this issue in something like Harmony Build Guide to remind other people to use the latest make. Cannot make libvmi.so and libhytext.so on linux --- Key: HARMONY-136 URL: http://issues.apache.org/jira/browse/HARMONY-136 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Hello, When trying to build Harmony native code on my redhat linux (RHEL 3), I fail to make the libvmi.so. But after I convert the makefile(revision=379478) to unix format using dos2unix, the make is successful. The same problem occurs in module text. in /native-src/linux.IA32/vmi/ issue command: make output: cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -I../include-c -o vmi_copyright.o vmi_copyright.c cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -I../include-c -o vmi.o vmi.c cc -shared -Wl,-Map=vmi.map \ -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ -L. -L../lib -L.. -o ../libvmi.so \ vmi_copyright.o vmi.o -Xlinker --start-group \ : No such file or directory make: *** [../libvmi.so] Error 1 issue command: dos2unix makefile issue command: make output: cc -shared -Wl,-Map=vmi.map \ -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ -L. -L../lib -L.. -o ../libvmi.so \ vmi_copyright.o vmi.o -Xlinker --start-group \ -lhyzip \ -lhypool -Xlinker --end-group -lc -lm -ldl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-136) Cannot make libvmi.so and libhytext.so on linux
[ http://issues.apache.org/jira/browse/HARMONY-136?page=all ] Richard Liang updated HARMONY-136: -- Attachment: readme_patch.txt Add a new section of Troubleshooting Known Problems in README.txt. Feel free to change my words. :-) Cannot make libvmi.so and libhytext.so on linux --- Key: HARMONY-136 URL: http://issues.apache.org/jira/browse/HARMONY-136 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Attachments: readme_patch.txt Hello, When trying to build Harmony native code on my redhat linux (RHEL 3), I fail to make the libvmi.so. But after I convert the makefile(revision=379478) to unix format using dos2unix, the make is successful. The same problem occurs in module text. in /native-src/linux.IA32/vmi/ issue command: make output: cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -I../include-c -o vmi_copyright.o vmi_copyright.c cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -I../include-c -o vmi.o vmi.c cc -shared -Wl,-Map=vmi.map \ -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ -L. -L../lib -L.. -o ../libvmi.so \ vmi_copyright.o vmi.o -Xlinker --start-group \ : No such file or directory make: *** [../libvmi.so] Error 1 issue command: dos2unix makefile issue command: make output: cc -shared -Wl,-Map=vmi.map \ -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ -L. -L../lib -L.. -o ../libvmi.so \ vmi_copyright.o vmi.o -Xlinker --start-group \ -lhyzip \ -lhypool -Xlinker --end-group -lc -lm -ldl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-96) Two new methods need to be implemented by java.nio.charset.Charset
[ http://issues.apache.org/jira/browse/HARMONY-96?page=comments#action_12367894 ] Richard Liang commented on HARMONY-96: -- Tim, Looks good. Thanks a lot. Two new methods need to be implemented by java.nio.charset.Charset -- Key: HARMONY-96 URL: http://issues.apache.org/jira/browse/HARMONY-96 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Attachments: charset_patch.txt There are two new methods added since Java 5.0 1. public static Charset defaultCharset() 2. public final int compareTo(Charset that) I'd like to implement the two methods and attach my code soon :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-36) java.nio.CharBuffer does not implement java.lang.Appendable and java.lang.Readable
[ http://issues.apache.org/jira/browse/HARMONY-36?page=comments#action_12367895 ] Richard Liang commented on HARMONY-36: -- Tim, The fix is good. Please close this JIRA. Thanks a lot. java.nio.CharBuffer does not implement java.lang.Appendable and java.lang.Readable -- Key: HARMONY-36 URL: http://issues.apache.org/jira/browse/HARMONY-36 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Attachments: Appendable.java, CharBufferTest_patch.txt, CharBuffer_patch.txt, CharSequenceAdapter_patch.txt, Readable.java In Java 5, java.nio.CharBuffer are required to implement two new interfaces java.lang.Appendable and java.lang.Readable. I will attache the new interfaces and fix for java.nio.CharBuffer soon :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-43) Performance enhancement for nio buffers bulk get/put methods
[ http://issues.apache.org/jira/browse/HARMONY-43?page=comments#action_12367896 ] Richard Liang commented on HARMONY-43: -- Tim, The fix is good. Please close this JIRA. Thanks a lot. Performance enhancement for nio buffers bulk get/put methods Key: HARMONY-43 URL: http://issues.apache.org/jira/browse/HARMONY-43 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Attachments: CharBuffer_patch.txt, OtherBuffer_patch.txt The performance of some bulk get/put methods can be enhanced. I will post the patches one by one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-113) java.nio.charset.Charset should regard empty charset name properly as Illegal CharsetName
[
http://issues.apache.org/jira/browse/HARMONY-113?page=comments#action_12367897
]
Richard Liang commented on HARMONY-113:
---
Yes, Tim. The patch looks good.
java.nio.charset.Charset should regard empty charset name properly as Illegal
CharsetName
-
Key: HARMONY-113
URL: http://issues.apache.org/jira/browse/HARMONY-113
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Assignee: Tim Ellison
Attachments: charset_patch.txt
I think it's caused by the different between RI 1.4.2 and RI 5.0. Three test
cases in JIRA#57 should be updated accordingly.
public void testIsSupported_EmptyString() {
try {
Charset.isSupported();
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
public void testConstructor_EmptyCanonicalName() {
try {
new MockCharset(, new String[0]);
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
public void testConstructor_EmptyAliases() {
try {
new MockCharset(mockChar, new String[] { });
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-123) Refactor: java.nio.charset.CharsetDecoder.decode
[ http://issues.apache.org/jira/browse/HARMONY-123?page=comments#action_12367898 ] Richard Liang commented on HARMONY-123: --- Tim, The fix is good. Please close this JIRA. Thanks a lot. Refactor: java.nio.charset.CharsetDecoder.decode Key: HARMONY-123 URL: http://issues.apache.org/jira/browse/HARMONY-123 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Priority: Minor Attachments: CharsetDecoder_patch.txt I've refactored two decode methods in CharsetDecode.java. Although the original version runs well, the structure of these two methods is messed. The refactored methods include: 1. public final CharBuffer decode(ByteBuffer in) throws CharacterCodingException; 2. public final CoderResult decode(ByteBuffer in, CharBuffer out,boolean endOfInput); Main changes: 1. remove embedded while in decode(ByteBuffer in, CharBuffer out,boolean endOfInput); 2. restruct condition control process in both two methods. 3. truncate return value of decode(in), which means the returned CharBuffer has the same value between capacity and limit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-136) Cannot make libvmi.so and libhytext.so on linux
Cannot make libvmi.so and libhytext.so on linux --- Key: HARMONY-136 URL: http://issues.apache.org/jira/browse/HARMONY-136 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Hello, When trying to build Harmony native code on my redhat linux (RHEL 3), I fail to make the libvmi.so. But after I convert the makefile(revision=379478) to unix format using dos2unix, the make is successful. The same problem occurs in module text. in /native-src/linux.IA32/vmi/ issue command: make output: cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -I../include-c -o vmi_copyright.o vmi_copyright.c cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -I../include-c -o vmi.o vmi.c cc -shared -Wl,-Map=vmi.map \ -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ -L. -L../lib -L.. -o ../libvmi.so \ vmi_copyright.o vmi.o -Xlinker --start-group \ : No such file or directory make: *** [../libvmi.so] Error 1 issue command: dos2unix makefile issue command: make output: cc -shared -Wl,-Map=vmi.map \ -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ -L. -L../lib -L.. -o ../libvmi.so \ vmi_copyright.o vmi.o -Xlinker --start-group \ -lhyzip \ -lhypool -Xlinker --end-group -lc -lm -ldl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-124) java.nio.charset.CharsetDecoder doesn't throw CoderMalfunctionError exception when decodeLoop threw unexpected exception.
[ http://issues.apache.org/jira/browse/HARMONY-124?page=all ]
Richard Liang updated HARMONY-124:
--
Attachment: Charset_patch.txt
CharsetDecoder_patch.txt
The patches are attached.
java.nio.charset.Charset.java and java.nio.charset.CharsetDecoder.java are
modified.
Could you please take a try to apply patches ?
Charset_patch.txt is for java.nio.charset.Charset.java , and
CharsetDecoder_patch.txt is for java.nio.charset.CharsetDecoder.java.
You could simply click team-apply patch to apply these patches.
Java spec doesn't point out clearly which expections are unexpected. To be
compatible with RI, BufferOverflowException and BufferUnderflowException
are treated as unexpected exception currently.
Thank you!
java.nio.charset.CharsetDecoder doesn't throw CoderMalfunctionError exception
when decodeLoop threw unexpected exception.
-
Key: HARMONY-124
URL: http://issues.apache.org/jira/browse/HARMONY-124
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Attachments: CharsetDecoder_patch.txt, Charset_patch.txt
public final CoderResult decode(ByteBuffer in, CharBuffer out, boolean
endOfInput)
As spec says, the method throws CoderMalfunctionError if an invocation of the
decodeLoop method threw an unexpected exception.
However, Harmony doesn't throws CoderMalfunctionError when decodeLoop method
threw an unexpected exception.
The following test cases pass on RI , but fail on Harmony.
/*
* Test malfunction decode(ByteBuffer)
*/
public void testDecode_CoderMalfunctionError() throws Exception {
MockMalfunctionCharset cs = new MockMalfunctionCharset(mock,
null);
try{
cs.newDecoder().onMalformedInput(CodingErrorAction.REPLACE)
.onUnmappableCharacter(CodingErrorAction.REPLACE).decode(ByteBuffer.wrap(new
byte[]{0x00,0x11}));
fail(should throw CoderMalfunctionError);//NON-NLS-1$
}catch(CoderMalfunctionError e){
//expected
}
}
/*
* Test malfunction decode(ByteBuffer)
*/
public void testDecode_NoCoderMalfunctionError() throws Exception {
MockMalfunctionCharset cs = new MockMalfunctionCharset(mock,
null);
try{
cs.decode(ByteBuffer.wrap(new byte[]{0x00,0x11}));
}catch(CoderMalfunctionError e){
fail(Charset.decode should return
silently);//NON-NLS-1
}
}
/*
* Mock charset class with malfunction decode encode.
*/
static final class MockMalfunctionCharset extends Charset {
public MockMalfunctionCharset(String canonicalName, String[]
aliases) {
super(canonicalName, aliases);
}
public boolean contains(Charset cs) {
return false;
}
public CharsetDecoder newDecoder() {
return new MockMalfunctionDecoder(this);
}
public CharsetEncoder newEncoder() {
return new MockMalfunctionEncoder(this);
}
}
/*
* Mock decoder. decodeLoop always throws unexpected exception.
*/
static class MockMalfunctionDecoder extends
java.nio.charset.CharsetDecoder {
public MockMalfunctionDecoder(Charset cs) {
super(cs, 1, 10);
}
protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out)
{
throw new BufferOverflowException();
}
}
/*
* Mock encoder. encodeLoop always throws unexpected exception.
*/
static class MockMalfunctionEncoder extends
java.nio.charset.CharsetEncoder {
public MockMalfunctionEncoder(Charset cs) {
super(cs, 1, 3, new byte[] { (byte) '?' });
}
protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out)
{
throw new BufferOverflowException();
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-113) java.nio.charset.Charset should regard empty charset name properly as Illegal CharsetName
[
http://issues.apache.org/jira/browse/HARMONY-113?page=comments#action_12367618
]
Richard Liang commented on HARMONY-113:
---
Yes, Tim.
I think you can fix this issue. I will verify your update after you mark this
issue as fixed. When JIRA57 is acceptted I will create patch for the test
cases, otherwise there may be duplication. :-)
Thanks a lot.
java.nio.charset.Charset should regard empty charset name properly as Illegal
CharsetName
-
Key: HARMONY-113
URL: http://issues.apache.org/jira/browse/HARMONY-113
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Attachments: charset_patch.txt
I think it's caused by the different between RI 1.4.2 and RI 5.0. Three test
cases in JIRA#57 should be updated accordingly.
public void testIsSupported_EmptyString() {
try {
Charset.isSupported();
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
public void testConstructor_EmptyCanonicalName() {
try {
new MockCharset(, new String[0]);
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
public void testConstructor_EmptyAliases() {
try {
new MockCharset(mockChar, new String[] { });
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-123) Refactor: java.nio.charset.CharsetDecoder.decode
Refactor: java.nio.charset.CharsetDecoder.decode Key: HARMONY-123 URL: http://issues.apache.org/jira/browse/HARMONY-123 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Priority: Minor I've refactored two decode methods in CharsetDecode.java. Although the original version runs well, the structure of these two methods is messed. The refactored methods include: 1. public final CharBuffer decode(ByteBuffer in) throws CharacterCodingException; 2. public final CoderResult decode(ByteBuffer in, CharBuffer out,boolean endOfInput); Main changes: 1. remove embedded while in decode(ByteBuffer in, CharBuffer out,boolean endOfInput); 2. restruct condition control process in both two methods. 3. truncate return value of decode(in), which means the returned CharBuffer has the same value between capacity and limit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-123) Refactor: java.nio.charset.CharsetDecoder.decode
[ http://issues.apache.org/jira/browse/HARMONY-123?page=all ] Richard Liang updated HARMONY-123: -- Attachment: CharsetDecoder_patch.txt Here is my update. Would you please take a try? Thanks a lot. Refactor: java.nio.charset.CharsetDecoder.decode Key: HARMONY-123 URL: http://issues.apache.org/jira/browse/HARMONY-123 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Priority: Minor Attachments: CharsetDecoder_patch.txt I've refactored two decode methods in CharsetDecode.java. Although the original version runs well, the structure of these two methods is messed. The refactored methods include: 1. public final CharBuffer decode(ByteBuffer in) throws CharacterCodingException; 2. public final CoderResult decode(ByteBuffer in, CharBuffer out,boolean endOfInput); Main changes: 1. remove embedded while in decode(ByteBuffer in, CharBuffer out,boolean endOfInput); 2. restruct condition control process in both two methods. 3. truncate return value of decode(in), which means the returned CharBuffer has the same value between capacity and limit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-113) java.nio.charset.Charset should regard empty charset name properly as Illegal CharsetName
java.nio.charset.Charset should regard empty charset name properly as Illegal
CharsetName
-
Key: HARMONY-113
URL: http://issues.apache.org/jira/browse/HARMONY-113
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
I think it's caused by the different between RI 1.4.2 and RI 5.0. Three test
cases in JIRA#57 should be updated accordingly.
public void testIsSupported_EmptyString() {
try {
Charset.isSupported();
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
public void testConstructor_EmptyCanonicalName() {
try {
new MockCharset(, new String[0]);
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
public void testConstructor_EmptyAliases() {
try {
new MockCharset(mockChar, new String[] { });
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-113) java.nio.charset.Charset should regard empty charset name properly as Illegal CharsetName
[ http://issues.apache.org/jira/browse/HARMONY-113?page=all ]
Richard Liang updated HARMONY-113:
--
Attachment: charset_patch.txt
Please try my patch. Thanks a lot.
java.nio.charset.Charset should regard empty charset name properly as Illegal
CharsetName
-
Key: HARMONY-113
URL: http://issues.apache.org/jira/browse/HARMONY-113
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Attachments: charset_patch.txt
I think it's caused by the different between RI 1.4.2 and RI 5.0. Three test
cases in JIRA#57 should be updated accordingly.
public void testIsSupported_EmptyString() {
try {
Charset.isSupported();
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
public void testConstructor_EmptyCanonicalName() {
try {
new MockCharset(, new String[0]);
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
public void testConstructor_EmptyAliases() {
try {
new MockCharset(mockChar, new String[] { });
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-106) java.text.DecimalFormat does not parse infinite values correctly
java.text.DecimalFormat does not parse infinite values correctly
Key: HARMONY-106
URL: http://issues.apache.org/jira/browse/HARMONY-106
Project: Harmony
Type: Bug
Reporter: Richard Liang
In Java 1.4.2 Spec of java.text.DecimalFormat.parse(String, ParsePosition),
it's said:
Values that cannot fit into a Long are returned as Doubles. This includes
values with a fractional part, infinite values, NaN, and the value -0.0.
The test cases will fail if excuting under Harmony and pass on RI:
// Test whether DecimalFormat can parse Positive infinity correctly
public void testParseInfinityBigDecimalFalse() {
DecimalFormat format = (DecimalFormat) DecimalFormat.getInstance();
DecimalFormatSymbols symbols = new DecimalFormatSymbols();
Number number = format.parse(symbols.getInfinity(), new
ParsePosition(0));
assertTrue(number instanceof Double);
assertTrue(Double.isInfinite(number.doubleValue()));
}
// Test whether DecimalFormat can parse Negative infinity correctly
public void testParseMinusInfinityBigDecimalFalse() {
DecimalFormat format = (DecimalFormat) DecimalFormat.getInstance();
DecimalFormatSymbols symbols = new DecimalFormatSymbols();
Number number = format.parse(- + symbols.getInfinity(),
new ParsePosition(0));
assertTrue(number instanceof Double);
assertTrue(Double.isInfinite(number.doubleValue()));
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-96) Two new methods need to be implemented by java.nio.charset.Charset
Two new methods need to be implemented by java.nio.charset.Charset -- Key: HARMONY-96 URL: http://issues.apache.org/jira/browse/HARMONY-96 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang There are two new methods added since Java 5.0 1. public static Charset defaultCharset() 2. public final int compareTo(Charset that) I'd like to implement the two methods and attach my code soon :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-68) java.nio.charset.Charset.isSupported(String charsetName) does not throw IllegalCharsetNameException for spoiled standard sharset name
[ http://issues.apache.org/jira/browse/HARMONY-68?page=all ]
Richard Liang updated HARMONY-68:
-
Attachment: charset_patch.txt
Please try my patch according to the spec of Java 5.0 :-)
java.nio.charset.Charset.isSupported(String charsetName) does not throw
IllegalCharsetNameException for spoiled standard sharset name
-
Key: HARMONY-68
URL: http://issues.apache.org/jira/browse/HARMONY-68
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Attachments: charset_patch.txt
According to j2se 1.4.2 specification for Charset.isSupported(String
charsetName) the method must throw IllegalCharsetNameException if the
given charset name is illegal .
Legal charset name must begin with either a letter or a digit.
The test listed below shows that there is no the exception if to insert -
or _ symbols before standard sharset name, for example -UTF-8 or
_US-ASCII.
Moreover the method returns true in this case.
BEA also does not throw the exception but returns false.
Code to reproduce:
import java.nio.charset.*;
public class test2 {
public static void main (String[] args) {
// string starts neither a letter nor a digit
boolean sup=false;
try{
sup=Charset.isSupported(-UTF-8);
System.out.println(***BAD. should be exception; sup=+sup);
sup=Charset.isSupported(_US-ASCII);
System.out.println(***BAD. should be exception; sup=+sup);
} catch (IllegalCharsetNameException e) {
System.out.println(***OK. Expected IllegalCharsetNameException
+ e);
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
***BAD. should be exception; sup=false
***BAD. should be exception; sup=false
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
***BAD. should be exception; sup=true
***BAD. should be exception; sup=true
Suggested junit test case:
CharserTest.java
-
import java.nio.charset.*;
import junit.framework.*;
public class CharsetTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(CharsetTest.class);
}
public void test_isSupported() {
boolean sup=false;
// string starts neither a letter nor a digit
try{
sup=Charset.isSupported(-UTF-8);
fail(***BAD. should be exception IllegalCharsetNameException);
} catch (IllegalCharsetNameException e) { //expected
}
// string starts neither a letter nor a digit
try{
sup=Charset.isSupported(_US-ASCII);
fail(***BAD. should be exception IllegalCharsetNameException);
} catch (IllegalCharsetNameException e) { //expected
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-99) java.nio.charset.CharsetDecoder.decode(ByteBuffer in) does not throw MalformedInputException when buffer's current position is not legal
[ http://issues.apache.org/jira/browse/HARMONY-99?page=all ]
Richard Liang updated HARMONY-99:
-
Attachment: CharsetDecoder_patch.txt
Please try me patch. At least, it will pass the proposed test case. :-)
java.nio.charset.CharsetDecoder.decode(ByteBuffer in) does not throw
MalformedInputException when buffer's current position is not legal
Key: HARMONY-99
URL: http://issues.apache.org/jira/browse/HARMONY-99
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Attachments: CharsetDecoder_patch.txt
According to 1.4.2 and 1.5 java.nio.charset.CharsetDecoder.decode(ByteBuffer
in) throws
MalformedInputException - If the byte sequence starting at the input buffer's
current position is not legal for this charset and the current
malformed-input action is CodingErrorAction.REPORT.
Harmony does not throw MalformedInputException in this case as test listed
below shows.
Code to reproduce:
import java.nio.*;
import java.nio.charset.*;
public class test2 {
public static void main(String[] args) throws Exception {
Charset cs =Charset.forName(utf-16);
CharsetDecoder decoder = cs.newDecoder();
decoder.onMalformedInput(CodingErrorAction.REPORT);
decoder.onUnmappableCharacter(CodingErrorAction.REPORT);
CharBuffer out = CharBuffer.allocate(10);
ByteBuffer in = ByteBuffer.wrap(new byte[] { 109, 97, 109});
CharBuffer res1 = decoder.decode(in);
//output
System.out.println(CharBuffer==+res1);
System.out.println(CharBuffer.position ==+res1.position());
System.out.println(toHexString==+Integer.toHexString(res1.charAt(0)));
System.out.println(ByteBuffer.position()==+in.position());
System.out.println(ByteBuffer.remaining()==+in.remaining());
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
java.nio.charset.MalformedInputException: Input length = 1
at
java.nio.charset.CoderResult.throwException()V(CoderResult.java:260)
at
java.nio.charset.CharsetDecoder.decode(Ljava.nio.ByteBuffer;)Ljava.nio.CharBuffer;(CharsetDecoder.java:763)
at test2.main([Ljava.lang.String;)V(test2.java:34)
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
res1==
res1==0
toHexString==6d61
ByteBuffer.position()==3
ByteBuffer.remaining()==0
Suggested junit test case:
CharsetDecoderTest.java
-
import junit.framework.*;
import java.nio.*;
import java.nio.charset.*;
public class CharsetDecoderTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(CharsetDecoderTest.class);
}
public void test_decode() {
try {
Charset cs =Charset.forName(utf-16);
CharsetDecoder decoder = cs.newDecoder();
decoder.onMalformedInput(CodingErrorAction.REPORT);
decoder.onUnmappableCharacter(CodingErrorAction.REPORT);
CharBuffer out = CharBuffer.allocate(10);
ByteBuffer in = ByteBuffer.wrap(new byte[] { 109, 97, 109});
CharBuffer res1 = decoder.decode(in);
fail(MalformedInputException should have thrown);
} catch (MalformedInputException e) {
//expected
} catch (CharacterCodingException e) {
fail(unexpected CharacterCodingException);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-92) Suggestion: Move com.ibm.platform from NIO to LUNI
Suggestion: Move com.ibm.platform from NIO to LUNI -- Key: HARMONY-92 URL: http://issues.apache.org/jira/browse/HARMONY-92 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Hello Tim, As we discussed in JIRA 27 and JIRA 42, I suggest we move the packages com.ibm.platform and com.ibm.platform.struct from NIO to LUNI component. As these packages are used by java.net, as well as java.nio.channels. I will post the proposed fix soon :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-92) Suggestion: Move com.ibm.platform from NIO to LUNI
[ http://issues.apache.org/jira/browse/HARMONY-92?page=comments#action_12366423 ] Richard Liang commented on HARMONY-92: -- According to the package naming convention (http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html), I suggest we rename com.ibm.platform to org.apache.harmony.luni.platform, and com.ibm.platform.struct to org.apache.harmony.luni.platform.struct Any comments? Suggestion: Move com.ibm.platform from NIO to LUNI -- Key: HARMONY-92 URL: http://issues.apache.org/jira/browse/HARMONY-92 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Hello Tim, As we discussed in JIRA 27 and JIRA 42, I suggest we move the packages com.ibm.platform and com.ibm.platform.struct from NIO to LUNI component. As these packages are used by java.net, as well as java.nio.channels. I will post the proposed fix soon :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-92) Suggestion: Move com.ibm.platform from NIO to LUNI
[ http://issues.apache.org/jira/browse/HARMONY-92?page=all ] Richard Liang updated HARMONY-92: - Attachment: refactor_platform.zip Hello, Here is the patch for this issue. 1. For java source, it's more convenient to use Eclipse's refact-move, rename (You can also copy files from the attachment) 2. For native source, please copy files from the attachment, then apply the patch file. (Though there are only some copy, paste, delete, and rename operations, we have done it for you.) Thanks a lot. Suggestion: Move com.ibm.platform from NIO to LUNI -- Key: HARMONY-92 URL: http://issues.apache.org/jira/browse/HARMONY-92 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Attachments: refactor_platform.zip Hello Tim, As we discussed in JIRA 27 and JIRA 42, I suggest we move the packages com.ibm.platform and com.ibm.platform.struct from NIO to LUNI component. As these packages are used by java.net, as well as java.nio.channels. I will post the proposed fix soon :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-42) com.ibm.io.nio.FileChannel is not fully implemented
[ http://issues.apache.org/jira/browse/HARMONY-42?page=comments#action_12366146 ] Richard Liang commented on HARMONY-42: -- Thanks a lot, Tim. We are satisfied with the patch application. You may close this JIRA. com.ibm.io.nio.FileChannel is not fully implemented --- Key: HARMONY-42 URL: http://issues.apache.org/jira/browse/HARMONY-42 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Tim Ellison Attachments: FileChannel_patch.zip, Harmony42-IFileSystem-patch.txt, Harmony42-IMemorySystem-patch.txt, Harmony42-java_io_FileChannelFactory-patch.txt, Harmony42-java_io_FileOutputStream-patch.txt, IFileSystem.java Many functions of FileChannel, such as memory map, transfer, gathering/scattering I/O are not implemented. Further, three classes in java.io, FileInputStream FileOutputStream, and RandomAccessFile, are related to java.nio.FileChannel, so that they can be refactored to base on same JNI interface, just like the network channels and sockets. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-42) com.ibm.io.nio.FileChannel is not fully implemented
[ http://issues.apache.org/jira/browse/HARMONY-42?page=all ] Richard Liang updated HARMONY-42: - Attachment: FileChannel_patch.zip Hello Tim, Finally, The refactor of FileChannel and related classes are completed :-), as well as some modification about some native code (OS File system and OS Memory system). Would you please help to verify my patches? Thanks a lot. Hopefully, I will post my test cases soon :-) com.ibm.io.nio.FileChannel is not fully implemented --- Key: HARMONY-42 URL: http://issues.apache.org/jira/browse/HARMONY-42 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Tim Ellison Attachments: FileChannel_patch.zip, Harmony42-IFileSystem-patch.txt, Harmony42-IMemorySystem-patch.txt, Harmony42-java_io_FileChannelFactory-patch.txt, Harmony42-java_io_FileOutputStream-patch.txt, IFileSystem.java Many functions of FileChannel, such as memory map, transfer, gathering/scattering I/O are not implemented. Further, three classes in java.io, FileInputStream FileOutputStream, and RandomAccessFile, are related to java.nio.FileChannel, so that they can be refactored to base on same JNI interface, just like the network channels and sockets. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-43) Performance enhancement for nio buffers bulk get/put methods
[ http://issues.apache.org/jira/browse/HARMONY-43?page=all ] Richard Liang updated HARMONY-43: - Attachment: OtherBuffer_patch.txt Hello Tim, Here is the patch file for all other buffers (except for CharBuffer). The changes are just similar to those of CharBuffer. Would you please try to apply the patch? Thanks a lot. Performance enhancement for nio buffers bulk get/put methods Key: HARMONY-43 URL: http://issues.apache.org/jira/browse/HARMONY-43 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Attachments: CharBuffer_patch.txt, OtherBuffer_patch.txt The performance of some bulk get/put methods can be enhanced. I will post the patches one by one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-43) Performance enhancement for nio buffers bulk get/put methods
Performance enhancement for nio buffers bulk get/put methods Key: HARMONY-43 URL: http://issues.apache.org/jira/browse/HARMONY-43 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang The performance of some bulk get/put methods can be enhanced. I will post the patches one by one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-43) Performance enhancement for nio buffers bulk get/put methods
[ http://issues.apache.org/jira/browse/HARMONY-43?page=all ] Richard Liang updated HARMONY-43: - Attachment: CharBuffer_patch.txt This patch is created against java.nio which will affect the following files: java.nio.CharBuffer java.nio.CharArrayBuffer java.nio.CharSequenceAdapter java.nio.CharToByteBufferAdapter java.nio.ReadOnlyCharArrayBuffer java.nio.ReadWriteCharArrayBuffer Performance enhancement for nio buffers bulk get/put methods Key: HARMONY-43 URL: http://issues.apache.org/jira/browse/HARMONY-43 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Attachments: CharBuffer_patch.txt The performance of some bulk get/put methods can be enhanced. I will post the patches one by one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-36) java.nio.CharBuffer does not implement java.lang.Appendable and java.lang.Readable
[ http://issues.apache.org/jira/browse/HARMONY-36?page=all ] Richard Liang updated HARMONY-36: - Attachment: CharBuffer_patch.txt CharSequenceAdapter_patch.txt CharBufferTest_patch.txt These are patch files for java.nio.CharBuffer, java.nio.CharSequenceAdapter and unit test for java.nio.CharBuffer. Could anyone verify my fix? Thanks a lot. java.nio.CharBuffer does not implement java.lang.Appendable and java.lang.Readable -- Key: HARMONY-36 URL: http://issues.apache.org/jira/browse/HARMONY-36 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Attachments: Appendable.java, CharBufferTest_patch.txt, CharBuffer_patch.txt, CharSequenceAdapter_patch.txt, Readable.java In Java 5, java.nio.CharBuffer are required to implement two new interfaces java.lang.Appendable and java.lang.Readable. I will attache the new interfaces and fix for java.nio.CharBuffer soon :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-30) java.text.BreakIterator.next () returns incorrect value
[
http://issues.apache.org/jira/browse/HARMONY-30?page=comments#action_12363211 ]
Richard Liang commented on HARMONY-30:
--
Proposed fix:
Change the method
public static BreakIterator getWordInstance(Locale where) {
return new RuleBasedBreakIterator(com.ibm.icu.text.BreakIterator
.getSentenceInstance(where));
}
to
public static BreakIterator getWordInstance(Locale where) {
return new RuleBasedBreakIterator(com.ibm.icu.text.BreakIterator
.getWordInstance(where));
}
java.text.BreakIterator.next () returns incorrect value
Key: HARMONY-30
URL: http://issues.apache.org/jira/browse/HARMONY-30
Project: Harmony
Type: Bug
Components: Classlib
Reporter: tatyana doubtsova
Assignee: Geir Magnusson Jr
java.text.BreakIterator.next () returns incorrect value
Code for reproducing Test.java:
import java.text.BreakIterator;
import java.util.Locale;
public class Test {
public static void main (String[] args) {
BreakIterator bi = BreakIterator.getWordInstance(Locale.US);
bi.setText(This is the test, WordInstance);
int n = bi.first();
System.out.println(bi.first() = + n);
n = bi.next();
System.out.println(bi.next() = + n);
}
}
Steps to Reproduce:
1. Build Harmony-14 j2se subset as described in README.txt.
2. Compile Test.java using BEA 1.4 javac
javac -d . Test.java
2. Run java using compatible VM (J9)
java -showversion Test
Output:
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
bi.first() = 0
bi.next() = 30
Output on BEA 1.4.2 to compare with:
bi.first() = 0
bi.next() = 4
Suggested junit test case:
package org.apache.harmony.tests.java.text;
import java.text.BreakIterator;
import java.util.Locale;
import junit.framework.TestCase;
public class BreakIteratorTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(BreakIteratorTest.class);
}
public void test_next() {
BreakIterator bi = BreakIterator.getWordInstance(Locale.US);
bi.setText(This is the test, WordInstance);
int n = bi.first();
n = bi.next();
assertTrue(Assert 0: next() returns incorrect value + n, n
== 4 );
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-26) The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
[ http://issues.apache.org/jira/browse/HARMONY-26?page=all ] Richard Liang updated HARMONY-26: - Attachment: nio-tests.jar The API of buffer classes in java.nio are not compliant with the specification of Java 5.0 -- Key: HARMONY-26 URL: http://issues.apache.org/jira/browse/HARMONY-26 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Attachments: DirectBuffer.java, nio-tests.jar 1. java.nio.CharBuffer 1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable 1.2) The following methods should NOT be protected: protected CharBuffer(int capacity) protected abstract char[] protectedArray(); protected abstract int protectedArrayOffset(); protected abstract boolean protectedHasArray(); 1.3) The following method should be final: public CharBuffer put(char[] src) 2. java.nio.Buffer 2.1) The following fields should NOT be protected: int UNSET_MARK int capacity int limit int mark should int position 2.3) The following method should NOT be protected: protected Buffer(int capacity) 3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer 3.1) The following field should NOT be protected: com.ibm.platform.Endianness order 3.2) The following methods should NOT be protected: protected ByteBuffer(int capacity) protected abstract byte[] protectedArray(); protected abstract int protectedArrayOffset(); protected abstract boolean protectedHasArray(); 3.3) The following method should be final: public ByteBuffer order(ByteOrder byteOrder) 4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-26) The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
[ http://issues.apache.org/jira/browse/HARMONY-26?page=all ] Richard Liang updated HARMONY-26: - Attachment: DirectBuffer.java This is the new interface added in com.ibm.io.nio The API of buffer classes in java.nio are not compliant with the specification of Java 5.0 -- Key: HARMONY-26 URL: http://issues.apache.org/jira/browse/HARMONY-26 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Attachments: DirectBuffer.java 1. java.nio.CharBuffer 1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable 1.2) The following methods should NOT be protected: protected CharBuffer(int capacity) protected abstract char[] protectedArray(); protected abstract int protectedArrayOffset(); protected abstract boolean protectedHasArray(); 1.3) The following method should be final: public CharBuffer put(char[] src) 2. java.nio.Buffer 2.1) The following fields should NOT be protected: int UNSET_MARK int capacity int limit int mark should int position 2.3) The following method should NOT be protected: protected Buffer(int capacity) 3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer 3.1) The following field should NOT be protected: com.ibm.platform.Endianness order 3.2) The following methods should NOT be protected: protected ByteBuffer(int capacity) protected abstract byte[] protectedArray(); protected abstract int protectedArrayOffset(); protected abstract boolean protectedHasArray(); 3.3) The following method should be final: public ByteBuffer order(ByteOrder byteOrder) 4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-32) java.text.Collator.setDecomposition(FULL_DECOMPOSITION) throws IllegalArgumentException
[
http://issues.apache.org/jira/browse/HARMONY-32?page=comments#action_12363208 ]
Richard Liang commented on HARMONY-32:
--
Having a looking at the javadoc of com.ibm.icu.text.Collator, I find that
icu4j's collator officially supports only two decomposition mode:
CANONICAL_DECOMPOSITION and NO_DECOMPOSITION. (FULL_DECOMPOSITION is in
Deprecated status).
For this issue, throwing a more specific expcetion such as
*NotYetImplementedException* may be a better solution.
Any comment?
Thanks a lot.
java.text.Collator.setDecomposition(FULL_DECOMPOSITION) throws
IllegalArgumentException
Key: HARMONY-32
URL: http://issues.apache.org/jira/browse/HARMONY-32
Project: Harmony
Type: Bug
Components: Classlib
Reporter: tatyana doubtsova
Assignee: Geir Magnusson Jr
Code for reproducing Test.java:
import java.text.Collator;
import java.util.Locale;
public class Test {
public static void main (String[] args) {
Collator c = Collator.getInstance(Locale.US);
c.setDecomposition(Collator.FULL_DECOMPOSITION);
int decompositionMode = c.getDecomposition();
System.out.println(decomposition Mode is +
decompositionMode);
}
}
Steps to Reproduce:
1. Build Harmony-14 j2se subset as described in README.txt.
2. Compile Test.java using BEA 1.4 javac
javac -d . Test.java
2. Run java using compatible VM (J9)
java -showversion Test
Output:
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
Exception in thread main java.lang.IllegalArgumentException: Wrong
decomposition mode.
at com.ibm.icu.text.Collator.setDecomposition(Collator.java:295)
at java.text.Collator.setDecomposition(Collator.java:277)
at Test.main(Test.java:7)
Output on BEA 1.4.2:
decomposition Mode is 2
Suggested junit test case:
package org.apache.harmony.tests.java.text;
import java.text.Collator;
import java.util.Locale;
import junit.framework.TestCase;
public class CollatorTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(CollatorTest.class);
}
public void test_setDecomposition() {
Collator c = Collator.getInstance(Locale.US);
try {
c.setDecomposition(Collator.FULL_DECOMPOSITION);
} catch (Exception e) {
fail(Assert 0: Unexpected exception + e);
}
int decompositionMode = c.getDecomposition();
assertTrue(Assert 1: next() returns incorrect value +
decompositionMode, decompositionMode == Collator.FULL_DECOMPOSITION );
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-26) The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
The API of buffer classes in java.nio are not compliant with the specification of Java 5.0 -- Key: HARMONY-26 URL: http://issues.apache.org/jira/browse/HARMONY-26 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Assigned to: Geir Magnusson Jr 1. java.nio.CharBuffer 1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable 1.2) The following methods should NOT be protected: protected CharBuffer(int capacity) protected abstract char[] protectedArray(); protected abstract int protectedArrayOffset(); protected abstract boolean protectedHasArray(); 1.3) The following method should be final: public CharBuffer put(char[] src) 2. java.nio.Buffer 2.1) The following fields should NOT be protected: int UNSET_MARK int capacity int limit int mark should int position 2.3) The following method should NOT be protected: protected Buffer(int capacity) 3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer 3.1) The following field should NOT be protected: com.ibm.platform.Endianness order 3.2) The following methods should NOT be protected: protected ByteBuffer(int capacity) protected abstract byte[] protectedArray(); protected abstract int protectedArrayOffset(); protected abstract boolean protectedHasArray(); 3.3) The following method should be final: public ByteBuffer order(ByteOrder byteOrder) 4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
