Re: [classlib] Sun compiler change?
Alexey Varlamov 写道: 2006/8/29, Spark Shen [EMAIL PROTECTED]: Krzysztof Sobolewski 写道: Spark Shen wrote: Did you (refer to thread [app] ant with ecj) put Eclipse compiler JAR on Ant's execution classpath to execute the javac task. If so, may be that's why It always gives you unchecked cast warning, no errors. Well, I created a new EnumSet class in completly unrelated environment... So it is perfectly possible that there's a classpath conflict somewhere. I can't verify that because don't have the Harmony build here :) BTW: another experiment revealed that EnumSet? extends EnumE set = (EnumSet? extends EnumE)collection; compiles without warnings. No matter how much I think I understand generics, there's always something that surprises me ;) Conceptually speaking, I think EnumSet? extends EnumE still has potential pitfall: In the signature of addAll(Collection? extends E collection) method, ? denotes subclass of E. While in EnumSet? extends EnumE, ? denotes subclass of EnumE. But consider the relationship between E and EnumE, E is subclass of EnumE. So, we can not guarantee that subclass of E is definitely subclass of EnumE. Hmm, as E is a subclass of EnumE, subclasses of E definitely have EnumE among ancestors ;) Yes, you are right. And I made a wrong judgement here. :-P The actual statement I want to judge is that: E is subclass of EnumE. So, we can not guarantee that subclasses of E(? extends E) is definitely compatible with subclasses of EnumE(? extends EnumE). Since the input collection is of type ? extends E, cast it to ? extends EnumE seems suspicious. Correct me if I am wrong. Best regards -KS -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1295) [classlib][net] flaw in setReuseAddrAndReusePort()
On 8/29/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/8/29, Andrew Zhang [EMAIL PROTECTED]: On 8/28/06, Alexey Varlamov (JIRA) [EMAIL PROTECTED] wrote: [classlib][net] flaw in setReuseAddrAndReusePort() -- Key: HARMONY-1295 URL: http://issues.apache.org/jira/browse/HARMONY-1295 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Varlamov Priority: Critical The tests.api.java.net.DatagramSocketTest test crashes on assert in DRLVM : Assertion `IsInstanceOf(env, obj, struct_Class_to_jclass(f-get_class()))' failed. The reason is that java.net.DatagramSocket.setReuseAddress(boolean) calls to PlainDatagramSocketImpl.setOption(int optID, Object val) with Boolean value, but underlying native code treats this value as Integer. Quickfix must be straightforward enough, but I inclined to blame the design of INetworkSystem.[set|get]SocketOption() as the actual root of the evil. The problem is that this API conceals the details of contract for particular options, and a client have to guess which type of value to pass. I think it's determine, not guess. :) And the implementation is basically an ugly switch sorting requests out to setBoolSocketOption() or setIntegerSocketOption(), etc. Shouldn'te refactor this? Any proposals? Thanks! Of course, lots of them ;). Just to start: 1) Why at all we clone underlying OS interface to Java with extra mapping JAVASOCKOPT_* to HY_SO_*? Totally agree with you. :) Current two option lists are duplicated. I think we'd better use one type defination. Let's have a clean API with specialized methods as XXXSocket classes have: setTTL(int) , isReuseAddress() etc. It's a design problem. The legacy design provides simple unified interface to classlib, while your proposal seems more specific and direct for classlib API usage. 2) At least we could provide more typified [s|g]etOption() methods, which take/return primitive values instead of wrappers. At first glance int and boolean would fit all needs, am I wrong? This way, type mismatch will be found immediately during compilation. Though this would not detect optid and value type disparity... Agree. For this case, at least, we could use booleanValue for Boolean and intValue for Integer. :) -- Regards, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
Re: [jira] Created: (HARMONY-1295) [classlib][net] flaw in setReuseAddrAndReusePort()
Andrew Zhang wrote: On 8/29/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/8/29, Andrew Zhang [EMAIL PROTECTED]: On 8/28/06, Alexey Varlamov (JIRA) [EMAIL PROTECTED] wrote: [classlib][net] flaw in setReuseAddrAndReusePort() -- Key: HARMONY-1295 URL: http://issues.apache.org/jira/browse/HARMONY-1295 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Varlamov Priority: Critical The tests.api.java.net.DatagramSocketTest test crashes on assert in DRLVM : Assertion `IsInstanceOf(env, obj, struct_Class_to_jclass(f-get_class()))' failed. The reason is that java.net.DatagramSocket.setReuseAddress(boolean) calls to PlainDatagramSocketImpl.setOption(int optID, Object val) with Boolean value, but underlying native code treats this value as Integer. Quickfix must be straightforward enough, but I inclined to blame the design of INetworkSystem.[set|get]SocketOption() as the actual root of the evil. The problem is that this API conceals the details of contract for particular options, and a client have to guess which type of value to pass. I think it's determine, not guess. :) And the implementation is basically an ugly switch sorting requests out to setBoolSocketOption() or setIntegerSocketOption(), etc. Shouldn'te refactor this? Any proposals? Thanks! Of course, lots of them ;). Just to start: 1) Why at all we clone underlying OS interface to Java with extra mapping JAVASOCKOPT_* to HY_SO_*? Totally agree with you. :) Current two option lists are duplicated. I think we'd better use one type defination. Let's have a clean API with specialized methods as XXXSocket classes have: setTTL(int) , isReuseAddress() etc. It's a design problem. The legacy design provides simple unified interface to classlib, while your proposal seems more specific and direct for classlib API usage. 2) At least we could provide more typified [s|g]etOption() methods, which take/return primitive values instead of wrappers. At first glance int and boolean would fit all needs, am I wrong? This way, type mismatch will be found immediately during compilation. Though this would not detect optid and value type disparity... Agree. For this case, at least, we could use booleanValue for Boolean and intValue for Integer. :) Interesting, deep look into code, I find JNI use pointer as the field ID, so field-ID of value in Boolean is the same as the one of Integer. In this way the code can get a value field of Integer out of a Boolean (C pointer is great! :) ). IMO, this is a mis-use but cause no error until a strict check is taken. :) This is a bug of native code, I agree we should use booleanValue instead of intValue, may we raise a JIRA and fix? -- Regards, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] A problem about behavior of EnumMap
On 8/28/06, Spark Shen wrote:
Hi All:
When I develop EnumMap,I find EnumMap strange on RI. As the following
code describes, the method entrySet() of
EnumMap returns a set view of mappings contained in this map. Then we
get the set's iterator and use the iterator's next() method to get an
Entry which contains one mapping. But if we use next() method again to
get another Entry, the previous Entry will also point to the next Entry.
import java.util.EnumMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import junit.framework.TestCase;
public class EnumMapTest extends TestCase{
enum Size {
Small, Middle, Big {
};
}
public void test_entrySet() {
EnumMap enumSizeMap = new EnumMap(Size.class);
enumSizeMap.put(Size.Middle, 1);
enumSizeMap.put(Size.Big, null);
Set set = enumSizeMap.entrySet();
Iterator iter = set.iterator();
Map.Entry entry = (Map.Entry) iter.next();
assertEquals(Size.Middle, entry.getKey());
Map.Entry entry1 = (Map.Entry) iter.next();
assertEquals(Size.Big, entry.getKey());
assertSame(entry,entry1);
}
}
I guess on RI, the returned iterator maintains a reference to current
entry and returns this reference in iter.next() method.
I do not think RI's behavior makes sense here. So I suggest not to
follow RI on the behavior.
I agree. RI behavior looks confusing.
Thanks,
Stepan Mishura
Intel Middleware Products Division
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1295) [classlib][net] flaw in setReuseAddrAndReusePort()
Jimmy, Jing Lv wrote: Andrew Zhang wrote: On 8/29/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/8/29, Andrew Zhang [EMAIL PROTECTED]: On 8/28/06, Alexey Varlamov (JIRA) [EMAIL PROTECTED] wrote: [classlib][net] flaw in setReuseAddrAndReusePort() -- Key: HARMONY-1295 URL: http://issues.apache.org/jira/browse/HARMONY-1295 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Varlamov Priority: Critical The tests.api.java.net.DatagramSocketTest test crashes on assert in DRLVM : Assertion `IsInstanceOf(env, obj, struct_Class_to_jclass(f-get_class()))' failed. The reason is that java.net.DatagramSocket.setReuseAddress(boolean) calls to PlainDatagramSocketImpl.setOption(int optID, Object val) with Boolean value, but underlying native code treats this value as Integer. Quickfix must be straightforward enough, but I inclined to blame the design of INetworkSystem.[set|get]SocketOption() as the actual root of the evil. The problem is that this API conceals the details of contract for particular options, and a client have to guess which type of value to pass. I think it's determine, not guess. :) And the implementation is basically an ugly switch sorting requests out to setBoolSocketOption() or setIntegerSocketOption(), etc. Shouldn'te refactor this? Any proposals? Thanks! Of course, lots of them ;). Just to start: 1) Why at all we clone underlying OS interface to Java with extra mapping JAVASOCKOPT_* to HY_SO_*? Totally agree with you. :) Current two option lists are duplicated. I think we'd better use one type defination. Let's have a clean API with specialized methods as XXXSocket classes have: setTTL(int) , isReuseAddress() etc. It's a design problem. The legacy design provides simple unified interface to classlib, while your proposal seems more specific and direct for classlib API usage. 2) At least we could provide more typified [s|g]etOption() methods, which take/return primitive values instead of wrappers. At first glance int and boolean would fit all needs, am I wrong? This way, type mismatch will be found immediately during compilation. Though this would not detect optid and value type disparity... Agree. For this case, at least, we could use booleanValue for Boolean and intValue for Integer. :) Interesting, deep look into code, I find JNI use pointer as the field ID, so field-ID of value in Boolean is the same as the one of Integer. In this way the code can get a value field of Integer out of a Boolean (C pointer is great! :) ). IMO, this is a mis-use but cause no error until a strict check is taken. :) This is a bug of native code, I agree we should use booleanValue instead of intValue, may we raise a JIRA and fix? Just go ahead and provide a patch for HARMONY-1295 to get this error fixed, and go on discussing the design issue, I agree that there are some things better to be improved. -- Regards, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] A problem about behavior of EnumMap
Spark Shen wrote:
Hi All:
When I develop EnumMap,I find EnumMap strange on RI. As the following
code describes, the method entrySet() of EnumMap returns a set view of
mappings contained in this map. Then we get the set's iterator and use
the iterator's next() method to get an Entry which contains one
mapping. But if we use next() method again to get another Entry, the
previous Entry will also point to the next Entry.
import java.util.EnumMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import junit.framework.TestCase;
public class EnumMapTest extends TestCase{
enum Size {
Small, Middle, Big {
};
}
public void test_entrySet() {
EnumMap enumSizeMap = new EnumMap(Size.class);
enumSizeMap.put(Size.Middle, 1);
enumSizeMap.put(Size.Big, null);
Set set = enumSizeMap.entrySet();
Iterator iter = set.iterator();
Map.Entry entry = (Map.Entry) iter.next();
assertEquals(Size.Middle, entry.getKey());
Map.Entry entry1 = (Map.Entry) iter.next();
assertEquals(Size.Big, entry.getKey());
assertSame(entry,entry1);
}
}
I guess on RI, the returned iterator maintains a reference to current
entry and returns this reference in iter.next() method.
I do not think RI's behavior makes sense here. So I suggest not to
follow RI on the behavior.
+1 from me.
Best regards
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][sql] Another confusing behavior: java.sql.Timestamp
Hello All,
RI's java.sql.Timestamp(long time) behaves confusing when the
parameter time is in Long.MIN_VALUE. Shall we follow RI?
Output of the following sample is:
time: -9223372036854775808
time: 9223372036854775192
timestamp: 292278994-08-17 15:12:55.192
timestamp: 292278994-08-17 15:12:55.192
=
import java.sql.Timestamp;
public class TimeStampTest {
public static void main(String[] args) {
long time = Long.MIN_VALUE;
long time2 = 9223372036854775192l;
Timestamp timestamp = new Timestamp(time);
Timestamp timestamp2 = new Timestamp(time2);
System.out.println(time: + time);
System.out.println(time: + time2);
System.out.println(timestamp: + timestamp);
System.out.println(timestamp: + timestamp2);
}
}
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to use the jet?
Hi, Egor, It now works. It doesn`t work first because I add the printf as follows: #if defined(_DEBUG) || defined(JIT_STATS) || defined(JIT_LOGS) fprintf(stdout, ); #endif And the default cfg for jitrino is: release. So the _DEBUG is not defined. So I modified the $ANT_COMMAND -f ./make/build.xml -Dvm.jitrino.cfg=debug $@ || ERROR in build.sh. I have to do this because I want to get more trace from JET. Then I build the drlvm again, but this time error happens in compiling it: [cc] `.L1249' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o [cc] `.L1234' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o [cc] `.L1248' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o [cc] `.L1235' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o [cc] `.L1236' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o [cc] `.L1237' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o [cc] `.L1247' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o [cc] `.L251' referenced in section `.rodata' of ../_obj/trace.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino3Jet8Compiler5fetchEjRNS0_5JInstE' of ../_obj/trace.o [cc] `.L250' referenced in section `.rodata' of ../_obj/trace.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino3Jet8Compiler5fetchEjRNS0_5JInstE' of ../_obj/trace.o [cc] `.L258' referenced in section `.rodata' of ../_obj/trace.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino3Jet8Compiler5fetchEjRNS0_5JInstE' of ../_obj/trace.o [cc] `.L259' referenced in section `.rodata' of ../_obj/trace.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino3Jet8Compiler5fetchEjRNS0_5JInstE' of ../_obj/trace.o [cc] `.L262' referenced in section `.rodata' of ../_obj/trace.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino3Jet8Compiler5fetchEjRNS0_5JInstE' of ../_obj/trace.o [cc] `.L265' referenced in section `.rodata' of ../_obj/trace.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino3Jet8Compiler5fetchEjRNS0_5JInstE' of ../_obj/trace.o [cc] collect2: ld returned 1 exit status The compile i use is gcc-3.4.6, gcc-3.3.4, both have errors happening. Can you help me to find it out. Thanks
Re: [DRLVM][GC] proposal: tools to help verify all live references are properly enumerated
Weldon, I think there are two different tasks: 1. We need to make sure that GC doesn't break heap consistency. 2. We need to detect wrong / unreported roots from JIT/VM. First task is solved by HARMONY-881. Second task can be addressed with your proposal. The point is, that java stack can contain some garbage (slots which will never be used), this can complicate this task. I have used different approach to locate second problem: Most likely unreported roots leads to crash or at least unexpected behaviour of program. I have written special GC (customized the HARMONY-1269) which moves all objects after garbage collection to new area. Old area is marked as inaccessible (hardware protection: pages has neither read nor write permission). Failing program can be started with the GC implementation and the exact place with outdated root can be identified. -- Ivan On 8/29/06, Weldon Washburn [EMAIL PROTECTED] wrote: One of the harder GC debugging problems is verifying that all live references are indeed reported to the GC. In other words, verify the stuff that happens outside the GC that impacts the GC. This actually complements verifying that GC internals are functioning correctly. Both are important for building a product quality JVM. Perhaps it makes sense to build the following tool for Harmony: Build a stack scanner that scans a given Java thread and compares each 4-byte slot to see if it can be interpreted as a ref ptr into the java heap. Put the scan results in a list. The locations that match what the JIT reports are removed from this list. The assumption is that two independent approaches to identifying live references is most likely correct. The remaining (hopefully few) items on the list can be manually inspected by JIT and VM developers to determine if somehow a live reference was actually overlooked. The above approach can be refined. More powerful filters can be constructed to reduce the clutter of false positives. It may even be possible to run the JVM in debug mode that will do an assert(0); if it sees suspicious bit patterns in the stack. Thoughts? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Sun compiler change?
2006/8/29, Spark Shen [EMAIL PROTECTED]: Alexey Varlamov 写道: 2006/8/29, Spark Shen [EMAIL PROTECTED]: Krzysztof Sobolewski 写道: Spark Shen wrote: Did you (refer to thread [app] ant with ecj) put Eclipse compiler JAR on Ant's execution classpath to execute the javac task. If so, may be that's why It always gives you unchecked cast warning, no errors. Well, I created a new EnumSet class in completly unrelated environment... So it is perfectly possible that there's a classpath conflict somewhere. I can't verify that because don't have the Harmony build here :) BTW: another experiment revealed that EnumSet? extends EnumE set = (EnumSet? extends EnumE)collection; compiles without warnings. No matter how much I think I understand generics, there's always something that surprises me ;) Conceptually speaking, I think EnumSet? extends EnumE still has potential pitfall: In the signature of addAll(Collection? extends E collection) method, ? denotes subclass of E. While in EnumSet? extends EnumE, ? denotes subclass of EnumE. But consider the relationship between E and EnumE, E is subclass of EnumE. So, we can not guarantee that subclass of E is definitely subclass of EnumE. Hmm, as E is a subclass of EnumE, subclasses of E definitely have EnumE among ancestors ;) Yes, you are right. And I made a wrong judgement here. :-P The actual statement I want to judge is that: E is subclass of EnumE. So, we can not guarantee that subclasses of E(? extends E) is definitely compatible with subclasses of EnumE(? extends EnumE). Since the input collection is of type ? extends E, cast it to ? extends EnumE seems suspicious. Nothing suspicious actually - the cast just lifts upper bound up. Taking into account cyclic declaration of E, the bound in fact remains the same. So I believe this is correct way in this particular case. -- Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1295) [classlib][net] flaw in setReuseAddrAndReusePort()
[snip] Interesting, deep look into code, I find JNI use pointer as the field ID, so field-ID of value in Boolean is the same as the one of Integer. In this way the code can get a value field of Integer out of a Boolean (C pointer is great! :) ). IMO, this is a mis-use but cause no error until a strict check is taken. :) Yes, this appears to be an (unwritten) standard de-facto. DRLVM also uses fieldIDs to unwrap boxed values, and would silently bear with such misuse in release mode. This is a bug of native code, I agree we should use booleanValue instead of intValue, may we raise a JIRA and fix? JIRA is already there, feel free to attach a patch :) We could apply a quickfix and continue with design discussion without closing the JIRA. -- Alexey -- Regards, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [kernel][reflect] Should we copy bug of RI JVM ?
I've created HARMONY-1309 to track this issue. -- WBR, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to use the jet?
On the 0x1D4 day of Apache Harmony jingxia xing wrote: Hi, Egor, It now works. It doesn`t work first because I add the printf as follows: #if defined(_DEBUG) || defined(JIT_STATS) || defined(JIT_LOGS) fprintf(stdout, ); #endif And the default cfg for jitrino is: release. So the _DEBUG is not defined. So I modified the $ANT_COMMAND -f ./make/build.xml -Dvm.jitrino.cfg=debug $@ || ERROR in build.sh. I have to do this because I want to get more trace from JET. Then I build the drlvm again, but this time error happens in compiling it: defined in discarded section [snip] `.gnu.linkonce.t._ZN7Jitrino3Jet8Compiler5fetchEjRNS0_5JInstE' of ../_obj/trace.o [cc] `.L265' referenced in section `.rodata' of ../_obj/trace.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino3Jet8Compiler5fetchEjRNS0_5JInstE' of ../_obj/trace.o [cc] collect2: ld returned 1 exit status The compile i use is gcc-3.4.6, gcc-3.3.4, both have errors happening. Can you help me to find it out. Thanks try ./build.sh clean maybe, it helps... Also look at what Weldon did to enable debug mode in Jitrino (windoze): http://article.gmane.org/gmane.comp.java.harmony.devel/10181 I use a variation of this patch. We should finish these changes into a complete patch, check if pre-commit tests pass, and apply it. -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][sql] Another confusing behavior: java.sql.Timestamp
Hello,
I don't think we should bother about single value which is very
unlikely to happpen in real data.
On 8/29/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello All,
RI's java.sql.Timestamp(long time) behaves confusing when the
parameter time is in Long.MIN_VALUE. Shall we follow RI?
Output of the following sample is:
time: -9223372036854775808
time: 9223372036854775192
timestamp: 292278994-08-17 15:12:55.192
timestamp: 292278994-08-17 15:12:55.192
=
import java.sql.Timestamp;
public class TimeStampTest {
public static void main(String[] args) {
long time = Long.MIN_VALUE;
long time2 = 9223372036854775192l;
Timestamp timestamp = new Timestamp(time);
Timestamp timestamp2 = new Timestamp(time2);
System.out.println(time: + time);
System.out.println(time: + time2);
System.out.println(timestamp: + timestamp);
System.out.println(timestamp: + timestamp2);
}
}
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to use the jet?
Yeah, Weldon`s way works. Thanks! 29 Aug 2006 17:26:35 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1D4 day of Apache Harmony jingxia xing wrote: Hi, Egor, It now works. It doesn`t work first because I add the printf as follows: #if defined(_DEBUG) || defined(JIT_STATS) || defined(JIT_LOGS) fprintf(stdout, ); #endif And the default cfg for jitrino is: release. So the _DEBUG is not defined. So I modified the $ANT_COMMAND -f ./make/build.xml -Dvm.jitrino.cfg=debug $@ || ERROR in build.sh. I have to do this because I want to get more trace from JET. Then I build the drlvm again, but this time error happens in compiling it: defined in discarded section [snip] `.gnu.linkonce.t._ZN7Jitrino3Jet8Compiler5fetchEjRNS0_5JInstE' of ../_obj/trace.o [cc] `.L265' referenced in section `.rodata' of ../_obj/trace.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino3Jet8Compiler5fetchEjRNS0_5JInstE' of ../_obj/trace.o [cc] collect2: ld returned 1 exit status The compile i use is gcc-3.4.6, gcc-3.3.4, both have errors happening. Can you help me to find it out. Thanks try ./build.sh clean maybe, it helps... Also look at what Weldon did to enable debug mode in Jitrino (windoze): http://article.gmane.org/gmane.comp.java.harmony.devel/10181 I use a variation of this patch. We should finish these changes into a complete patch, check if pre-commit tests pass, and apply it. -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] HARMONY-790 is not reproducible
On 28 August 2006 at 16:14, Denis Kishenko [EMAIL PROTECTED] wrote: 2006/8/25, Mark Hindess [EMAIL PROTECTED]: Thanks for helping by looking at these. If you spot others and send messages and/or add comments in JIRA I'll take a look at them. Mark There are a lot of unassigned issues with patches in JIRA. For example most of issues listed bellow were created more then two weeks ago. http://issues.apache.org/jira/browse/HARMONY-1070 http://issues.apache.org/jira/browse/HARMONY-1118 http://issues.apache.org/jira/browse/HARMONY-1190 http://issues.apache.org/jira/browse/HARMONY-1131 http://issues.apache.org/jira/browse/HARMONY-1231 http://issues.apache.org/jira/browse/HARMONY-1168 http://issues.apache.org/jira/browse/HARMONY-1153 http://issues.apache.org/jira/browse/HARMONY-1107 http://issues.apache.org/jira/browse/HARMONY- http://issues.apache.org/jira/browse/HARMONY-1175 http://issues.apache.org/jira/browse/HARMONY-1244 Some of these are fixes without regression test patches. That might be one reason why they are overlooked. Also it helps to indicate if the bug is a blocker for running applications. Also there are several assigned but not resolved issues which have patches to o. http://issues.apache.org/jira/browse/HARMONY-1031 http://issues.apache.org/jira/browse/HARMONY-1139 http://issues.apache.org/jira/browse/HARMONY-1148 http://issues.apache.org/jira/browse/HARMONY-1081 http://issues.apache.org/jira/browse/HARMONY-1184 http://issues.apache.org/jira/browse/HARMONY-1169 I'll let the respective assignees comment on these. Could you please look at these issues? I'll try to look at those which have regression tests (at least). -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to use the jet?
On the 0x1D4 day of Apache Harmony jingxia xing wrote: Yeah, Weldon`s way works. Thanks! Great! I am s glad :) BTW, are you having some well-defined ideas what to do with Harmony JITs? -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][TestNG] groups of Harmony test
I think we can treat something like *os.any*,*type.api* as default
groups.Itwill make our logic more clear and bring convenience to
testcase writing :)
for example, an os.platformid group indicates that it is designed for
paltformid only. If there is no group like os.platformid here, this is a
*os.any* test.
so if we want to run all *api* tests on *win32* platform which is *not
broken*, we could write the testng.xml like this:
groups
run
include name=.* /
exclude name=type.impl /
exclude name=os\.(?!win\.IA32).* /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
2006/8/29, Vladimir Ivanov [EMAIL PROTECTED]:
Also some tag for regression tests should be added.
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for MacOS,
instead of list 9 os.platform id, we can just use state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification of
the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name= state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello All,
I'm sorry. It seems that the example does not work. I will try to figure
another example soon. ;-)
Best regards,
Richard
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG to add a
new option -groups for its JUnitConverter which allow us to specify
the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments
or suggestion. ;-)
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Tony Wu
China Software Development Lab, IBM
Re: how to use the jet?
I want to profile some memory access patterns, and try to find out which are the most hot ones. BTW, I find that I undefine MACRO USE_FAST_PATH, it will happen with assert errors (just a HelloWorld application)? Does it mean that JET must be first used to get some profile information? 29 Aug 2006 21:07:48 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1D4 day of Apache Harmony jingxia xing wrote: Yeah, Weldon`s way works. Thanks! Great! I am s glad :) BTW, are you having some well-defined ideas what to do with Harmony JITs? -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] A problem about behavior of EnumMap
I found all of the previous entrys will be set to current one while
iter.next() was invoked. so I guess there is just the same instance returned
by iter.next() with variable modifications.
It is a bug if not a trade-off for performance I think.
On 8/28/06, Spark Shen [EMAIL PROTECTED] wrote:
Hi All:
When I develop EnumMap,I find EnumMap strange on RI. As the following
code describes, the method entrySet() of
EnumMap returns a set view of mappings contained in this map. Then we
get the set's iterator and use the iterator's next() method to get an
Entry which contains one mapping. But if we use next() method again to
get another Entry, the previous Entry will also point to the next Entry.
import java.util.EnumMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import junit.framework.TestCase;
public class EnumMapTest extends TestCase{
enum Size {
Small, Middle, Big {
};
}
public void test_entrySet() {
EnumMap enumSizeMap = new EnumMap(Size.class);
enumSizeMap.put(Size.Middle, 1);
enumSizeMap.put(Size.Big, null);
Set set = enumSizeMap.entrySet();
Iterator iter = set.iterator();
Map.Entry entry = (Map.Entry) iter.next();
assertEquals(Size.Middle, entry.getKey());
Map.Entry entry1 = (Map.Entry) iter.next();
assertEquals(Size.Big, entry.getKey());
assertSame(entry,entry1);
}
}
I guess on RI, the returned iterator maintains a reference to current
entry and returns this reference in iter.next() method.
I do not think RI's behavior makes sense here. So I suggest not to
follow RI on the behavior.
Best regards
--
Spark Shen
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Tony Wu
China Software Development Lab, IBM
Re: [app] xmlbeans
I verified that this issue appears to be fixed for xmlbeans with r438202 of the classlib trunk. Thanks again Richard. On 8/28/06, Paulex Yang [EMAIL PROTECTED] wrote: HARMONY-1293 has been resolved at r437626, thank Richard to provide patch. Would anyone help to check the status of xmlbeans with Harmony now? Jordan Justen wrote: Thanks Richard! On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote: Richard Liang wrote: Nathan Beyer wrote: I take it that means the issue is pretty obvious (very easy to recreate). Can you tell us what you did to recreate it and what class in Harmony is at issue? It seems a bug of java.util.ArrayList. I will attach a patch to fix it. I have raised a JIRA HARMONY-1293[1] for this issue with patch attached. :-) [1] https://issues.apache.org/jira/browse/HARMONY-1293 Richard. Best regards, Richard -Nathan -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Sunday, August 27, 2006 10:36 PM To: harmony-dev@incubator.apache.org Subject: Re: [app] xmlbeans I reproduce the same error on xmlbeans-2.2.0. Jordan Justen wrote: Well, I don't have much details, but here's the stack trace. I figured it wouldn't be to helpful for the list. I don't see this exception with the sun jvm/classes. Anyway, I'll try debug it some... [java] java.lang.NullPointerException [java] at org.apache.xmlbeans.impl.common.NameUtil.splitWords ( NameUtil.java:667) [java] at org.apache.xmlbeans.impl.common.NameUtil.lowerCamelCase( NameUtil.java:623) [java] at org.apache.xmlbeans.impl.common.NameUtil.getPackageFromNamespace( NameUtil.java:513) [java] at org.apache.xmlbeans.impl.common.NameUtil.getClassNameFromQName( NameUtil.ja va :328) [java] at org.apache.xmlbeans.impl.common.NameUtil.getClassNameFromQName( NameUtil.ja va :318) [java] at org.apache.xmlbeans.impl.schema.StscJavaizer.pickFullJavaClassName ( StscJavaizer.java:679) [java] at org.apache.xmlbeans.impl.schema.StscJavaizer.assignGlobalJavaNames ( StscJavaizer.java:91) [java] at org.apache.xmlbeans.impl.schema.StscJavaizer.javaizeAllTypes( StscJavaizer.java:55) [java] at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compileImpl( SchemaTypeSystemCompiler.java:313) [java] at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile( SchemaTypeSystemCompiler.java:181) [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.loadTypeSystem( SchemaCompiler.java:952) [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.compile( SchemaCompiler.java:1072) [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.main( SchemaCompiler.java:368) On 8/27/06, Nathan Beyer [EMAIL PROTECTED] wrote: Is there a particular issue that you've run into? -Original Message- From: Jordan Justen [mailto:[EMAIL PROTECTED] Sent: Sunday, August 27, 2006 7:10 PM To: harmony-dev@incubator.apache.org Subject: [app] xmlbeans Has anyone successfully used harmony with xmlbeans ( http://xmlbeans.apache.org/)? Or, does anyone know of any major reasons why it would not be working at this time? I tried it without luck. I'll debug the error if no one knows of any major roadblocks that I'd encounter. Thanks, -Jordan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] A problem about behavior of EnumMap
Spark Shen 写道:
I guess on RI, the returned iterator maintains a reference to current
entry and returns this reference in iter.next() method.
I do not think RI's behavior makes sense here. So I suggest not to
follow RI on the behavior.
I want to adopt the behavior described below because it seems more
reasonable.
The previous Entry should not point to the next Entry when the
iterator's next() is invoked. And then the methods of the Class Entry,
such as getKey(), getValue() ,setValue() etc,
will act on the different objects.
Based on my implement,I expect the following test cases pass on
Harmony.(Some of them will fail on RI.)
enum Size {
Small, Middle, Big {
};
}
public void test_entrySet() {
EnumMap enumSizeMap = new EnumMap(Size.class);
enumSizeMap.put(Size.Middle, 1);
enumSizeMap.put(Size.Big, null);
Set set = enumSizeMap.entrySet();
Iterator iter = set.iterator();
Map.Entry entry1 = (Map.Entry) iter.next();
Map.Entry entry2 = (Map.Entry) iter.next();
assertEquals(Size.Middle, entry1.getKey());
assertEquals(1, entry1.getValue());
enumSizeMap.remove(Size.Middle);
try {
entry1.setValue(0);
fail(Should throw IllegalStateException); //$NON-NLS-1$
} catch (IllegalStateException e) {
// Expected
}
assertEquals(1, set.size());
entry2.setValue(2);
assertEquals(Size.Big, entry2.getKey());
assertEquals(2, entry2.getValue());
}
Best regards
--
Spark Shen
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
Ilya Okomin wrote: Tim, great news for me. Everything looks fine with the patch you've applied, now it's time for the main part of the task. I've created HARMONY-1308 issue with task description. This issue is devided into a set of sub-issues for each module. I'm going to process them one by one. These issues can be processed in a parallel way, so everyone is welcomed to take part in the internationalization process :) Hi, Ilya, I'd like to process instrument :) Can you tell me something about the generation tool, or how can we process these strings? Is there anything to take care of? And in fact, in java.lang.instrument, there are some error messages in native code(AFAIK, there are also many in luni). Is there any tool to find them out automatic ? Thanks, Ilya. On 8/29/06, Tim Ellison [EMAIL PROTECTED] wrote: Thanks for waiting Ilya, I've applied the final patch on HARMONY-1201 (I'll check-in the tool when I get back from vacation). So now we can get to work on breaking out the messages into each component's message file. Regards, Tim Ilya Okomin wrote: On 8/11/06, Tim Ellison [EMAIL PROTECTED] wrote: I took a look at the HARMONY-1041 tool. It is fine, I have only minor comments: - do you think we need to separate the Message and MsgUtil types? Given that they are generated from a template I'd be inclined to combine them into a single type now. We have no need to look in that file in general. If you do choose to combine them then I would expect the resulting header to be (c) 1998, 2006. - Minor typo Better make changes in the teamplate file. - template. Ilya Okomin wrote: I would suggest to split this task into a set of jira sub-issues, one module - one issue. This kind of division would give us an opportunity this work to be done in a parallel mode. Agreed. I suggest that we run the msgtool on the existing modules and commit the generated code and catalog files, then the incoming patches can assume they are there and use them to fix the externalization. Hello, Tim! I've made changes to the generation tool [1] and also prepared patch with the set of generated files according to the existing modules set I've raised issue for that [2]. Not all modules were included into the generation (full set can be found in comments to the [2]). E.g. x-net module has package xnet, also I'm not sure about necessity to make internationalization in suncompat or rmi2, etc. You can check list of suggested modules and if something is missed I'll make update. Waiting for your comments and proposals! [1]http://issues.apache.org/jira/browse/HARMONY-1041 [2]http://issues.apache.org/jira/browse/HARMONY-1201 Regards, Ilya. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to use the jet?
On the 0x1D4 day of Apache Harmony jingxia xing wrote: I want to profile some memory access patterns, and try to find out which are the most hot ones. Sounds interesting! BTW, I find that I undefine MACRO USE_FAST_PATH, it will happen with assert errors (just a HelloWorld application)? Does it mean that JET must be first used to get some profile information? Yes, exactly. Currently, JET provides entry-backedge profile that is used by OPT. AFAIR, generating profile in OPT is disabled now, but it is the subject to change soon :) I did NOT try to undef USE_FAST_PATH, and this is not what is supposed to be done. We have 'Execution Manager' that decides which JIT to use on a method and in which mode (profile-generating, profile-consuming or no-profile). Try to run VM with options: -Xem opt They tell EM to disable JET. AFAIR, there is no profiling in this mode today. Execution manager can be configured via a simple rule-based config file. Feel free to ask questions on it. BTW, Mikhail Fursov is a great expert of EM. -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][TestNG] groups of Harmony test
Tony Wu wrote:
I think we can treat something like *os.any*,*type.api* as default
groups.Itwill make our logic more clear and bring convenience to
testcase writing :)
for example, an os.platformid group indicates that it is designed for
paltformid only. If there is no group like os.platformid here,
this is a
*os.any* test.
so if we want to run all *api* tests on *win32* platform which is *not
broken*, we could write the testng.xml like this:
groups
run
include name=.* /
exclude name=type.impl /
exclude name=os\.(?!win\.IA32).* /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello Tony,
It's a good idea. However, we shall define a default group which means
os.any, type.impl, level.unit. Thanks a lot.
Best regards,
Richard
2006/8/29, Vladimir Ivanov [EMAIL PROTECTED]:
Also some tag for regression tests should be added.
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the groups.
e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform,
because
of bugs of tests or implementation. We need to fix the bugs of tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups.
e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a
convenient way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for
MacOS,
instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the
verification of
the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name= state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello All,
I'm sorry. It seems that the example does not work. I will try to
figure
another example soon. ;-)
Best regards,
Richard
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG to
add a
new option -groups for its JUnitConverter which allow us to
specify
the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your
comments
or suggestion. ;-)
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][TestNG] groups of Harmony test
Richard Liang wrote:
Tony Wu wrote:
I think we can treat something like *os.any*,*type.api* as default
groups.Itwill make our logic more clear and bring convenience to
testcase writing :)
for example, an os.platformid group indicates that it is designed for
paltformid only. If there is no group like os.platformid here,
this is a
*os.any* test.
so if we want to run all *api* tests on *win32* platform which is *not
broken*, we could write the testng.xml like this:
groups
run
include name=.* /
exclude name=type.impl /
exclude name=os\.(?!win\.IA32).* /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello Tony,
It's a good idea. However, we shall define a default group which
means os.any, type.impl, level.unit. Thanks a lot.
And even the default group is not necessary by removing the include
name=.* /
groups
run
exclude name=type.impl /
exclude name=os\.(?!win\.IA32).* /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Richard
Best regards,
Richard
2006/8/29, Vladimir Ivanov [EMAIL PROTECTED]:
Also some tag for regression tests should be added.
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei
Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the groups.
e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform,
because
of bugs of tests or implementation. We need to fix the bugs of
tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on
one
specific platform. A test may be in more than one of the groups.
e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a
convenient way
to indicate that a test is platform-specific. e.g., If we
support 10
platforms, and one test are designed for 9 platforms except for
MacOS,
instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the
verification of
the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name= state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello All,
I'm sorry. It seems that the example does not work. I will try to
figure
another example soon. ;-)
Best regards,
Richard
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG to
add a
new option -groups for its JUnitConverter which allow us to
specify
the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your
comments
or suggestion. ;-)
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use :
Re: [classlib][luni] A problem about behavior of EnumMap
Spark Shen wrote:
Spark Shen 写道:
I guess on RI, the returned iterator maintains a reference to current
entry and returns this reference in iter.next() method.
I do not think RI's behavior makes sense here. So I suggest not to
follow RI on the behavior.
I want to adopt the behavior described below because it seems more
reasonable.
The previous Entry should not point to the next Entry when the
iterator's next() is invoked. And then the methods of the Class Entry,
such as getKey(), getValue() ,setValue() etc,
will act on the different objects.
Based on my implement,I expect the following test cases pass on
Harmony.(Some of them will fail on RI.)
enum Size {
Small, Middle, Big {
};
}
public void test_entrySet() {
EnumMap enumSizeMap = new EnumMap(Size.class);
enumSizeMap.put(Size.Middle, 1);
enumSizeMap.put(Size.Big, null);
Set set = enumSizeMap.entrySet();
Iterator iter = set.iterator();
Map.Entry entry1 = (Map.Entry) iter.next();
Map.Entry entry2 = (Map.Entry) iter.next();
assertEquals(Size.Middle, entry1.getKey());
assertEquals(1, entry1.getValue());
enumSizeMap.remove(Size.Middle);
try {
entry1.setValue(0);
fail(Should throw IllegalStateException); //$NON-NLS-1$
} catch (IllegalStateException e) {
// Expected
}
assertEquals(1, set.size());
entry2.setValue(2);
assertEquals(Size.Big, entry2.getKey());
assertEquals(2, entry2.getValue());
}
Sounds reasonable, what's RI's behavior on the entries
getKey()/getValue()/setValue() then (i.e., which asserts fails on RI)?
Best regards
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][TestNG] groups of Harmony test
Vladimir Ivanov wrote:
Also some tag for regression tests should be added.
Yes. Do you think we could annotate regression test as
*level.regression*? Thanks a lot.
Richard
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for MacOS,
instead of list 9 os.platform id, we can just use state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification of
the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name= state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello All,
I'm sorry. It seems that the example does not work. I will try to figure
another example soon. ;-)
Best regards,
Richard
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG to add a
new option -groups for its JUnitConverter which allow us to specify
the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments
or suggestion. ;-)
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][TestNG] groups of Harmony test
Paulex Yang wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the groups.
e.g., @Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
I suggest to separate the CPU arch with OS, they are actually
different things, and we probably will have tests written for all
64bits arch, or for all Linux OS.
Thanks a lot, Paulex. I agree. Separating os and arch make our groups
more flexible. I will update the grouping proposal soon to integrate
your and others' suggestion.
Best regards,
Richard
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups.
e.g., @Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient
way to indicate that a test is platform-specific. e.g., If we support
10 platforms, and one test are designed for 9 platforms except for
MacOS, instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api, type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
complexity as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification
of the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG to add
a new option -groups for its JUnitConverter which allow us to
specify the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments
or suggestion. ;-)
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][logging]yet another non-bug difference with RI(Re: [jira] Created: (HARMONY-1300) [classlib][logging] XMLFormatter.format returns a String contains message/ while RI doesn't when log m
From the DTD for j.u.logging.XMLFormatter[1], message is required by
record, so I consider this is RI's bug, and I suggest to follow spec in
this case, because it is hard to believe this difference with RI will
make application fail, while there is possibilities for some
applications to validate logging record using the DTD, it may fail on
RI. If no one objects, I will mark this issue as non-bug difference
with RI.
[1]
...
!-- Each logging call is described by a record element. --
!ELEMENT record (date, millis, sequence, logger?, level,class?,
method?, thread?, message, key?, catalog?, param*, exception?)
...
Andrew Zhang (JIRA) wrote:
[classlib][logging] XMLFormatter.format returns a String contains message/ while RI doesn't when log message and pattern is null.
---
Key: HARMONY-1300
URL: http://issues.apache.org/jira/browse/HARMONY-1300
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Andrew Zhang
Following test reproduces the bug:
public void test_format() {
formatter = new XMLFormatter();
LogRecord lr = new LogRecord(Level.SEVERE, null);
String output = formatter.format(lr);
assertFalse(output.indexOf(message) 0);
}
The test passes against RI while fails against Harmony.
I'll upload a patch to fix this problem soon.
Best regards,
Andrew
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][logging]yet another non-bug difference with RI(Re: [jira] Created: (HARMONY-1300) [classlib][logging] XMLFormatter.format returns a String contains message/ while RI doesn't when lo
agreed
Paulex Yang wrote:
From the DTD for j.u.logging.XMLFormatter[1], message is required by
record, so I consider this is RI's bug, and I suggest to follow spec in
this case, because it is hard to believe this difference with RI will
make application fail, while there is possibilities for some
applications to validate logging record using the DTD, it may fail on
RI. If no one objects, I will mark this issue as non-bug difference
with RI.
[1]
...
!-- Each logging call is described by a record element. --
!ELEMENT record (date, millis, sequence, logger?, level,class?,
method?, thread?, message, key?, catalog?, param*, exception?)
...
Andrew Zhang (JIRA) wrote:
[classlib][logging] XMLFormatter.format returns a String contains
message/ while RI doesn't when log message and pattern is null.
---
Key: HARMONY-1300
URL: http://issues.apache.org/jira/browse/HARMONY-1300
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Andrew Zhang
Following test reproduces the bug:
public void test_format() {
formatter = new XMLFormatter();
LogRecord lr = new LogRecord(Level.SEVERE, null);
String output = formatter.format(lr);
assertFalse(output.indexOf(message) 0);
}
The test passes against RI while fails against Harmony.
I'll upload a patch to fix this problem soon.
Best regards,
Andrew
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][TestNG] groups of Harmony test
I'm just catching up after a few days of travel. Have you begun
sketching this out on the wiki?
geir
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related threads
which posted by George, Vladimir Ivanov and Alexei Zakharov. All of them
are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of our
tests should be in this group.
*os.platform id* - group of tests which are designed for one specific
platform. A test may be in more than one of the groups. e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is, tests
in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform, because of
bugs of tests or implementation. We need to fix the bugs of tests or
implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for MacOS,
instead of list 9 os.platform id, we can just use state.broken.MacOS
3) [Test type] type.api, type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification of
the entire system. Maybe we'll put them into a separate project. e.g.,
harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Well, I think our most of existing tests are in the groups of {os.any,
type.api, level.unit}, and I have asked TestNG to add a new option
-groups for its JUnitConverter which allow us to specify the test
groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments or
suggestion. ;-)
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] HARMONY-790 is not reproducible
Also, remember that people have to review the patch and decide that it's reasonable, not just blindly add them. That said, I'll start looking as well. geir Mark Hindess wrote: On 28 August 2006 at 16:14, Denis Kishenko [EMAIL PROTECTED] wrote: 2006/8/25, Mark Hindess [EMAIL PROTECTED]: Thanks for helping by looking at these. If you spot others and send messages and/or add comments in JIRA I'll take a look at them. Mark There are a lot of unassigned issues with patches in JIRA. For example most of issues listed bellow were created more then two weeks ago. http://issues.apache.org/jira/browse/HARMONY-1070 http://issues.apache.org/jira/browse/HARMONY-1118 http://issues.apache.org/jira/browse/HARMONY-1190 http://issues.apache.org/jira/browse/HARMONY-1131 http://issues.apache.org/jira/browse/HARMONY-1231 http://issues.apache.org/jira/browse/HARMONY-1168 http://issues.apache.org/jira/browse/HARMONY-1153 http://issues.apache.org/jira/browse/HARMONY-1107 http://issues.apache.org/jira/browse/HARMONY- http://issues.apache.org/jira/browse/HARMONY-1175 http://issues.apache.org/jira/browse/HARMONY-1244 Some of these are fixes without regression test patches. That might be one reason why they are overlooked. Also it helps to indicate if the bug is a blocker for running applications. Also there are several assigned but not resolved issues which have patches to o. http://issues.apache.org/jira/browse/HARMONY-1031 http://issues.apache.org/jira/browse/HARMONY-1139 http://issues.apache.org/jira/browse/HARMONY-1148 http://issues.apache.org/jira/browse/HARMONY-1081 http://issues.apache.org/jira/browse/HARMONY-1184 http://issues.apache.org/jira/browse/HARMONY-1169 I'll let the respective assignees comment on these. Could you please look at these issues? I'll try to look at those which have regression tests (at least). -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][sql] Another confusing behavior: java.sql.Timestamp
1) What should it do?
2) if it's just a single value, why not fix it and never have to deal w/
it again? Is it an easy fix?
geir
Anton Luht wrote:
Hello,
I don't think we should bother about single value which is very
unlikely to happpen in real data.
On 8/29/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello All,
RI's java.sql.Timestamp(long time) behaves confusing when the
parameter time is in Long.MIN_VALUE. Shall we follow RI?
Output of the following sample is:
time: -9223372036854775808
time: 9223372036854775192
timestamp: 292278994-08-17 15:12:55.192
timestamp: 292278994-08-17 15:12:55.192
=
import java.sql.Timestamp;
public class TimeStampTest {
public static void main(String[] args) {
long time = Long.MIN_VALUE;
long time2 = 9223372036854775192l;
Timestamp timestamp = new Timestamp(time);
Timestamp timestamp2 = new Timestamp(time2);
System.out.println(time: + time);
System.out.println(time: + time2);
System.out.println(timestamp: + timestamp);
System.out.println(timestamp: + timestamp2);
}
}
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][logging]yet another non-bug difference with RI(Re: [jira] Created: (HARMONY-1300) [classlib][logging] XMLFormatter.format returns a String contains message/ while RI doesn't when lo
On 8/30/06, Paulex Yang [EMAIL PROTECTED] wrote:
From the DTD for j.u.logging.XMLFormatter[1], message is required by
record, so I consider this is RI's bug, and I suggest to follow spec in
this case, because it is hard to believe this difference with RI will
make application fail, while there is possibilities for some
applications to validate logging record using the DTD, it may fail on
RI. If no one objects, I will mark this issue as non-bug difference
with RI.
Agreed.
Paulex, please don't apply harmony-1300 patch, and close it as non-bug
difference with RI.
[1]
...
!-- Each logging call is described by a record element. --
!ELEMENT record (date, millis, sequence, logger?, level,class?,
method?, thread?, message, key?, catalog?, param*, exception?)
...
Andrew Zhang (JIRA) wrote:
[classlib][logging] XMLFormatter.format returns a String contains
message/ while RI doesn't when log message and pattern is null.
---
Key: HARMONY-1300
URL: http://issues.apache.org/jira/browse/HARMONY-1300
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Andrew Zhang
Following test reproduces the bug:
public void test_format() {
formatter = new XMLFormatter();
LogRecord lr = new LogRecord(Level.SEVERE, null);
String output = formatter.format(lr);
assertFalse(output.indexOf(message) 0);
}
The test passes against RI while fails against Harmony.
I'll upload a patch to fix this problem soon.
Best regards,
Andrew
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
RE: [classlib] Sun compiler change?
-Original Message- From: Spark Shen [mailto:[EMAIL PROTECTED] Nathan Beyer 写道: There were some compiler changes according to the release notes [1]. Of particular note is this bug fix [2], which is related to a number of bugs. I think this may be it. So, I think at the moment, it is more safe to use the below pattern(different compiler implements slightly different generic feature): They shouldn't be. If this is something that should also fail to compile with Eclipse, then I would suggest logging a bug for the JDT. They'll be able to confirm the correct behavior. EnumSet set = (EnumSet)collection; and leave the warning as it is. When compiler itself is consistent with generic, these warning may remind us later. Best regards -Nathan [1] https://java.sun.com/j2se/1.5.0/ReleaseNotes.html#150_08 [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4916620 -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 6:55 PM To: harmony-dev@incubator.apache.org Subject: [classlib] Sun compiler change? Is anyone else using the latest Sun JDK, v5.0 Update 8 on Windows? I'm seeing a compilation error in the LUNI that I don't see with 5.0 Update 7. Here's the error I'm getting. compile: [mkdir] Created dir: C:\dev\harmony\enhanced\classlib\trunk\build\classes [javac] Compiling 3173 source files to C:\dev\harmony\enhanced\classlib\trun k\build\classes [javac] C:\dev\harmony\enhanced\classlib\trunk\modules\luni\src\main\java\ja va\util\MiniEnumSet.java:78: inconvertible types [javac] found : java.util.Collectioncapture of ? extends E [javac] required: java.util.EnumSetE [javac] EnumSetE set = (EnumSetE) collection; [javac] ^ When I compile in Eclipse 3.2 there's no error. -Nathan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [kernel][reflect] Should we copy bug of RI JVM ?
Vladimir Gorr wrote: On 8/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: There is a test[1] in classlib, which verifies that reflection access from enclosing class to a private member of a nested class results in IllegalAccessException. However, this is against the language specification (para 6.6.1 of the JLS3): [SNIP] I found out, this is an acknowledged bug of RI [2], and is ranked TOP#6. The good news, however, that DRLVM is free of this defect. OTOH, it surely cannot pass the aforementioned test of the classlib. So the question: should we fix the test and will IBM VME address this issue? What is appropriate JIRA category for it? I suppose this test should be modified after IBM VME will behave in accordance with the specifications if any. I agree, if IBM will fix it, if they have the problem. Certainly, if there are no any objections. IMO we should avoid any bugs known for the RI, shouldn't we? I think that we should fix this, since it's a known bug of the RI that may be fixed... I know that Alexey setup a JIRA for it, so we can revisit... geir Thanks, Vladimir. [1]testcase classname=tests.api.java.lang.reflect.FieldTest name=test_getLjava_lang_Object/ [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 -- Alexey Varlamov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][MMTk GC] marksweep configuration works in user mode
Weldon Washburn wrote: All, I just committed mods that allow MMTk marksweep configuration to run the simple tests in test.java. That's cool - what do we do with it next? :) geir There were some workarounds in MMTk code itself. It does not make sense to commit these workarounds to drlvm/trunk or to put them in JIRA. Instead, I told Steve Blackburn what the MMTk porting problems are. For the record the MMTk mods are: 1) SegregatedFreeList.java wants to use vmmagic atomic operations even in single java thread app. But vmmagic atomic ops are not fully functional in Jitrino.JET just yet. The workaround is to do a simple write to memory instead of CAS. The mods to SegregatedFreeList.java are: 731a732 atomic = false; //wjw hack around Addresss.attempt bug 2) MMType.getSlot() is hard coded to assume that element zero is an Offset of zero from the vtable ptr. While this may indeed be the case for JikesRVM, in DRLVM the offset is 12. The diff to MMType.java is: 83,86c83,86 if (isReferenceArray) return addr.plus(arrayOffset).plus(reference LOG_BYTES_IN_ADDRESS); else return addr.plus(offsets[reference]); --- if (isReferenceArray) return addr.plus(12).plus(reference LOG_BYTES_IN_ADDRESS); // return addr.plus(arrayOffset).plus(reference LOG_BYTES_IN_ADDRESS); else return addr.plus(offsets[reference]); - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][ldap] contribution of missing javax.naming.ldap 1.4 classes
Nice - thanks! But we need the documentation - the BCC, ACQs for anyone who wrote parts of it, and a CCLA for the ASF. I'm happy to discuss how to get that to me offline... geir Daniel Gandara wrote: Hi all, on http://issues.apache.org/jira/browse/HARMONY-1296 we have contributed the missing classes for v1.4 of the javax.naming.ldap package.At the ITC we are working to complete the 1.5 version of the package, in the following weeks we plan to contribute it. Within the contribution you will find a test suite for the package and a coverage analysis of it. Thanks, Daniel Gándara - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Hi,
I was browsing thought logging tests and realized that running logging test
suite cause updates of tested JRE configuration.
The ant script changes jre/lib/logging.properties file by:
target name=copy.resources
copy todir=${hy.jdk}/jre/lib overwrite=yes flatten=yes
fileset dir=${hy.logging.src.main.java}
include name=**/logging.properties /
/fileset
/copy
/target
I do believe that we shouldn't do testing in this way - if a test requires
special env. configuration(different from JRE's default) the test suite
shouldn't *hack* JRE config files. We should consider dynamic env.
reconfiguration. For example, for this particular case is there any problem
with using LogManager.readConfiguration(InputStream) to reinitialize the
logging properties?
Also keep in mind that the test suite is expected to be run against some
compatible implementation. I think nobody is going to reinstall Sun's JRE
each time after running Harmony test suite.
Thanks,
Stepan Mishura
Intel Middleware Products Division
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build-test] Re: Build-Test regular expression matcher pb
Any joy? Paulex Yang wrote: Jean, Sorry for response so late, do you still get this error? I use Sun JVM 1.5.0_06 and ant 1.6.5 on WinXP SP2, I think this env should be similar with you, but I cannot reproduce it. If you still cannot get it work, would you please raise a JIRA? Jean-frederic Clere wrote: Geir Magnusson Jr. wrote: Jean-frederic Clere wrote: Geir Magnusson Jr. wrote: (can you please prefix the subject line with something like [build-test] in the future :)) What JRE are you using? Sun JVM 1.5.0_06. Cheers Jean-Frederic And you simply checked it out, followed the directions, and it didn't work? Yes ;-( What version of ant? 1.6.5 Cheers Jean-Frederic geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][sql] Another confusing behavior: java.sql.Timestamp
Geir Magnusson Jr. wrote:
1) What should it do?
When calculating nanos value, underflow may occur if the given time is
near Long.MIN_VALUE. In fact, I'm also not sure what it should do. Just
notice that RI handles the underflow situation in a special/confusing
way, while Harmony does not have any handling.
2) if it's just a single value, why not fix it and never have to deal
w/ it again? Is it an easy fix?
Yes, the fix is quite easy. Do you mean we shall follow RI?
Thanks a lot.
Richard.
geir
Anton Luht wrote:
Hello,
I don't think we should bother about single value which is very
unlikely to happpen in real data.
On 8/29/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello All,
RI's java.sql.Timestamp(long time) behaves confusing when the
parameter time is in Long.MIN_VALUE. Shall we follow RI?
Output of the following sample is:
time: -9223372036854775808
time: 9223372036854775192
timestamp: 292278994-08-17 15:12:55.192
timestamp: 292278994-08-17 15:12:55.192
=
import java.sql.Timestamp;
public class TimeStampTest {
public static void main(String[] args) {
long time = Long.MIN_VALUE;
long time2 = 9223372036854775192l;
Timestamp timestamp = new Timestamp(time);
Timestamp timestamp2 = new Timestamp(time2);
System.out.println(time: + time);
System.out.println(time: + time2);
System.out.println(timestamp: + timestamp);
System.out.println(timestamp: + timestamp2);
}
}
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][logging] A non bug difference from RI?
Andrew Zhang wrote:
Hi folks,
When SecurityManager is enabled and all file permissions are disabled, RI
fails to new a FileHandler while Harmony allows.
Following test code shows the differences:
public void test_FileHandler() throws Exception {
FileHandler handler = new FileHandler();
SecurityManager originalSecurityManager =
System.getSecurityManager
();
try {
System.setSecurityManager(new MockFileSecurityManager());
handler.publish(new LogRecord(Level.SEVERE, msg));
// SecurityException is thrown here
handler.close();
} finally {
System.setSecurityManager(originalSecurityManager);
}
}
public static class MockFileSecurityManager extends SecurityManager {
public void checkPermission(Permission perm) {
if (perm instanceof FilePermission) {
System.out.println(check + perm.getName());
throw new SecurityException();
}
}
}
FileHandler.close() spec says Throws: SecurityException - if a security
manager exists and if the caller does not have
LoggingPermission(control)., In the code above, control permission is
allowed. The failure stack trace against RI looks like:
java.lang.SecurityException
at com.andrew.LoggingTest$MockFileSecurityManager.checkPermission(
LoggingTest.java:131)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.File.exists(File.java:700)
at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:401)
at java.io.File.getCanonicalPath(File.java:531)
at java.io.FilePermission$1.run(FilePermission.java:218)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.FilePermission.init(FilePermission.java:212)
at java.io.FilePermission.init(FilePermission.java:264)
at java.lang.SecurityManager.checkDelete(SecurityManager.java:990)
at java.io.File.delete(File.java:869)
at java.util.logging.FileHandler.close(FileHandler.java:594)
at com.andrew.LoggingTest.test_FileHandler(LoggingTest.java:121)
...
The output is check C:\Documents and Settings\myaccount\java0.log.lck
It seems RI tries to delete log file.lck file, but has no permission.
.lck file is never mentioned in spec, and should be implementation
detail.
Current Harmony code never tries to lock a temp empty .lck file, so
the test
passes against Harmony.
If we revise the MockSecurityManager a little, to allow .lck file
permission,
public void checkPermission(Permission perm) {
if (perm instanceof FilePermission) {
if (perm.getName().indexOf(.lck) == -1) {
System.out.println(check + perm.getName());
throw new SecurityException();
}
}
}
The test will pass both against RI and Harmony.
So I'd suggest to leave it as non-bug difference from RI.
I agree.
Richard
Any comments? Thank you!
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
