[jira] Updated: (HARMONY-159) Two JSE 5 methods are not implemented in java.util.zip.Inflator
[ http://issues.apache.org/jira/browse/HARMONY-159?page=all ] Paulex Yang updated HARMONY-159: Attachment: java.util.zip.Inflater.patch java.util.zip.InflaterTests.patch 159-native-patch.txt the patches are attached, and same with JIRA 158, for java impl, test and native respectively. Pls. apply the native patch on the native-src directory. Two JSE 5 methods are not implemented in java.util.zip.Inflator --- Key: HARMONY-159 URL: http://issues.apache.org/jira/browse/HARMONY-159 Project: Harmony Type: Bug Reporter: Paulex Yang Attachments: 159-native-patch.txt, java.util.zip.Inflater.patch, java.util.zip.InflaterTests.patch Two methods: java/util/zip/Inflater public getBytesRead()J java/util/zip/Inflater public getBytesWritten()J are introduced by JSE 5, but they are not been implemented by Harmony yet. -- 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-172) Harmony text component has some API difference with JSE 5 spec
Harmony text component has some API difference with JSE 5 spec -- Key: HARMONY-172 URL: http://issues.apache.org/jira/browse/HARMONY-172 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Priority: Minor Three new methods added to java.text.BreakIterator method java.text.BreakIterator.getInt(byte[], int) method java.text.BreakIterator.getLong(byte[], int) method java.text.BreakIterator.getShort(byte[], int) One method signature difference in java.text.NumberFormat java/text/NumberFormat format(Object, StringBuffer,FieldPosition) should not be final -- 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-172) Harmony text component has some API difference with JSE 5 spec
[ http://issues.apache.org/jira/browse/HARMONY-172?page=all ] Paulex Yang updated HARMONY-172: Attachment: java.text.BreakIterator.patch java.text.NumberFormat.patch Patches are attached. As we discussed before on mailing list, the BreakIterator's three new methods throw NotYetImplementedException directly, due to these methods are removed again in JSE 6 spec. Harmony text component has some API difference with JSE 5 spec -- Key: HARMONY-172 URL: http://issues.apache.org/jira/browse/HARMONY-172 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Priority: Minor Attachments: java.text.BreakIterator.patch, java.text.NumberFormat.patch Three new methods added to java.text.BreakIterator method java.text.BreakIterator.getInt(byte[], int) method java.text.BreakIterator.getLong(byte[], int) method java.text.BreakIterator.getShort(byte[], int) One method signature difference in java.text.NumberFormat java/text/NumberFormat format(Object, StringBuffer,FieldPosition) should not be final -- 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-178) java.text.DateFormat$Field's contructor may replace predefined consts with new value in cache
java.text.DateFormat$Field's contructor may replace predefined consts with new
value in cache
-
Key: HARMONY-178
URL: http://issues.apache.org/jira/browse/HARMONY-178
Project: Harmony
Type: Bug
Reporter: Paulex Yang
DataFormat$Field will cache some constants to be searched by method
ofCalendarField(int), but the predefined consts should not be replaced.
the testcases is as below:
import java.text.DateFormat;
import java.util.Calendar;
import junit.framework.TestCase;
public class DataFormatFieldTest extends TestCase{
public void test_Constructor2() {
MyField field = new MyField(day of month, Calendar.ERA);
DateFormat.Field realField = DateFormat.Field
.ofCalendarField(Calendar.ERA);
assertSame(Modified calendar field with the same field number,
DateFormat.Field.ERA, realField);
}
static class MyField extends DateFormat.Field {
protected MyField(String fieldName, int calendarField) {
super(fieldName, calendarField);
}
protected String getName() {
return super.getName();
}
}
}
Run on RI 5.0, test case passes.
Run on Harmony, test case fail with message:
junit.framework.AssertionFailedError: Modified calendar field with the same
field number expected same:java.text.DateFormat$Field(era) was
not:DataFormatFieldTest$MyField(day of month)
--
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-178) java.text.DateFormat$Field's contructor may replace predefined consts with new value in cache
[ http://issues.apache.org/jira/browse/HARMONY-178?page=all ]
Paulex Yang updated HARMONY-178:
Attachment: java.text.DateFormat.patch
java.text.DateFormatFieldTest.patch
patch for fix and test is attached. And for your information, the test is
extracted from Harmon JIRA 57.
java.text.DateFormat$Field's contructor may replace predefined consts with
new value in cache
-
Key: HARMONY-178
URL: http://issues.apache.org/jira/browse/HARMONY-178
Project: Harmony
Type: Bug
Reporter: Paulex Yang
Attachments: java.text.DateFormat.patch, java.text.DateFormatFieldTest.patch
DataFormat$Field will cache some constants to be searched by method
ofCalendarField(int), but the predefined consts should not be replaced.
the testcases is as below:
import java.text.DateFormat;
import java.util.Calendar;
import junit.framework.TestCase;
public class DataFormatFieldTest extends TestCase{
public void test_Constructor2() {
MyField field = new MyField(day of month, Calendar.ERA);
DateFormat.Field realField = DateFormat.Field
.ofCalendarField(Calendar.ERA);
assertSame(Modified calendar field with the same field number,
DateFormat.Field.ERA, realField);
}
static class MyField extends DateFormat.Field {
protected MyField(String fieldName, int calendarField) {
super(fieldName, calendarField);
}
protected String getName() {
return super.getName();
}
}
}
Run on RI 5.0, test case passes.
Run on Harmony, test case fail with message:
junit.framework.AssertionFailedError: Modified calendar field with the same
field number expected same:java.text.DateFormat$Field(era) was
not:DataFormatFieldTest$MyField(day of month)
--
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-184) java.util.TimeZone's default implementation may cause many classes' serialization non-compatible with RI
java.util.TimeZone's default implementation may cause many classes'
serialization non-compatible with RI
Key: HARMONY-184
URL: http://issues.apache.org/jira/browse/HARMONY-184
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Priority: Critical
Static factory methods, java.util.TimeZone.getInstance(String) and
getDefault(), are only ways to get a TimeZone instance, but Harmony and RI uses
different classes as default implementation, which cause serialization
non-compatible. Further, all classes whose serialization form includes TimeZone
won't compatible with RI, too, for example, java.util.Calendar(with subclass),
java.text.DateFormat(with subclass), etc.
But the incompatiblity is hard to be imputed to Harmony, because Harmony use
API class SimpleTimeZone as default implementation, but RI use a non-API class,
whose full name is sun.util.calendar.ZoneInfo.
The reproduce procedure:
1. To serialize TimeZone object to a file in RI, run codes below in RI
public void writeObject(){
TimeZone zone = TimeZone.getTimeZone(GMT);
ObjectOutputStream ooutput = null;
try {
ooutput = new ObjectOutputStream(new
FileOutputStream(TimeZone.ser));
ooutput.writeObject(zone);
} finally {
try {
if (null != ooutput) {
ooutput.close();
}
} catch (Exception e) {
}
}
}
2. Trying to deserialize this object from file, run codes below
public void readObject(){
ObjectInputStream oinput = null;
try {
oinput = new ObjectInputStream(new
FileInputStream(TimeZone.ser));
TimeZone newObj = (TimeZone)oinput.readObject();
} finally {
try {
if (null != oinput) {
oinput.close();
}
} catch (Exception e) {
}
}
}
Run in RI, passes without any failure
Run in Harmony, exception throwed as below:
java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
at java.lang.Class.forName(Class.java:154)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
... ...
--
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-160) Three JSE 5 methods are not implemented in java.util.zip.InflaterInputStream
[ http://issues.apache.org/jira/browse/HARMONY-160?page=all ] Paulex Yang updated HARMONY-160: Attachment: java.util.zip.InflaterStreamTests.patch The prior fix is fine, thx. Here goes the patch for tests. Three JSE 5 methods are not implemented in java.util.zip.InflaterInputStream Key: HARMONY-160 URL: http://issues.apache.org/jira/browse/HARMONY-160 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Tim Ellison Attachments: java.util.zip.InflaterStreamTests.patch, java.util.zip.inflaterinputStream.patch Three methods: java/util/zip/InflaterInputStream public markSupported()Z, java/util/zip/InflaterInputStream public mark(I)V, java/util/zip/InflaterInputStream public reset()V, are overridden in JSE 5, but they not implemented in 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-158) Two JSE 5 methods are not implemented in java.util.zip.Deflator
[ http://issues.apache.org/jira/browse/HARMONY-158?page=all ] Paulex Yang updated HARMONY-158: Attachment: java.util.zip.Deflater.patch java.util.zip.DeflaterTests.patch 158-native-patch.txt The patches are attached, one for java implementation, one for test, and the last for native codes. Pls. note that the native patches include both win.IA32 and linux.IA32, so pls. apply them on level of native-src directory. Two JSE 5 methods are not implemented in java.util.zip.Deflator --- Key: HARMONY-158 URL: http://issues.apache.org/jira/browse/HARMONY-158 Project: Harmony Type: Bug Reporter: Paulex Yang Attachments: 158-native-patch.txt, java.util.zip.Deflater.patch, java.util.zip.DeflaterTests.patch Two methods: java/util/zip/Deflater public getBytesRead()J java/util/zip/Deflater public getBytesWritten()J are introduced by JSE 5, but they are not been implemented by Harmony yet. -- 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-160) Three JSE 5 methods are not implemented in java.util.zip.InflaterInputStream
[ http://issues.apache.org/jira/browse/HARMONY-160?page=all ] Paulex Yang updated HARMONY-160: Attachment: java.util.zip.inflaterinputStream.patch Would you pls. to try this patch? thx a lot. Three JSE 5 methods are not implemented in java.util.zip.InflaterInputStream Key: HARMONY-160 URL: http://issues.apache.org/jira/browse/HARMONY-160 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Attachments: java.util.zip.inflaterinputStream.patch Three methods: java/util/zip/InflaterInputStream public markSupported()Z, java/util/zip/InflaterInputStream public mark(I)V, java/util/zip/InflaterInputStream public reset()V, are overridden in JSE 5, but they not implemented in 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-156) InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() should return a historical charset name.
[ http://issues.apache.org/jira/browse/HARMONY-156?page=comments#action_12368656 ] Paulex Yang commented on HARMONY-156: - All the spec about Charset historical name is: Some charsets have an historical name that is defined for compatibility with previous versions of the Java platform. A charset's historical name is either its canonical name or one of its aliases. From this paragraph, I personally think the historical name is specific to RI without any public standard:(, so the only way to be compatible with RI is write testcases to get all historical names of RI supported Charsets, and store them in an map. I can provide the patch of tests(to get all historical name) and the mapping implementation, but before that, I hope I can get some better idea from the mailing list to avoid this ugly solution:-\. InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() should return a historical charset name. - Key: HARMONY-156 URL: http://issues.apache.org/jira/browse/HARMONY-156 Project: Harmony Type: Bug Components: Classlib Reporter: Dmitry M. Kononov Priority: Minor InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() return canonical names on the given charsets instead of historical ones. For example, new OutputStreamWriter(new ByteArrayOutputStream(), UTF-16BE).getEncoding() has to return the UnicodeBigUnmarked string as a historical name. But it returns UTF-16BE, that is a canonical name. The java spec reads the historical names as the charset names defined for compatibility with previous versions of the Java platform. -- 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-158) Two JSE 5 methods are not implemented in java.util.zip.Deflator
Two JSE 5 methods are not implemented in java.util.zip.Deflator --- Key: HARMONY-158 URL: http://issues.apache.org/jira/browse/HARMONY-158 Project: Harmony Type: Bug Reporter: Paulex Yang Two methods: java/util/zip/Deflater public getBytesRead()J java/util/zip/Deflater public getBytesWritten()J are introduced by JSE 5, but they are not been implemented by Harmony yet. -- 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-159) Two JSE 5 methods are not implemented in java.util.zip.Inflator
Two JSE 5 methods are not implemented in java.util.zip.Inflator --- Key: HARMONY-159 URL: http://issues.apache.org/jira/browse/HARMONY-159 Project: Harmony Type: Bug Reporter: Paulex Yang Two methods: java/util/zip/Inflater public getBytesRead()J java/util/zip/Inflater public getBytesWritten()J are introduced by JSE 5, but they are not been implemented by Harmony yet. -- 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-160) Three JSE 5 methods are not implemented in java.util.zip.InflaterInputStream
Three JSE 5 methods are not implemented in java.util.zip.InflaterInputStream Key: HARMONY-160 URL: http://issues.apache.org/jira/browse/HARMONY-160 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Three methods: java/util/zip/InflaterInputStream public markSupported()Z, java/util/zip/InflaterInputStream public mark(I)V, java/util/zip/InflaterInputStream public reset()V, are overridden in JSE 5, but they not implemented in 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] Created: (HARMONY-162) One JSE 5 method are not implemented in java/util/jar/JarEntry
One JSE 5 method are not implemented in java/util/jar/JarEntry -- Key: HARMONY-162 URL: http://issues.apache.org/jira/browse/HARMONY-162 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang java/util/jar/JarEntry public getCodeSigners() is introduced by JSE 5, but not implemented in 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] Created: (HARMONY-163) Three types in java.util.jar are not implemented in Harmony
Three types in java.util.jar are not implemented in Harmony --- Key: HARMONY-163 URL: http://issues.apache.org/jira/browse/HARMONY-163 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Three types: public abstract class java/util/jar/Pack200 public interface java/util/jar/Pack200$Packer public interface java/util/jar/Pack200$Unpacker are introduced in JSE 5, but not implemented in 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-137) CharsetDecoder should replace undefined bytes with replacement string
[
http://issues.apache.org/jira/browse/HARMONY-137?page=comments#action_12367917
]
Paulex Yang commented on HARMONY-137:
-
A little investigation on the Harmony codes, seems it is caused by problems of
ICU4JNI decoder provider, the following test cases shows that. RI cp1250
passes the testcase while ICU cp1250 fails under either RI or Harmony . I'll
try to report the bug to ICU.
Test case:
public void testDecode_JIRA137() {
ByteBuffer bb = ByteBuffer.allocate(5);
bb.put((byte) 0x81);
bb.flip();
// Use ICU cp1250 charset
CharsetProviderICU provider = new CharsetProviderICU();
Charset cp1250 = provider.charsetForName(cp1250);
// Uncomment code below to use RI charset
//cp1250 = Charset.forName(cp1250);
CharBuffer cb;
try {
cb = cp1250.newDecoder()
.onMalformedInput(CodingErrorAction.REPLACE)
.onUnmappableCharacter(CodingErrorAction.REPLACE)
.decode(bb);
assertEquals(0XFFFD,cb.get(0));
} catch (CharacterCodingException e) {
e.printStackTrace();
}
}
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] Commented: (HARMONY-63) java.text.MessageFormat.parse(String): incorrect size of Object array parsed from the string
[
http://issues.apache.org/jira/browse/HARMONY-63?page=comments#action_12366167 ]
Paulex Yang commented on HARMONY-63:
A test suite on text package are included here,
http://issues.apache.org/jira/browse/HARMONY-57, it should be helpful on
regression test.
java.text.MessageFormat.parse(String): incorrect size of Object array parsed
from the string
Key: HARMONY-63
URL: http://issues.apache.org/jira/browse/HARMONY-63
Project: Harmony
Type: Bug
Components: Classlib
Reporter: tatyana doubtsova
Attachments: MessageFormat_patch.txt
Problem details:
Method java.text.MessageFormat.parse(String) returns the array of 10 elements
when parsing string 1,00,00' using pattern {0,number,#,}. It should
return array of 1 element.
Code for reproducing Test.java:
import java.text.MessageFormat;
import java.util.Locale;
public class Test {
public static void main(String[] args) {
try {
MessageFormat mf = new MessageFormat({0,number,#,},
Locale.US);
Object[] res = mf.parse(1,00,00);
System.out.println(result's length: + res.length);
for (int i = 0; i res.length; i++) {
System.out.println(result is: + res[0]);
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile Test.java using BEA 1.4 javac
javac -d . Test.java
3. 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.
result's length: 10
result is: 1
result is: 1
result is: 1
result is: 1
result is: 1
result is: 1
result is: 1
result is: 1
result is: 1
result is: 1
Output on BEA 1.4.2 to compare with:
result's length: 1
result is: 1
Suggested junit test case:
package org.apache.harmony.tests.java.text;
import java.text.MessageFormat;
import java.util.Locale;
import junit.framework.TestCase;
public class MessageFormatTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(MessageFormatTest.class);
}
public void test_parse() {
try {
MessageFormat mf = new MessageFormat({0,number,#,},
Locale.US);
Object[] res = mf.parse(1,00,00);
assertEquals(Assert 0: incorrect size of parsed data , 1,
res.length);
} catch (Exception e) {
fail(Assert 0: Unexpected exception + 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-84) java.net.InetAddress() shouldn't perform reverse name lookup
java.net.InetAddress() shouldn't perform reverse name lookup
Key: HARMONY-84
URL: http://issues.apache.org/jira/browse/HARMONY-84
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Priority: Minor
Currently, the java.net.InetAddress.toString() is as below:
code
public String toString() {
return getHostName() + / + getHostAddress();
}
/code
But actually the toString() should behave differently with getHostName()!
the Java spec for toString():
spec
Converts this IP address to a String. The string returned is of the
form: hostname / literal IP address. If the host name is unresolved, no reverse
name service loopup is performed. The hostname part will be represented by an
empty string.
/spec
and the spec for getHostName() says:
spec
If this InetAddress was created with a host name, this host name will be
remembered and returned; otherwise, a reverse name lookup will be performed and
the result will be returned based on the system configured name lookup service.
/spec
Spec shows that toString() shouldn't perform reverse name lookup while
getHostName() should!
A simple test show this bug:
code
public class ToStringTest{
public static void main(String[] args) throws Exception{
InetAddress addr = InetAddress.getByName(localhost);
System.out.println(addr);
InetAddress addr2 = InetAddress.getByAddress(new byte[]{127, 0, 0, 1});
System.out.println(addr2);
}
}
/code
on RI, it outputs:
localhost/127.0.0.1
/127.0.0.1
and on Harmony, it outputs:
localhost/127.0.0.1
localhost/127.0.0.1
--
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-84) java.net.InetAddress() shouldn't perform reverse name lookup
[
http://issues.apache.org/jira/browse/HARMONY-84?page=comments#action_12365837 ]
Paulex Yang commented on HARMONY-84:
A suggested simple fix is rewrite the toString() as below:
code
public String toString() {
return (hostName==null?:hostName)+/+getHostAddress();
}
/code
java.net.InetAddress() shouldn't perform reverse name lookup
Key: HARMONY-84
URL: http://issues.apache.org/jira/browse/HARMONY-84
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Priority: Minor
Currently, the java.net.InetAddress.toString() is as below:
code
public String toString() {
return getHostName() + / + getHostAddress();
}
/code
But actually the toString() should behave differently with getHostName()!
the Java spec for toString():
spec
Converts this IP address to a String. The string returned is of the
form: hostname / literal IP address. If the host name is unresolved, no
reverse name service loopup is performed. The hostname part will be
represented by an empty string.
/spec
and the spec for getHostName() says:
spec
If this InetAddress was created with a host name, this host name will be
remembered and returned; otherwise, a reverse name lookup will be performed
and the result will be returned based on the system configured name lookup
service.
/spec
Spec shows that toString() shouldn't perform reverse name lookup while
getHostName() should!
A simple test show this bug:
code
public class ToStringTest{
public static void main(String[] args) throws Exception{
InetAddress addr = InetAddress.getByName(localhost);
System.out.println(addr);
InetAddress addr2 = InetAddress.getByAddress(new byte[]{127, 0, 0,
1});
System.out.println(addr2);
}
}
/code
on RI, it outputs:
localhost/127.0.0.1
/127.0.0.1
and on Harmony, it outputs:
localhost/127.0.0.1
localhost/127.0.0.1
--
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-73) java.net.InetAddress.getLocalHost() returns wrong host name for loopback address
[
http://issues.apache.org/jira/browse/HARMONY-73?page=comments#action_12365843 ]
Paulex Yang commented on HARMONY-73:
Further study shows that the prior patch is not needed, in fact, my proposed
fix for issue 84 (http://issues.apache.org/jira/browse/HARMONY-84) is enough to
fix this issue as by product.
java.net.InetAddress.getLocalHost() returns wrong host name for loopback
address
-
Key: HARMONY-73
URL: http://issues.apache.org/jira/browse/HARMONY-73
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Priority: Minor
Attachments: InetAddress.patch
J2se 1.4.2 and 5.0 specifications for java.net.InetAddress.getLocalHost()
read, that if there is a security manager, its checkConnect method is called
with the local host name and -1 as its arguments to see if the operation is
allowed.
If the operation is not allowed, an InetAddress representing the loopback
address is returned as hostname/hostaddress (as followed from toString()
specification).
The test listed below shows that the returned loopback address has wrong
hostname, 127.0.0.1 instead of loopback.
Inet_SecurityManager class is called twice and therefore host name is
substituted with hostaddress address.
Code to reproduce:
import java.net.*;
public class test2 {
public static void main(String[] args) {
try {
System.setSecurityManager(new Inet_SecurityManager());
System.out.println(Loopback address = +
InetAddress.getLocalHost());
} catch (Exception e){
System.out.println(Unexpected exception = + e);
};
}
}
class Inet_SecurityManager extends SecurityManager {
public void checkConnect(String host, int port) {
super.checkConnect(host,port);
throw new SecurityException();
}
}
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)
Inet_SecurityManager :host= nswssamoil1
Inet_SecurityManager :port= -1
Loopback address = localhost/127.0.0.1
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
Inet_SecurityManager :host= nswssamoil1
Inet_SecurityManager :port= -1
Inet_SecurityManager :host= localhost
Inet_SecurityManager :port= -1
Loopback address = 127.0.0.1/127.0.0.1
Suggested junit test case:
InetAddressTest.java
-
import java.net.*;
import junit.framework.*;
public class InetAddressTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(InetAddress.class);
}
public void test_getLocalHost() {
try{
System.setSecurityManager(new Inet_SecurityManager());
String hostname=InetAddress.getLocalHost().getHostName();
assertEquals(localhost, hostname);
} catch (Exception e){
fail(Unexpected exception = + e);
};
}
}
class Inet_SecurityManager extends SecurityManager {
public void checkConnect(String host, int port) {
super.checkConnect(host,port);
throw new SecurityException();
}
}
--
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-70) java.io.FileInputStream.close() must close channel associated with this FileInputStream
[
http://issues.apache.org/jira/browse/HARMONY-70?page=comments#action_12365680 ]
Paulex Yang commented on HARMONY-70:
This issue is similiar with issue
40(http://issues.apache.org/jira/browse/HARMONY-40), pls. refer to my comments
for that issue, and these issues should be fixed by patches for issue
42(http://issues.apache.org/jira/browse/HARMONY-42).
java.io.FileInputStream.close() must close channel associated with this
FileInputStream
---
Key: HARMONY-70
URL: http://issues.apache.org/jira/browse/HARMONY-70
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
J2SE 1.4 specification reads for the method java.io.FileInputStream.close() :
If this stream has an associated channel then the channel is closed as well.
But the channel is still opened.
Code to reproduce:
import java.io.*;
import java.nio.channels.*;
public class test29 {
public static void main(String[] args) {
try {
File f = File.createTempFile(temp, .txt);
f.deleteOnExit();
FileInputStream fis = new FileInputStream(f);
FileChannel fch = fis.getChannel();
fis.close();
System.out.println(fch.isOpen = + fch.isOpen());
} catch (Exception e) {
System.out.println(unex = + e);
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test29.java using BEA 1.4 javac
javac -d . test29.java
3. Run java using compatible VM (J9)
java -showversion test29
Output:
C:\tmp\tmp17C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test29
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)
fch.isOpen = false
C:\tmp\tmp17C:\harmony\trunk\deploy\jre\bin\java -showversion test29
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
fch.isOpen = true
junit test:
FileInputStreamTest.java
-
import java.io.*;
import java.nio.channels.*;
import junit.framework.*;
public class FileInputStreamTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(FileInputStreamTest.class);
}
public void testClose() {
try {
File f = File.createTempFile(temp, .txt);
f.deleteOnExit();
FileInputStream fis = new FileInputStream(f);
FileChannel fch = fis.getChannel();
fis.close();
assertFalse(FAILED, channel still opened!, fch.isOpen());
} catch (Exception e) {
fail(Unexpected exception: + 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-69) java.io.RandomAccessFile(String name, String mode) doesn't allow to open a file in a read-only mode
[
http://issues.apache.org/jira/browse/HARMONY-69?page=comments#action_12365682 ]
Paulex Yang commented on HARMONY-69:
An alternative fix is to modify the problematic constructor as follows:
public RandomAccessFile(String fileName, String mode)
throws FileNotFoundException {
this(new File(fileName), mode);
}
java.io.RandomAccessFile(String name, String mode) doesn't allow to open a
file in a read-only mode
---
Key: HARMONY-69
URL: http://issues.apache.org/jira/browse/HARMONY-69
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
java.io.RandomAccessFile(String name, String mode) doesn't allow to open a
file in a read-only mode. Looks like the mode is always rw.
Note, java.io.RandomAccessFile(File file, String mode) works OK.
Code to reproduce:
import java.io.*;
import java.nio.channels.*;
public class test29 {
private static void testMode(RandomAccessFile raf, int index) {
try {
FileChannel fcr = raf.getChannel();
// fcr.lock() should throw NonWritableChannelException for r
mode
fcr.lock(0L, Long.MAX_VALUE, false);
fcr.close();
System.out.println(Error + index);
} catch (NonWritableChannelException e) {
System.out.println(Success + index + : + e);
} catch (Throwable e) {
System.out.println(Exception + index + : + e);
e.printStackTrace();
}
}
public static void testRandomAccessFile_File_String(File f, int index) {
try {
System.out.println(Create RAF(File, Sting): + f);
RandomAccessFile raf = new RandomAccessFile(f, r);
testMode(raf, index);
raf.close();
} catch (Throwable e) {
System.out.println(Exception + index + : + e);
e.printStackTrace();
}
}
public static void testRandomAccessFile_String_String(String f, int
index) {
try {
System.out.println(Create RAF(File, Sting): + f);
RandomAccessFile raf = new RandomAccessFile(f, r);
testMode(raf, index);
raf.close();
} catch (Throwable e) {
System.out.println(Exception + index + : + e);
e.printStackTrace();
}
}
public static void main(String[] args) {
try {
File f = File.createTempFile(temp, .txt);
f.deleteOnExit();
testRandomAccessFile_File_String(f, 1);
testRandomAccessFile_String_String(f.getAbsolutePath(), 2);
testRandomAccessFile_File_String(f, 3);
} catch (Throwable e) {
System.out.println(Unexpected exception: + e);
e.printStackTrace();
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test29.java using BEA 1.4 javac
javac -d . test29.java
3. Run java using compatible VM (J9)
java -showversion test29
Output:
C:\tmp\tmp17C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test29
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)
Create RAF(File, Sting): C:\DOCUME~1\vivanov1\LOCALS~1\Temp\temp23838.txt
Success1: java.nio.channels.NonWritableChannelException
Create RAF(File, Sting): C:\DOCUME~1\vivanov1\LOCALS~1\Temp\temp23838.txt
Success2: java.nio.channels.NonWritableChannelException
Create RAF(File, Sting): C:\DOCUME~1\vivanov1\LOCALS~1\Temp\temp23838.txt
Success3: java.nio.channels.NonWritableChannelException
C:\tmp\tmp17C:\harmony\trunk\deploy\jre\bin\java -showversion test29
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
Create RAF(File, Sting): C:\DOCUME~1\vivanov1\LOCALS~1\Temp\temp24535.txt
Success1: java.nio.channels.NonWritableChannelException
Create RAF(File, Sting): C:\DOCUME~1\vivanov1\LOCALS~1\Temp\temp24535.txt
Error 2
Create RAF(File, Sting): C:\DOCUME~1\vivanov1\LOCALS~1\Temp\temp24535.txt
Success3: java.nio.channels.NonWritableChannelException
Suggested fix:
Add the string to set up current mode like the string in the
RandomAccessFile(File, String) method in the class RandomAccessFile.java
sting #122:
122: isReadOnly = mode.equals(r);
junit test:
RandomAccessFileTest.java
-
import java.io.*;
import java.nio.channels.*;
import junit.framework.*;
public class RandomAccessFileTest extends
[jira] Updated: (HARMONY-73) java.net.InetAddress.getLocalHost() returns wrong host name for loopback address
[ http://issues.apache.org/jira/browse/HARMONY-73?page=all ]
Paulex Yang updated HARMONY-73:
---
Attachment: InetAddress.patch
A suggested modification is to add these two lines before Ln. 296 of
java.net.InetAddress,
if(this == LOOPBACK){
return localhost;
}
So that the getHostName() will return localhost instead of 127.0.0.1.
The patch is attached.
java.net.InetAddress.getLocalHost() returns wrong host name for loopback
address
-
Key: HARMONY-73
URL: http://issues.apache.org/jira/browse/HARMONY-73
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Priority: Minor
Attachments: InetAddress.patch
J2se 1.4.2 and 5.0 specifications for java.net.InetAddress.getLocalHost()
read, that if there is a security manager, its checkConnect method is called
with the local host name and -1 as its arguments to see if the operation is
allowed.
If the operation is not allowed, an InetAddress representing the loopback
address is returned as hostname/hostaddress (as followed from toString()
specification).
The test listed below shows that the returned loopback address has wrong
hostname, 127.0.0.1 instead of loopback.
Inet_SecurityManager class is called twice and therefore host name is
substituted with hostaddress address.
Code to reproduce:
import java.net.*;
public class test2 {
public static void main(String[] args) {
try {
System.setSecurityManager(new Inet_SecurityManager());
System.out.println(Loopback address = +
InetAddress.getLocalHost());
} catch (Exception e){
System.out.println(Unexpected exception = + e);
};
}
}
class Inet_SecurityManager extends SecurityManager {
public void checkConnect(String host, int port) {
super.checkConnect(host,port);
throw new SecurityException();
}
}
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)
Inet_SecurityManager :host= nswssamoil1
Inet_SecurityManager :port= -1
Loopback address = localhost/127.0.0.1
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
Inet_SecurityManager :host= nswssamoil1
Inet_SecurityManager :port= -1
Inet_SecurityManager :host= localhost
Inet_SecurityManager :port= -1
Loopback address = 127.0.0.1/127.0.0.1
Suggested junit test case:
InetAddressTest.java
-
import java.net.*;
import junit.framework.*;
public class InetAddressTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(InetAddress.class);
}
public void test_getLocalHost() {
try{
System.setSecurityManager(new Inet_SecurityManager());
String hostname=InetAddress.getLocalHost().getHostName();
assertEquals(localhost, hostname);
} catch (Exception e){
fail(Unexpected exception = + e);
};
}
}
class Inet_SecurityManager extends SecurityManager {
public void checkConnect(String host, int port) {
super.checkConnect(host,port);
throw new SecurityException();
}
}
--
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 ]
Paulex Yang updated HARMONY-42:
---
Attachment: Harmony42-java_io_FileChannelFactory-patch.txt
Harmony42-java_io_FileOutputStream-patch.txt
A POC refactor patch for java.io.FileOutputStream is attached, with some minor
changes on FileChannelFactory. java.io.FileInputStream and RandomAccessFile can
be easily refactored in similiar style.
As a completement to my comment on the issue 40, The FileChannelImpl's
implCloseChannel() can look like:
protected void implCloseChannel() throws IOException {
if(stream instanceof Closeable){
((Closeable)stream).close();
}
fileSystem.close(handle);
}
and the FileChannelImpl's super class, AbstractInterruptibleChannel's close
method can be:
public synchronized final void close() throws IOException {
if (!closed) {
closed = true;
implCloseChannel();
}
}
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: 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] Created: (HARMONY-38) com.ibm.platform.struct.AbstractMemorySpy doesn't actually autoFree native memory
com.ibm.platform.struct.AbstractMemorySpy doesn't actually autoFree native
memory
-
Key: HARMONY-38
URL: http://issues.apache.org/jira/browse/HARMONY-38
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Priority: Critical
com.ibm.platform.struct.IMemorySpy is a memory watcher, and the
AbstractMemorySpy is a default implementation working with nio direct buffers
to free the native memories when direct buffer instances are garbage collected.
But currently its auto free donsn't work.
Look inside the orphanedMemory(Object obj) method, the memory is freed only if
the local variable wrapper can be found from the memoryInUse, a Map which
records the native memories used by direct buffers, but actually it will be
removed when autoFree(PlatfromAddress) is invoked. Checking the autoFree()
reference, I found that all DirectByteBuffer will invoke autoFree() in
constructor, which means no memory will be freed.
A simple fix:
modify the Ln 94 in autoFree() from:
wrapper = (AddressWrapper) memoryInUse.remove(address);
to:
wrapper = (AddressWrapper) memoryInUse.get(address);
and it should work.
The steps to reproduce the bug:
1. Add the following line in the the Ln109, which indicates the memory is auto
freed by AbstractMemorySpy
System.out.println(MemorySpy autofree:+wrapper.shadow);
2. Run the test below:
public class MemorySpyTest {
public static void main(String[] args) throws Exception {
for (int i = 0; i 1000; i++) {
try{
ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
buffer = null;
}catch(Exception e){
e.printStackTrace();
}
System.gc();
}
}
Before modification: application exits silently.
After modification, hundres of lines printed out, like this:
.
MemorySpy autofree:PlatformAddress[9310024]
MemorySpy autofree:PlatformAddress[9311056]
MemorySpy autofree:PlatformAddress[9312088]
MemorySpy autofree:PlatformAddress[9313120]
MemorySpy autofree:PlatformAddress[9314152]
MemorySpy autofree:PlatformAddress[9315184]
MemorySpy autofree:PlatformAddress[9316216]
MemorySpy autofree:PlatformAddress[9317248]
...
Another possible pitfall in AbstractMemorySpy is it uses WeakReference and
ReferenceQueue to get notification when the buffers are ready to be garbage
collected. But it is not so safe yet to free the native memory, because the
weakly-reachable object has its chance to be resurrected to strongly-reachable,
if only some finalize() method doing this is executed. A safer solution is to
use PhantomReference instead, because phantom-reachable object has no chance to
survive. The only concern is the PhantomReference should be explicitly cleared
by application, but that's OK because the orphanedMemory() method is a perfect
candidate to do this.
I will attach the patch 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-27) The network related channels in java.nio.channels are not implemented
[ http://issues.apache.org/jira/browse/HARMONY-27?page=all ] Paulex Yang updated HARMONY-27: --- Attachment: INetworkSystem.java OSNetworkSystem.java FileDescriptorHandler.java This files demonstrate what I mean on the JNI interface, which encapsulate network relevant functions for both NIO and LUNI component. Significant part of the method declarations are refactored from current Harmony java.net JNI methods, others are added to support NIO extension. The network related channels in java.nio.channels are not implemented - Key: HARMONY-27 URL: http://issues.apache.org/jira/browse/HARMONY-27 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Geir Magnusson Jr Attachments: FileDescriptorHandler.java, INetworkSystem.java, Nio-net Refactoring.jpg, OSNetworkSystem.java, java.net.JPG The following classes defined by Java Spec 5.0 in java.nio.channels are not included in the class library code public abstarct class java.nio.channels.DatagramChannel public abstract class java.nio.channels.ServerSocketChannel public abstract class java.nio.channels.SocketChannel -- 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-27) The network related channels in java.nio.channels are not implemented
[ http://issues.apache.org/jira/browse/HARMONY-27?page=all ] Paulex Yang updated HARMONY-27: --- Attachment: java.net.JPG the current java.net class diagram The network related channels in java.nio.channels are not implemented - Key: HARMONY-27 URL: http://issues.apache.org/jira/browse/HARMONY-27 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Geir Magnusson Jr Attachments: Nio-net Refactoring.jpg, java.net.JPG The following classes defined by Java Spec 5.0 in java.nio.channels are not included in the class library code public abstarct class java.nio.channels.DatagramChannel public abstract class java.nio.channels.ServerSocketChannel public abstract class java.nio.channels.SocketChannel -- 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-27) The network related channels in java.nio.channels are not implemented
The network related channels in java.nio.channels are not implemented -- Key: HARMONY-27 URL: http://issues.apache.org/jira/browse/HARMONY-27 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assigned to: Geir Magnusson Jr The following classes defined by Java Spec 5.0 in java.nio.channels are not included in the class library code public abstarct class java.nio.channels.DatagramChannel public abstract class java.nio.channels.ServerSocketChannel public abstract class java.nio.channels.SocketChannel -- 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
