Re: [classlib][logging] A non bug difference from RI?
On 8/30/06, 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.(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 .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 I understoond correctly, new FileHandler() creates temporary file for
logging (its name is defined by default configuration properties). That is
true for Harmony and RI. Right?
RI tries to delete the created file if FileHandler.close() is invoked. And
Harmony doesn't. Why?
Thanks,
Stepan.
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".
Any comments? Thank you!
--
Andrew Zhang
China Software Development Lab, IBM
--
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: [classlib][luni] A problem about behavior of EnumMap
Paulex Yang 写道:
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());
The above line will fail on RI. But
assertEquals(Size.Big, entry1.getKey()); will pass on RI, which
indicates object referenced by entry1been changed - unreasonable.
assertEquals(1, entry1.getValue());
The above line will fail on RI. But
assertNull(entry1.getValue()); will pass on RI, which indicates object
referenced by entry1been changed to object referenced by entry2 -
unreasonable.
enumSizeMap.remove(Size.Middle);
try {
entry1.setValue(0);
fail("Should throw IllegalStateException"); //$NON-NLS-1$
} catch (IllegalStateException e) {
// Expected
}
The above line will fail on RI.But
entry1.setValue(0);
assertEquals(0, entry2.getValue()); will pass on RI,
which indicates object referenced by entry1been changed to object
referenced by entry2 - unreasonable.
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
--
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][TestNG] groups of Harmony test
On 8/30/06, Richard Liang <[EMAIL PROTECTED]> wrote:
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.
Yes, I do. While tests can have more than one group it will enough.
thanks, Vladimir
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.
>> > *os.any* - group of tests which pass on any platform. IMHO, most of
>> > our tests should be in this group.
>> > *os.* - 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. are mutually exclusive, that is,
>> > tests in os.any group should not be in os.win.IA32.
>> >
>> > 2) [Test state] state.broken, state.broken.
>> > *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.* - 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. 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., 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:
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> 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][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.(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 .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]
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]
[classlib][logging] A non bug difference from RI?
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.(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 .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".
Any comments? Thank you!
--
Andrew Zhang
China Software Development Lab, IBM
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][logging] a test suite shouldn't touch any of JRE config files!!!
+1 Stepan Mishura wrote: 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: 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] - 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: On 8/29/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: 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? :) The next step is to get MMTk semispace collector running. I am working on it right now. It turns out MMTk needs the mark bit and the forwarding bit adjacent to each other in the same byte of the object header. This may mean shoving around the bits in DRLVM object header to get the required space. In neither case is it configurable via a mask or something? geir - 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: 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: [DRLVM][MMTk GC] marksweep configuration works in "user mode"
On 8/29/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: 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? :) The next step is to get MMTk semispace collector running. I am working on it right now. It turns out MMTk needs the mark bit and the forwarding bit adjacent to each other in the same byte of the object header. This may mean shoving around the bits in DRLVM object header to get the required space. geir -- Weldon Washburn 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: [classlib][build] bug of RI 1.5.0_08 compiler
I'm still using Sun JDK 1.5.0_07 on Ubuntu 6.whatever, and I just saw
something odd...
I got a baffling compile error when compiling a test for Beans. (I
forget the test...)
The code was something like :
BeanInfo beanInfo[] = {
SomeClassThatIsABeanInfo.class.getInstance() };
and the compiler complained that it found j.l.Object rather than BeanInfo.
I did ant clean; ant; ant test and then all is fine.
Odd.
geir
Paulex Yang wrote:
I got this error reproduced, more than 50 compile errors when I switched
to Sun JDK 1.5.0_08 with ant 1.6.5 on WinXP. The mysterious thing is the
build passed after "ant clean", while failed again when I modified one
file then built without clean.
Anyone others have same issue? Any ideas what happened?
Richard Liang wrote:
Hello,
Our incremental build does not work under the new compiler.
1) ant clean
2) ant
3) modify a piece of code
4) ant
Then, lots of compilation error are reported. To make the build pass,
call "ant clean" before the build.
Could anyone re-produce this issue? Thanks a lot.
Best regards,
-
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]
Re: [classlib][concurrent] Integrating into builds and snapshot
Andrey Chernyshev wrote: I agree that j.u.c. will need efficient inlining for the Unsafe. However, if the Harmony impl of Unsafe does nothing but simple call forwarding to the appropriate methods of vmmagic, then we probably won't get that big overhead. In other words, we can try keeping Unsafe interface as a bridge between j.u.c. and various VM's at the price of one extra method call to it's "real" implementation (which could be vmmagic in our case). It would be nice, however, if we can agree with the concurrency group to hide Unsafe under some other interface which would have a more neutral package name (e.g. not sun.misc). Agreed. I think though that we should demonstrate why we want the package change by successfully integrating into Harmony. geir - 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][concurrent] Integrating into builds and snapshot
Didn't we agree to move it out of there? geir Nathan Beyer wrote: For now, I'm just going to put everything into 'enhanced/classlib/trunk/modules/concurrent' for the sake of simplicity. We can refactor later. -Nathan -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, August 21, 2006 9:19 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][concurrent] Integrating into builds and snapshot Nathan Beyer wrote: I think we're on the same page for all of this except for the placement of the public domain code. I didn't state it explicitly, but my assumption was that all of the code would go under the 'enhanced/classlib/trunk/modules/concurrent'. I probably should have stated this, but I so rarely work outside of 'enhanced' that it slipped my mind. I don't really care, but I'm not sure how we'd work the build. Right - we'll figure that out. I hope to get it into enhanced as well. Are you thinking that we can svn:external the code from 'standard' to 'enhanced', such that most of it just overlays a normal module code layout? Nope :) I wasn't thinking anything. it's a ugly mess that makes my head hurt. The other options are having the build traverse up from classlib to standard or have two JARs one with the public domain code and one with Harmony code (COWAL). The public domain JAR could be built once and checked into the "depends" under classlib. That would be odd, code from std checked in. Maybe we just tell devs to do it and drop the jar in there... geir -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Monday, August 21, 2006 9:21 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][concurrent] Integrating into builds and snapshot Nathan Beyer wrote: Now that we're getting some good submissions to make the java.util.concurrent code to work with DRLVM, I'd like make a proposal for getting the code in the Class Library and a part of our regular builds, tests and snapshots. >From a technical/code integration standpoint, the go ahead assumption is that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe' class, such that the concurrent code, most of which is in the public domain, from the Concurrency Interest Site [1] can be used as-is, as least to the greatest extent possible. Are there any major dissents to this? This is my understanding of what we already agreed to, and I'm getting a note from Doug about the code provenance. Now, the issue that's of most contention, at least from our past conversations, is the code management. First and foremost, we must consider the realities of the situation. 1. The concurrency interest group, the JSR-166 expert group, Doug Lea and others are NOT producing distributable builds, so we can not integrate the code like we do other components, like Xerces, Xalan, MX4J, etc. I don't want to speak for anyone here, so I'll qualify this by saying that I haven't been told this explicitly, so this is just my inference from discussions and documentation. If this is not the case, then someone please speak up. There is an experimental JAR on the site [1], but it's meant specifically to run with the Sun RI and it contains code outside of the java.util.concurrent package space. Additionally, the TCK tests from the site [1], which we'd like to use are not packaged in any way. Right - we should be able to slurp the tests in the same way as we do the rest of it. In fact, we are less worried about the tests because we don't ship those. And lets just call them "tests", not "TCK test", because while they are used in the TCK, something we get from Sun, they are just "tests" :) 2. The code on the site [1] is only accessible through a ViewCVS Web interface. As such, it's not exactly easy to interact with in terms of created an automated checkout of the source to integrate into a build. One of my thoughts was using the svn:externals feature to download source dynamically, but there are additional issues that make that especially difficult; these issues follow. Besides that, I'm not sure that svn:externals works with arbitrary URLs that aren't SVN repositories. Who cares? We're not going to slurp the code from their site for building... 3. There is at least one source file that MUST NOT be used from the site [1] because it's not open to the public domain, the CopyOnWriteArrayList [2]. This will require at least one class to be developed as part of the Harmony Class Library. Yes. 4. It's currently NOT feasible for Harmony to use the HEAD version of the code, as it has been updated to utilize several Java 6 APIs, which Harmony does not current provide, not even in stub form. Additionally, there is only one viable CVS tag (JSR166_PFD), but this tag is two years old and some of the code in it does not compile on current JLS3 compilers. This has been discussed on the maili
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: [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] 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: [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.Collection > >> > >> [javac] required: java.util.EnumSet > >> > >> [javac] EnumSet set = (EnumSet) 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: [classlib][logging]yet another non-bug difference with RI(Re: [jira] Created: (HARMONY-1300) [classlib][logging] XMLFormatter.format returns a String contains "" 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]
...
...
Andrew Zhang (JIRA) wrote:
> [classlib][logging] XMLFormatter.format returns a String contains
"" 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][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] 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][TestNG] groups of Harmony test
On 8/25/06, 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.
*os.any* - group of tests which pass on any platform. IMHO, most of our
tests should be in this group.
*os.* - 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. are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.
*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.* - 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. 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., we can just use state.broken.MacOS
If a test is marked as *state.broken.MacOS* then it sounds like the
test/implementation should be fixed. IMO we should use tag os.
to define explicitly valid platforms for the test so in this particular case
we should use 9 os.s
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).
Mixing different types of testing into one test-file doesn't look good for
me. I'd separate such tests by placing into different directories/packages.
Thanks,
Stepan.
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
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]
Re: [classlib][TestNG] groups of Harmony test
Can you explain how you expect to see these used? I'm not arguing, but
people think of regression tests different ways...
geir
Vladimir Ivanov wrote:
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.
> *os.any* - group of tests which pass on any platform. IMHO, most of
> our tests should be in this group.
> *os.* - 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. are mutually exclusive, that is,
> tests in os.any group should not be in os.win.IA32.
>
> 2) [Test state] state.broken, state.broken.
> *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.* - 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. 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., 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:
>
>
>
>
>
>
>
>
>
>
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]
-
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.
*os.any* - group of tests which pass on any platform. IMHO, most of our
tests should be in this group.
*os.* - 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. are mutually exclusive, that is, tests
in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.
*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.* - 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. 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., 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:
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][logging]yet another non-bug difference with RI(Re: [jira] Created: (HARMONY-1300) [classlib][logging] XMLFormatter.format returns a String contains "" 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]
...
method?, thread?, message, key?, catalog?, param*, exception?)>
...
Andrew Zhang (JIRA) wrote:
[classlib][logging] XMLFormatter.format returns a String contains
"" 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]
[classlib][logging]yet another non-bug difference with RI(Re: [jira] Created: (HARMONY-1300) [classlib][logging] XMLFormatter.format returns a String contains "" 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]
...
method?, thread?, message, key?, catalog?, param*, exception?)>
...
Andrew Zhang (JIRA) wrote:
[classlib][logging] XMLFormatter.format returns a String contains "" 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][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.
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.* - 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. 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.
*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.* - 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. 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., 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:
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]
Re: [classlib][TestNG] groups of Harmony test
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.
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.* - 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. 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.
2) [Test state] state.broken, state.broken.
*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.* - 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. 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., 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:
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. ;-)
--
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.
> *os.any* - group of tests which pass on any platform. IMHO, most of
> our tests should be in this group.
> *os.* - 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. are mutually exclusive, that is,
> tests in os.any group should not be in os.win.IA32.
>
> 2) [Test state] state.broken, state.broken.
> *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.* - 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. 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., 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:
>
>
>
>
>
>
>
>
>
>
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][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
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. group indicates that it is designed for
only. If there is no group like os. 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:
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 "name=".*" /> "
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.
> > *os.any* - group of tests which pass on any platform. IMHO, most of
> > our tests should be in this group.
> > *os.* - 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. are mutually exclusive, that is,
> > tests in os.any group should not be in os.win.IA32.
> >
> > 2) [Test state] state.broken, state.broken.
> > *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.* - 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. 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., 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:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 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
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. group indicates that it is designed for
only. If there is no group like os. 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:
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.
> > *os.any* - group of tests which pass on any platform. IMHO, most of
> > our tests should be in this group.
> > *os.* - 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. are mutually exclusive, that is,
> > tests in os.any group should not be in os.win.IA32.
> >
> > 2) [Test state] state.broken, state.broken.
> > *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.* - 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. 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., 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:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 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: 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]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: [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: [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://incubat
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: 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][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. group indicates that it is designed for
only. If there is no group like os. 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:
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.
> > *os.any* - group of tests which pass on any platform. IMHO, most of
> > our tests should be in this group.
> > *os.* - 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. are mutually exclusive, that is,
> > tests in os.any group should not be in os.win.IA32.
> >
> > 2) [Test state] state.broken, state.broken.
> > *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.* - 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. 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., 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:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 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?
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] 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?
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][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: [classlib]strings externalization
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 :) 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] -- -- Ilya Okomin Intel Middleware Products Division
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: [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: [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: [classlib][TestNG] groups of Harmony test
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.
> *os.any* - group of tests which pass on any platform. IMHO, most of
> our tests should be in this group.
> *os.* - 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. are mutually exclusive, that is,
> tests in os.any group should not be in os.win.IA32.
>
> 2) [Test state] state.broken, state.broken.
> *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.* - 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. 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., 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:
>
>
>
>
>
>
>
>
>
>
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]
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> set = (EnumSet> Enum>)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> still has >> potential pitfall: >> >> In the signature of addAll(Collection collection) method, ? >> denotes subclass of E. >> While in EnumSet>, ? denotes subclass of Enum. But >> consider the relationship >> between E and Enum, E is subclass of Enum. So, we can not >> guarantee that subclass of E is definitely >> subclass of Enum. > > Hmm, as E is a subclass of Enum, subclasses of E definitely have > Enum 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 Enum. So, we can not guarantee that subclasses of E(? extends E) is definitely compatible with subclasses of Enum(? extends Enum). Since the input collection is of type , cast it to > 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: [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: 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][VM] set_hash_bits() in vmcore/src/thread/mon_enter_exit.cpp -- is it a bug or a feature?
This is the GC_V4 specifics. It uses two bits of least significant
byte of the status word during GC, but it always return zeros to this
bits after GC.
Here is the atomic way to do the changes:
do {
unsigned char lsb = *P_HASH_CONTENTION(p_obj);
unsigned char new_lsb = lsb | hb;
unsigned char uptodate_lsb =
port_atomic_cas8(P_HASH_CONTENTION(p_obj), new_lsb, lsb);
while (lsb != uptodate_lsb);
BTW, atomic operations is only needed if GC wants to update those two
bits during mutator work. Otherwise, non-atomic operations is ok, as
the same value can be safely written to the same address by multiple
threads. This is one pros for moving this code to GC.
--
Ivan
On 8/28/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
While porting MMTk to harmony/drlvm, I hit an integration problem. It
could even be a bug. set_hash_bits() assumes the least significant
bit is zero. Assuming that the LSB can be "owned" by the garbage
collector for its purposes, set_hash_bits() will fail if the GC sets
this bit to one. Somehow I think the code should read the target
location, create the intended bit pattern before attempting to do the
atomic compare and swap. Currently the code assume the target CAS
location holds zero.
SInce I am working only in single thread right now, I hacked around
the problem with the below. Thoughts?
C:\t_harmony\drlvm\trunk\vm\vmcore\src\thread>svn diff mon_enter_exit.cpp
Index: mon_enter_exit.cpp
===
--- mon_enter_exit.cpp (revision 425482)
+++ mon_enter_exit.cpp (working copy)
@@ -368,7 +368,12 @@
hb = (23 & HASH_MASK); // NO hash = zero allowed, thus hard map hb = 0
to a fixed prime number
// don't care if the cmpxchg fails -- just means someone else already set t
he hash
-port_atomic_cas8(P_HASH_CONTENTION(p_obj),hb, 0);
+//port_atomic_cas8(P_HASH_CONTENTION(p_obj),hb, 0);
+unsigned char lsb = *P_HASH_CONTENTION(p_obj);
+lsb = lsb & 0x01; //wjw need to keep the LSB, its used by MMTk Garbage Col
lector
+hb = hb | lsb;
+if ( (*P_HASH_CONTENTION(p_obj) & HASH_MASK) == 0 ) // wjw non-atomic hack
for now
+*P_HASH_CONTENTION(p_obj) = hb;
}
-
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: [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]
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
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()
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]
