Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Stepan Mishura wrote: On 9/4/06, *Paulex Yang* wrote: Stepan Mishura wrote: On 9/1/06, Paulex Yang wrote: Stepan Mishura wrote: Hi Andrew, I've just looked into static initialization block and then to the spec. for LogManager class. My impression is that Harmony implementation doesn't follow the spec. The spec. says: At startup the LogManager class is located using the ' java.util.logging.manager' system property.By default, the LogManager reads its initial configuration from a properties file lib/logging.properties in the JRE directory Stepan, I think the meaning of By default is debatable. Actually the spec looks like this: At startup the LogManager class is located using the java.util.logging.manager system property. By default, the LogManager reads its initial configuration from a properties file lib/logging.properties in the JRE directory. If you edit that property file you can change the default logging configuration for all uses of that JRE. In addition, the LogManager uses two optional system properties that allow more control over reading the initial configuration: * java.util.logging.config.class * java.util.logging.config.file... So I consider the By default doesn't necessarily means default case without java.util.logging.manager property, but means the default case without java.util.logging.config.class/file properties. A simple test on RI of specifying a customized MockLogManager by j.u.l.manager property shows the default lib/logging.properties does affect the behavior of the customized LogManager, say the root logger's level, etc. Do you mean that RI resets the root logger's level of customized LogManager to default value from lib/logging.properties? Yes, so I think customized LogManager also needs to initialize itself in same procedure as j.u.l.LogManager. Hi Paulex, I've implemented custom LogManager (see attachment): it sets value for root logger's level different from default value(INFO). According to my test (see attachment) RI doesn't change level of root logger. The test prints the following: $java -classpath . MyTest INFO $java -classpath . -Djava.util.logging.manager=CustomLogManager MyTest SEVERE Did I missed something? Stepan, I run the test under Sun JDK 1.5.0_06 for WinXP, but I got INFO printed for both cases... Thanks, Stepan. -- 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: Re: Re: [classlib][TestNG] groups of Harmony test
On 9/5/06, Andrew Zhang [EMAIL PROTECTED] wrote: If test fails on linux than (for example): - the test/ implementation should be fixed or What if the behaviour is different on different platforms? Seems, that it may be just 2 different tests. - the test should define platform and report 'passed' if it does not support current platform How to define platform? Get platform information in test code? Yes. It is just one line of code. For example, from Support_Exec.java class: boolean onUnix = File.separatorChar == '/'; thanks, Vladimir In this context seems we don't need in any 'level' group (while 'stress' tests require reasonable time to pass). Seems, that platform group also can be deleted (at present time we have 10 platform-dependent tests and this amount should not increase dramatically so the platform-detection can be included to the each such test). Also cpu groups can be deleted (while we have not cpu-dependent test). At the end we need only state groups to support test exclusion on the 'one-element' level (while we have unresolved entries in the current exclude list). So, after small update of unit (aka integration, aka regression etc) tests and resolution of all entries in the exclude list we don't need any groups and pure JUnit covers all our needs :) On the other side, if we define some groups it will nice to define *all* reasonable groups at the begin of the process. Yes. We should figure out all possible groups. And it can be consolidated during applying TestNG. Agree. thanks, Vladimir thanks, Vladimir By the way, our regression tests are 'classic' regression tests that demonstrate some issues which were not resolved by initial code. But it provides less coverage than 'regression tests' + unit tests, of cause. On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote: If you've got fast and slow tests, then have a group for fast and slow tests. Then you can choose to just run the fast tests, and any automated build system can handle running the slow tests. IMHO, fast or slow may not be the key point. The question is whether we have any requirements to run only the regression tests. No, probably not the key point, but (a) groups don't have to be mutually exclusive (so you can decorate it with whatever groups you want) I agree. For example, os.win and os.linux are not mutually exclusive. Thanks a lot. and (b) it might be useful for an automated build system to run fast tests first, followed by slow (or non-fast) tests. That makes sense through we have not clear requirement currently. Mind you, I don't know what's going to happen with an automated test'n'build system; so it might not make sense to do it at this point. Really? ;-) We could also discuss whether it's feasible to move to TestNG. As you may know, there are already several threads about TestNG JUnit. Here I just review the open questions one by one so that we have sufficient preparation. [1]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [2]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [3]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] Best regards, Richard Alex. - 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] -- Andrew Zhang China Software Development Lab, IBM -- Andrew Zhang China Software Development Lab, IBM
Re: Re: Re: [classlib][TestNG] groups of Harmony test
On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: On 9/5/06, Andrew Zhang [EMAIL PROTECTED] wrote: If test fails on linux than (for example): - the test/ implementation should be fixed or What if the behaviour is different on different platforms? Seems, that it may be just 2 different tests. - the test should define platform and report 'passed' if it does not support current platform How to define platform? Get platform information in test code? Yes. It is just one line of code. For example, from Support_Exec.java class: boolean onUnix = File.separatorChar == '/'; Yes, it does work sometimes, but ... How to differentiate AIX, solaris, linux, unix, windows and etc... If there's a public API or can be retrieved from system property, it may work. thanks, Vladimir In this context seems we don't need in any 'level' group (while 'stress' tests require reasonable time to pass). Seems, that platform group also can be deleted (at present time we have 10 platform-dependent tests and this amount should not increase dramatically so the platform-detection can be included to the each such test). Also cpu groups can be deleted (while we have not cpu-dependent test). At the end we need only state groups to support test exclusion on the 'one-element' level (while we have unresolved entries in the current exclude list). So, after small update of unit (aka integration, aka regression etc) tests and resolution of all entries in the exclude list we don't need any groups and pure JUnit covers all our needs :) On the other side, if we define some groups it will nice to define *all* reasonable groups at the begin of the process. Yes. We should figure out all possible groups. And it can be consolidated during applying TestNG. Agree. thanks, Vladimir thanks, Vladimir By the way, our regression tests are 'classic' regression tests that demonstrate some issues which were not resolved by initial code. But it provides less coverage than 'regression tests' + unit tests, of cause. On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote: If you've got fast and slow tests, then have a group for fast and slow tests. Then you can choose to just run the fast tests, and any automated build system can handle running the slow tests. IMHO, fast or slow may not be the key point. The question is whether we have any requirements to run only the regression tests. No, probably not the key point, but (a) groups don't have to be mutually exclusive (so you can decorate it with whatever groups you want) I agree. For example, os.win and os.linux are not mutually exclusive. Thanks a lot. and (b) it might be useful for an automated build system to run fast tests first, followed by slow (or non-fast) tests. That makes sense through we have not clear requirement currently. Mind you, I don't know what's going to happen with an automated test'n'build system; so it might not make sense to do it at this point. Really? ;-) We could also discuss whether it's feasible to move to TestNG. As you may know, there are already several threads about TestNG JUnit. Here I just review the open questions one by one so that we have sufficient preparation. [1]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [2]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [3]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] Best regards, Richard Alex. - 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] -- Andrew Zhang China Software Development Lab, IBM -- Andrew Zhang China Software Development Lab, IBM -- Andrew Zhang China Software Development Lab, IBM
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
On 9/5/06, Paulex Yang wrote: Stepan Mishura wrote: On 9/4/06, *Paulex Yang* wrote: Stepan Mishura wrote: On 9/1/06, Paulex Yang wrote: Stepan Mishura wrote: Hi Andrew, I've just looked into static initialization block and then to the spec. for LogManager class. My impression is that Harmony implementation doesn't follow the spec. The spec. says: At startup the LogManager class is located using the ' java.util.logging.manager' system property.By default, the LogManager reads its initial configuration from a properties file lib/logging.properties in the JRE directory Stepan, I think the meaning of By default is debatable. Actually the spec looks like this: At startup the LogManager class is located using the java.util.logging.manager system property. By default, the LogManager reads its initial configuration from a properties file lib/logging.properties in the JRE directory. If you edit that property file you can change the default logging configuration for all uses of that JRE. In addition, the LogManager uses two optional system properties that allow more control over reading the initial configuration: * java.util.logging.config.class * java.util.logging.config.file... So I consider the By default doesn't necessarily means default case without java.util.logging.manager property, but means the default case without java.util.logging.config.class/file properties. A simple test on RI of specifying a customized MockLogManager by j.u.l.manager property shows the default lib/logging.properties does affect the behavior of the customized LogManager, say the root logger's level, etc. Do you mean that RI resets the root logger's level of customized LogManager to default value from lib/logging.properties? Yes, so I think customized LogManager also needs to initialize itself in same procedure as j.u.l.LogManager. Hi Paulex, I've implemented custom LogManager (see attachment): it sets value for root logger's level different from default value(INFO). According to my test (see attachment) RI doesn't change level of root logger. The test prints the following: $java -classpath . MyTest INFO $java -classpath . -Djava.util.logging.manager=CustomLogManager MyTest SEVERE Did I missed something? Stepan, I run the test under Sun JDK 1.5.0_06 for WinXP, but I got INFO printed for both cases... Hmm, interesting. I've tried with BEA JRE ... going to check with Sun's 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][security] Exception compatibility
Boris thank you for your question. I asked myself the same question and choose the same answer as you. Unfortunately as people wrote above we were wrong and they are reasonable. I have already written patch for HARMONY-1120 to follow RI behavior. 2006/9/5, Stepan Mishura [EMAIL PROTECTED]: On 9/4/06, Boris Kuznetsov wrote: Usually Harmony behavior is compared with RI behavior. But in security area RI behavior depends on provider. With different providers RI behave differently. For example, RI passes incorrect method arguments to provider. In such cases provider may throw exception (e.g. DigestException or IllegalArgumentException) or some RuntimeException (e.g. ArrayIndexOutOfBoundsException) may be thrown during the execution. Here is example. There are number of methods with arguments like (byte[] buf, int offset, int len). RI doesn't check if offset and len are negative but Harmony does, so we have difference in behavior (see Harmony-1120, 1148): on combination RI + provider application gets provider specific exception, but on Harmony + provider - IllegalArgumentException (as in other invalid parameters cases). So we have two options: 1. Fix Harmony (remove negative parameters checks) 2. Don't fix. Throw IllegalArgumentException for invalid parameters. Document as non-bug difference from RI. Hi, Boris. We agreed to be exceptions-compatible with RI so we would have chosen the first option. But I think that the first option is not suitable. I'll try to explain why. I have a look at MessageDigest.java and mentioned JIRAs: so there are 4 cases when parameters are invalid and an implementation has to check if: 1) buf - is null 2) offset 0 3) len 0 4) offset + len buf's len The first option means that we have to remove 2 and 3 checks. And leave 1 and 4 as RI does. But 4 check is meaningless without 2 and 3. IOW, it is only valid if offset and len params are correct. IMO chosing the first option is copying inconsistent behaviour. So I vote for the second option. Thanks, Stepan. Note, specification doesn't describe implementation behavior for invalid arguments, but RI also throws IllegalArgumentException if ofsset+len buf.length. So throwing of IllegalArgumentException in Harmony can't break any application. I suggest option 2. Thoughts? Thanks, Boris -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Denis M. Kishenko 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: Re: Re: [classlib][TestNG] groups of Harmony test
On 9/5/06, Andrew Zhang [EMAIL PROTECTED] wrote: ... How to define platform? Get platform information in test code? Yes. It is just one line of code. For example, from Support_Exec.java class: boolean onUnix = File.separatorChar == '/'; Yes, it does work sometimes, but ... How to differentiate AIX, solaris, linux, unix, windows and etc... Do we really need in it? At present time tests were designed for win/unix only. In any case, I don't against the groups but if we define 'general' groups set it should include 'regression' group too. If there's a public API or can be retrieved from system property, it may work. The public API does not specify exact names for platforms (java is platform independent :) ) so these ways are equals (but for impl tests it will works fine). thanks, Vladimir thanks, Vladimir In this context seems we don't need in any 'level' group (while 'stress' tests require reasonable time to pass). Seems, that platform group also can be deleted (at present time we have 10 platform-dependent tests and this amount should not increase dramatically so the platform-detection can be included to the each such test). Also cpu groups can be deleted (while we have not cpu-dependent test). At the end we need only state groups to support test exclusion on the 'one-element' level (while we have unresolved entries in the current exclude list). So, after small update of unit (aka integration, aka regression etc) tests and resolution of all entries in the exclude list we don't need any groups and pure JUnit covers all our needs :) On the other side, if we define some groups it will nice to define *all* reasonable groups at the begin of the process. Yes. We should figure out all possible groups. And it can be consolidated during applying TestNG. Agree. thanks, Vladimir thanks, Vladimir By the way, our regression tests are 'classic' regression tests that demonstrate some issues which were not resolved by initial code. But it provides less coverage than 'regression tests' + unit tests, of cause. On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote: If you've got fast and slow tests, then have a group for fast and slow tests. Then you can choose to just run the fast tests, and any automated build system can handle running the slow tests. IMHO, fast or slow may not be the key point. The question is whether we have any requirements to run only the regression tests. No, probably not the key point, but (a) groups don't have to be mutually exclusive (so you can decorate it with whatever groups you want) I agree. For example, os.win and os.linux are not mutually exclusive. Thanks a lot. and (b) it might be useful for an automated build system to run fast tests first, followed by slow (or non-fast) tests. That makes sense through we have not clear requirement currently. Mind you, I don't know what's going to happen with an automated test'n'build system; so it might not make sense to do it at this point. Really? ;-) We could also discuss whether it's feasible to move to TestNG. As you may know, there are already several threads about TestNG JUnit. Here I just review the open questions one by one so that we have sufficient preparation. [1]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [2]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [3]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] Best regards, Richard Alex. - 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] -- Andrew Zhang China Software Development Lab, IBM
Re: [classlib][security] Exception compatibility
IMHO we should look from the perspective of migrating the apps. So let's try to make behavior of Harmony + BC provider close to Sun + Sun's provider If without the checks the combination Harmony+BC works similar to Sun+Sun's provider, then let's remove the checks. Otherwise let's keep it to make the behavior at least logical. Thanks, Mikhail 2006/9/4, Boris Kuznetsov [EMAIL PROTECTED]: Usually Harmony behavior is compared with RI behavior. But in security area RI behavior depends on provider. With different providers RI behave differently. For example, RI passes incorrect method arguments to provider. In such cases provider may throw exception (e.g. DigestException or IllegalArgumentException) or some RuntimeException (e.g. ArrayIndexOutOfBoundsException) may be thrown during the execution. Here is example. There are number of methods with arguments like (byte[] buf, int offset, int len). RI doesn't check if offset and len are negative but Harmony does, so we have difference in behavior (see Harmony-1120, 1148): on combination RI + provider application gets provider specific exception, but on Harmony + provider - IllegalArgumentException (as in other invalid parameters cases). So we have two options: 1. Fix Harmony (remove negative parameters checks) 2. Don't fix. Throw IllegalArgumentException for invalid parameters. Document as non-bug difference from RI. Note, specification doesn't describe implementation behavior for invalid arguments, but RI also throws IllegalArgumentException if ofsset+len buf.length. So throwing of IllegalArgumentException in Harmony can't break any application. I suggest option 2. Thoughts? Thanks, Boris - 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: Re: Re: [classlib][TestNG] groups of Harmony test
On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: On 9/5/06, Andrew Zhang [EMAIL PROTECTED] wrote: ... How to define platform? Get platform information in test code? Yes. It is just one line of code. For example, from Support_Exec.java class: boolean onUnix = File.separatorChar == '/'; Yes, it does work sometimes, but ... How to differentiate AIX, solaris, linux, unix, windows and etc... Do we really need in it? At present time tests were designed for win/unix only. Yes. In the future, Harmony will support more platforms. We may have more platform-dependent test cases. In any case, I don't against the groups but if we define 'general' groups set it should include 'regression' group too. If there's a public API or can be retrieved from system property, it may work. The public API does not specify exact names for platforms (java is platform independent :) ) so these ways are equals (but for impl tests it will works fine). thanks, Vladimir thanks, Vladimir In this context seems we don't need in any 'level' group (while 'stress' tests require reasonable time to pass). Seems, that platform group also can be deleted (at present time we have 10 platform-dependent tests and this amount should not increase dramatically so the platform-detection can be included to the each such test). Also cpu groups can be deleted (while we have not cpu-dependent test). At the end we need only state groups to support test exclusion on the 'one-element' level (while we have unresolved entries in the current exclude list). So, after small update of unit (aka integration, aka regression etc) tests and resolution of all entries in the exclude list we don't need any groups and pure JUnit covers all our needs :) On the other side, if we define some groups it will nice to define *all* reasonable groups at the begin of the process. Yes. We should figure out all possible groups. And it can be consolidated during applying TestNG. Agree. thanks, Vladimir thanks, Vladimir By the way, our regression tests are 'classic' regression tests that demonstrate some issues which were not resolved by initial code. But it provides less coverage than 'regression tests' + unit tests, of cause. On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote: If you've got fast and slow tests, then have a group for fast and slow tests. Then you can choose to just run the fast tests, and any automated build system can handle running the slow tests. IMHO, fast or slow may not be the key point. The question is whether we have any requirements to run only the regression tests. No, probably not the key point, but (a) groups don't have to be mutually exclusive (so you can decorate it with whatever groups you want) I agree. For example, os.win and os.linux are not mutually exclusive. Thanks a lot. and (b) it might be useful for an automated build system to run fast tests first, followed by slow (or non-fast) tests. That makes sense through we have not clear requirement currently. Mind you, I don't know what's going to happen with an automated test'n'build system; so it might not make sense to do it at this point. Really? ;-) We could also discuss whether it's feasible to move to TestNG. As you may know, there are already several threads about TestNG JUnit. Here I just review the open questions one by one so that we have sufficient preparation. [1]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [2]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [3]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] Best regards, Richard Alex. - 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
Re: [DRLVM] GC heap verification infrastructure
Weldon Washburn wrote: On 7/18/06, Volynets, Vera [EMAIL PROTECTED] wrote: Hi, I didn't find any bugs in gc_v4 at the moment, Vera, its good to know the verifier found zero bugs in GCV4! but this feature is really very useful especially if you modify gc_v4 or design a new gc. Of course, it needs to be improved and developed. This brings up a good point. Harmony-dev needs to discuss the roadmap for DRLVM GC. I will start a discussion thread shortly. Also I'm going to add feature to verify write barriers work. Some comments. 1) There is no DRLVM GC that uses a write barrier currently. Assuming you have a write barrier verifier, how will you know it works? 2) I would like to see the design of the write barrier verifier discussed on harmony-dev mailing list before implementation is started. I am interested in using the proposed write verifier on DRLVM/MMTk. The first method to occur to me (and I'm afraid this is shamelessly MMTk-centric :) is to write a write-barrier validating plan: - Mutator runs, using write barrier to populate the REMSET - Collector performs a full-heap collection (a-la IGNORE_REMSETS), however, whenever an old-to-new pointer is encountered, you check whether the pointer was recorded in the REMSET. - Ditto for roots that point into the nursery. It would need to take care not to flag references from objects promoted from the nursery earlier in this collection, but this shouldn't be too hard to arrange. This should also be quite easy to build entirely within MMTk (sorry GCV5 guys :) Another (better) approach would be to write a REMSET sanity checker. When enabled by a command-line switch it would inject an extra phase into the GC phase list (like the existing sanity checker does), and before a nursery collection it would: - do a full-heap trace, using private side metadata - Record all references that point into the nursery - when done, check this against the remset and report discrepancies. The remset should contain a superset of the references that this sanity checker finds. There's no real reason this couldn't live in MMTk permanently. The same way as in GC heap verification I use idea to hijack interface function concerning write barriers. This patch will be sent a bit later. Pleased to hear from you, Vera :)! -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Saturday, July 15, 2006 9:37 AM To: harmony-dev@incubator.apache.org Subject: Re: [DRLVM] GC heap verification infrastructure On the 0x1A6 day of Apache Harmony Vera Volynets wrote: * GC heap verification infrastructure *** Hi, I have been working on implementing GC heap verification infrastructure for Stop-The-World GC in DRLVM. This infrastructure is intended be used with any stop-the-world GC implementation, conforming to the GC-VM interface (described in gc.h and vm_gc.h), with only a minor GC-VM interface change. It works on Windows and Linux ia32 platforms. cool feature! did you find any bugs in DRLVM while testing? do you have plans/ideas for future development of the tool? [...] *Patch contents* This is an individual contribution, and it was prepared according to the requirements of Apache cleanroom process; the size of two files all in all is about 30kb (161 and 585 lines). -Patch Add-function-to-gc-interface.txt oh, I found it! HARMONY-881 -- 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] - 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 non bug difference from RI?
Stepan Mishura wrote:
On 9/1/06, Paulex Yang wrote:
Stepan Mishura wrote:
Andrew, thanks for the test. But working test doesn't mean that there
is no
bug :-)
AFAIK in our case an operation on file (if file is not exist - create
file)
should be atomic. And it looks like Harmony implementation doesn't
do in
atomic way.(see FileHandler.initOutputFiles() method)
Seems there is a bug in the FileHandler.initOutputFiles(), in Ln. 232,
if the FileLock isn't held, the FileOutputStream should be closed before
continue.
code
lock = channel.tryLock();
if (null == lock) {
//the FileChannel(or FileOutputStream) should be
closed here
continue;
}
/code
BTW, why FileNotFoundException is re-thrown in Ln. 223 ? IMO, try-catch
block should be deleted.
try {
fileStream = new FileOutputStream(fileName, append);
channel = fileStream.getChannel();
} catch(FileNotFoundException e){
//invalid path name, throw exception
throw e;
}
Agree, fixed at revision r440292.
But I didn't catch up what's the atomic means here, do you mean the
tryLock() is not atomic or sth.? If so, any other solutions for Java
codes? Otherwise, I think current implementation is fine, if two process
try to open same log file at same time, only one process can get the
lock by tryLock(), and the other will close the FileOutputStream then
continue to try another log file name, anything I missed?
I was confused by gaps in code between File.exists(), new
FileOutputStream()
and FileChannel.tryLock().
For example, I've tried to emulate the following situation:
A process VM_1 is up to lock a created file (Ln.230) and in this time a
process VM_2 found out that the file exists and deleted it (Ln.213). My
current result is that the file is locked successfully but may be I
incorrectly emulated situation. I'm going to continue experimenting
and let
you know if it is possible to create reproducible files conflict.
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]
--
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][security] Exception compatibility
By the way, people what do you think about HARMONY-1110? Problem is we have to reproduce behavior of pattern parser without specification. There is only one example in Java doc which doesn't allow understand when pattern is incorrect. 2006/9/5, Denis Kishenko [EMAIL PROTECTED]: Boris thank you for your question. I asked myself the same question and choose the same answer as you. Unfortunately as people wrote above we were wrong and they are reasonable. I have already written patch for HARMONY-1120 to follow RI behavior. 2006/9/5, Stepan Mishura [EMAIL PROTECTED]: On 9/4/06, Boris Kuznetsov wrote: Usually Harmony behavior is compared with RI behavior. But in security area RI behavior depends on provider. With different providers RI behave differently. For example, RI passes incorrect method arguments to provider. In such cases provider may throw exception (e.g. DigestException or IllegalArgumentException) or some RuntimeException (e.g. ArrayIndexOutOfBoundsException) may be thrown during the execution. Here is example. There are number of methods with arguments like (byte[] buf, int offset, int len). RI doesn't check if offset and len are negative but Harmony does, so we have difference in behavior (see Harmony-1120, 1148): on combination RI + provider application gets provider specific exception, but on Harmony + provider - IllegalArgumentException (as in other invalid parameters cases). So we have two options: 1. Fix Harmony (remove negative parameters checks) 2. Don't fix. Throw IllegalArgumentException for invalid parameters. Document as non-bug difference from RI. Hi, Boris. We agreed to be exceptions-compatible with RI so we would have chosen the first option. But I think that the first option is not suitable. I'll try to explain why. I have a look at MessageDigest.java and mentioned JIRAs: so there are 4 cases when parameters are invalid and an implementation has to check if: 1) buf - is null 2) offset 0 3) len 0 4) offset + len buf's len The first option means that we have to remove 2 and 3 checks. And leave 1 and 4 as RI does. But 4 check is meaningless without 2 and 3. IOW, it is only valid if offset and len params are correct. IMO chosing the first option is copying inconsistent behaviour. So I vote for the second option. Thanks, Stepan. Note, specification doesn't describe implementation behavior for invalid arguments, but RI also throws IllegalArgumentException if ofsset+len buf.length. So throwing of IllegalArgumentException in Harmony can't break any application. I suggest option 2. Thoughts? Thanks, Boris -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Denis M. Kishenko Intel Middleware Products Division -- Denis M. Kishenko 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] Updated: (HARMONY-1334) [classlib][internationalization]Internationalization of the sound module
Ilya Does it make sense? -throw new Error(not yet implemented); +// sound.00=not yet implemented +throw new Error(Messages.getString(sound.00)); //$NON-NLS-1$ Thanks, Mikhail 2006/9/4, Ilya Okomin (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1334?page=all ] Ilya Okomin updated HARMONY-1334: - Attachment: sound.diff Please try this patch. [classlib][internationalization]Internationalization of the sound module Key: HARMONY-1334 URL: http://issues.apache.org/jira/browse/HARMONY-1334 Project: Harmony Issue Type: Sub-task Components: Classlib Reporter: Ilya Okomin Priority: Trivial Attachments: sound.diff [sound] module should be internationalized with the scheme suggested in HARMONY-1308 issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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][security] Exception compatibility
let's talk about it on a different thread 2006/9/5, Denis Kishenko [EMAIL PROTECTED]: By the way, people what do you think about HARMONY-1110? Problem is we have to reproduce behavior of pattern parser without specification. There is only one example in Java doc which doesn't allow understand when pattern is incorrect. 2006/9/5, Denis Kishenko [EMAIL PROTECTED]: Boris thank you for your question. I asked myself the same question and choose the same answer as you. Unfortunately as people wrote above we were wrong and they are reasonable. I have already written patch for HARMONY-1120 to follow RI behavior. 2006/9/5, Stepan Mishura [EMAIL PROTECTED]: On 9/4/06, Boris Kuznetsov wrote: Usually Harmony behavior is compared with RI behavior. But in security area RI behavior depends on provider. With different providers RI behave differently. For example, RI passes incorrect method arguments to provider. In such cases provider may throw exception (e.g. DigestException or IllegalArgumentException) or some RuntimeException (e.g. ArrayIndexOutOfBoundsException) may be thrown during the execution. Here is example. There are number of methods with arguments like (byte[] buf, int offset, int len). RI doesn't check if offset and len are negative but Harmony does, so we have difference in behavior (see Harmony-1120, 1148): on combination RI + provider application gets provider specific exception, but on Harmony + provider - IllegalArgumentException (as in other invalid parameters cases). So we have two options: 1. Fix Harmony (remove negative parameters checks) 2. Don't fix. Throw IllegalArgumentException for invalid parameters. Document as non-bug difference from RI. Hi, Boris. We agreed to be exceptions-compatible with RI so we would have chosen the first option. But I think that the first option is not suitable. I'll try to explain why. I have a look at MessageDigest.java and mentioned JIRAs: so there are 4 cases when parameters are invalid and an implementation has to check if: 1) buf - is null 2) offset 0 3) len 0 4) offset + len buf's len The first option means that we have to remove 2 and 3 checks. And leave 1 and 4 as RI does. But 4 check is meaningless without 2 and 3. IOW, it is only valid if offset and len params are correct. IMO chosing the first option is copying inconsistent behaviour. So I vote for the second option. Thanks, Stepan. Note, specification doesn't describe implementation behavior for invalid arguments, but RI also throws IllegalArgumentException if ofsset+len buf.length. So throwing of IllegalArgumentException in Harmony can't break any application. I suggest option 2. Thoughts? Thanks, Boris -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Denis M. Kishenko Intel Middleware Products Division -- Denis M. Kishenko 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]
[classlib][text] ChoiceFormat pattern parser compatibility
People what do you think about HARMONY-1110? Problem is we have to reproduce behavior of ChoiceFormat pattern parser without specification. There is only one example in Java doc which doesn't allow understand when RI assumes that pattern is incorrect. Thanks -- Denis M. Kishenko 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][security] Exception compatibility
BC provider throws the same exceptions as SUN provider (at least for standard digest alg. names: SHA, MD2, MD5, SHA-256, SHA-384, SHA-512). But what about other third party providers? On 9/5/06, Mikhail Loenko [EMAIL PROTECTED] wrote: IMHO we should look from the perspective of migrating the apps. So let's try to make behavior of Harmony + BC provider close to Sun + Sun's provider If without the checks the combination Harmony+BC works similar to Sun+Sun's provider, then let's remove the checks. Otherwise let's keep it to make the behavior at least logical. Thanks, Mikhail 2006/9/4, Boris Kuznetsov [EMAIL PROTECTED]: Usually Harmony behavior is compared with RI behavior. But in security area RI behavior depends on provider. With different providers RI behave differently. For example, RI passes incorrect method arguments to provider. In such cases provider may throw exception (e.g. DigestException or IllegalArgumentException) or some RuntimeException (e.g. ArrayIndexOutOfBoundsException) may be thrown during the execution. Here is example. There are number of methods with arguments like (byte[] buf, int offset, int len). RI doesn't check if offset and len are negative but Harmony does, so we have difference in behavior (see Harmony-1120, 1148): on combination RI + provider application gets provider specific exception, but on Harmony + provider - IllegalArgumentException (as in other invalid parameters cases). So we have two options: 1. Fix Harmony (remove negative parameters checks) 2. Don't fix. Throw IllegalArgumentException for invalid parameters. Document as non-bug difference from RI. Note, specification doesn't describe implementation behavior for invalid arguments, but RI also throws IllegalArgumentException if ofsset+len buf.length. So throwing of IllegalArgumentException in Harmony can't break any application. I suggest option 2. Thoughts? Thanks, Boris - 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] -- Best regards, Boris Kuznetsov 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] Updated: (HARMONY-1334) [classlib][internationalization]Internationalization of the sound module
Yep, you are right, we can left such messages without internationalization. I made this automatically. Thanks for pointing this Mikhail, I'll update the patch. Regards, Ilya. On 9/5/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Ilya Does it make sense? -throw new Error(not yet implemented); +// sound.00=not yet implemented +throw new Error(Messages.getString(sound.00)); //$NON-NLS-1$ Thanks, Mikhail 2006/9/4, Ilya Okomin (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1334?page=all ] Ilya Okomin updated HARMONY-1334: - Attachment: sound.diff Please try this patch. [classlib][internationalization]Internationalization of the sound module Key: HARMONY-1334 URL: http://issues.apache.org/jira/browse/HARMONY-1334 Project: Harmony Issue Type: Sub-task Components: Classlib Reporter: Ilya Okomin Priority: Trivial Attachments: sound.diff [sound] module should be internationalized with the scheme suggested in HARMONY-1308 issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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: [jira] Updated: (HARMONY-1334) [classlib][internationalization]Internationalization of the sound module
Ooops...I've seen your comments that you've already removed these changes in jira a bit later. I'll take a look at the applied patch results today. Regards, Ilya. On 9/5/06, Ilya Okomin [EMAIL PROTECTED] wrote: Yep, you are right, we can left such messages without internationalization. I made this automatically. Thanks for pointing this Mikhail, I'll update the patch. Regards, Ilya. On 9/5/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Ilya Does it make sense? -throw new Error(not yet implemented); +// sound.00=not yet implemented +throw new Error(Messages.getString(sound.00)); //$NON-NLS-1$ Thanks, Mikhail 2006/9/4, Ilya Okomin (JIRA) [EMAIL PROTECTED] : [ http://issues.apache.org/jira/browse/HARMONY-1334?page=all ] Ilya Okomin updated HARMONY-1334: - Attachment: sound.diff Please try this patch. [classlib][internationalization]Internationalization of the sound module Key: HARMONY-1334 URL: http://issues.apache.org/jira/browse/HARMONY-1334 Project: Harmony Issue Type: Sub-task Components: Classlib Reporter: Ilya Okomin Priority: Trivial Attachments: sound.diff [sound] module should be internationalized with the scheme suggested in HARMONY-1308 issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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 -- -- Ilya Okomin Intel Middleware Products Division
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
On 9/5/06, Paulex Yang wrote: Stepan Mishura wrote: On 9/4/06, *Paulex Yang* wrote: Stepan Mishura wrote: On 9/1/06, Paulex Yang wrote: Stepan Mishura wrote: Hi Andrew, I've just looked into static initialization block and then to the spec. for LogManager class. My impression is that Harmony implementation doesn't follow the spec. The spec. says: At startup the LogManager class is located using the ' java.util.logging.manager' system property.By default, the LogManager reads its initial configuration from a properties file lib/logging.properties in the JRE directory Stepan, I think the meaning of By default is debatable. Actually the spec looks like this: At startup the LogManager class is located using the java.util.logging.manager system property. By default, the LogManager reads its initial configuration from a properties file lib/logging.properties in the JRE directory. If you edit that property file you can change the default logging configuration for all uses of that JRE. In addition, the LogManager uses two optional system properties that allow more control over reading the initial configuration: * java.util.logging.config.class * java.util.logging.config.file... So I consider the By default doesn't necessarily means default case without java.util.logging.manager property, but means the default case without java.util.logging.config.class/file properties. A simple test on RI of specifying a customized MockLogManager by j.u.l.manager property shows the default lib/logging.properties does affect the behavior of the customized LogManager, say the root logger's level, etc. Do you mean that RI resets the root logger's level of customized LogManager to default value from lib/logging.properties? Yes, so I think customized LogManager also needs to initialize itself in same procedure as j.u.l.LogManager. Hi Paulex, I've implemented custom LogManager (see attachment): it sets value for root logger's level different from default value(INFO). According to my test (see attachment) RI doesn't change level of root logger. The test prints the following: $java -classpath . MyTest INFO $java -classpath . -Djava.util.logging.manager=CustomLogManager MyTest SEVERE Did I missed something? Stepan, I run the test under Sun JDK 1.5.0_06 for WinXP, but I got INFO printed for both cases... Paulex, thanks for your patience and answers. Yes, Sun's JRE sets root logger's level according to 'lib/logging.properties'. Also specifying the level for root logger in j.u.l.config.file doesn't help. (I assumed before that a JRE respects my lovely custom LogManager settings :-(! ) OK. Let's return to the initial issue: how to run logging tests without changing JRE config files? I still believe that there should be some elegant way for testing logging implementation without touching JRE files. For example, what about developing custom LogManager for testing? The testing manager will work in 2 modes: default configuration and custom configuration. A test will have a hook to switch testing manager's mode. The first configuration is read from JRE config files (by j.u.l.LogManager implementation) and the second one will be fully controlled by a test and is set by the test via some manager's method (say readConfiguration(InputStream)). Does this sound crazy? Thoughts? Other suggestions? 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][logging] a test suite shouldn't touch any of JRE config files!!!
Stepan Mishura wrote: Paulex, thanks for your patience and answers. Yes, Sun's JRE sets root logger's level according to 'lib/logging.properties'. Also specifying the level for root logger in j.u.l.config.file doesn't help. (I assumed before that a JRE respects my lovely custom LogManager settings :-(! ) OK. Let's return to the initial issue: how to run logging tests without changing JRE config files? I still believe that there should be some elegant way for testing logging implementation without touching JRE files. I agreed this is not acceptable. AFAIK current LogManagerTest has used a MockLogManager in most test cases, so the migration should be relatively easy. For example, what about developing custom LogManager for testing? The testing manager will work in 2 modes: default configuration and custom configuration. A test will have a hook to switch testing manager's mode. The first configuration is read from JRE config files (by j.u.l.LogManager implementation) and the second one will be fully controlled by a test and is set by the test via some manager's method (say readConfiguration(InputStream)). Does this sound crazy? Maybe we just need one Support_Exec() invocation to verify if the LogManager reads the default logging properties(jre/lib/logging.properties) correctly(which should be straightforward by also loading and parsing that properties in test codes), for other tests, we always use customized LogManager or configuration files. If you are fine with this, I'm volunteer to refactor the tests. Thoughts? Other suggestions? 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] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
On 9/5/06, Paulex Yang wrote: Stepan Mishura wrote: Paulex, thanks for your patience and answers. Yes, Sun's JRE sets root logger's level according to 'lib/logging.properties'. Also specifying the level for root logger in j.u.l.config.file doesn't help. (I assumed before that a JRE respects my lovely custom LogManager settings :-(! ) OK. Let's return to the initial issue: how to run logging tests without changing JRE config files? I still believe that there should be some elegant way for testing logging implementation without touching JRE files. I agreed this is not acceptable. AFAIK current LogManagerTest has used a MockLogManager in most test cases, so the migration should be relatively easy. For example, what about developing custom LogManager for testing? The testing manager will work in 2 modes: default configuration and custom configuration. A test will have a hook to switch testing manager's mode. The first configuration is read from JRE config files (by j.u.l.LogManager implementation) and the second one will be fully controlled by a test and is set by the test via some manager's method (say readConfiguration(InputStream)). Does this sound crazy? Maybe we just need one Support_Exec() invocation to verify if the LogManager reads the default logging properties(jre/lib/logging.properties) correctly(which should be straightforward by also loading and parsing that properties in test codes), for other tests, we always use customized LogManager or configuration files. If you are fine with this, I'm volunteer to refactor the tests. Agree with this approach. Thanks, Stepan -- 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][text] ChoiceFormat pattern parser compatibility
On 9/5/06, Denis Kishenko [EMAIL PROTECTED] wrote: People what do you think about HARMONY-1110? Problem is we have to reproduce behavior of ChoiceFormat pattern parser without specification. There is only one example in Java doc which doesn't allow understand when RI assumes that pattern is incorrect. According the sample in sepc, the rule is very straightforward except there's no explicit description about expcetional cases. IMHO, 2#ok #ab and 2#ok ab are illegal patterns, we shall follow RI. I'm a bit confused about 2|, it's illegal too. But maybe we could also follow RI if it's not too hard to follow RI. ;-) Best regards, Richard Thanks -- Denis M. Kishenko 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] -- 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: [drlvm] Cleaning insides of Class.h header
It's been long time this discussion stopped. This may mean three things: - first, everyone agrees this should be done and I'm ok to provide consecutive patches; - second, noone clearly understand the purpose of what is suggested to do; if this is the case, do not hesitate to ask (again?); - third, noone is really interested in making source code of DRLVM more readable and more understandable, and I should drop this activity. Meanwhile, I'd like to open jira and start posting patches there. Regards, Pavel. On 7/25/06, Pavel Pervov [EMAIL PROTECTED] wrote: Geir, well, it is the argument at least for me to start thinking in this direction and initiate this discussion. And there are places in VM core code where only definition of members of a class is required, but whole Class.h is included anyway. This is also about localizing potential development in separate functional groups to reduce recompilation when working intensively with these files. Hope, I answered, what you were asking about. :) Regards, Pavel. On 7/24/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Pavel Pervov wrote: On 7/24/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/7/24, Pavel Pervov [EMAIL PROTECTED]: First thing I would like to do is to split the file into a group of files, each of which would contain only one entity (and some closely related entities, if any). This would produce the following headers: 1) Class.h – constant pool and class 2) vtable.h – vtable 3) class_member.h – field and method entities descriptors, exception handler descriptor 4) cci.h – code chunk entity (part of compiled method code) Will these header files be useful separately? Yes, sure, they will be. This is one of the arguments for doing so. To whom? 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][text] ChoiceFormat pattern parser compatibility
One more example of strange RI behaviour
-
import java.text.*;
public class Test {
static void test(String pattern) {
System.err.print([ + pattern + ] );
try {
System.err.println(new ChoiceFormat(pattern).toPattern());
} catch (Exception e) {
System.err.println(e);
}
}
public static void main(String[] args) {
test(|||);
test(2#a|||);
test(1);
}
}
- Output
RI
[|||] 0.0#|0.0#|0.0#
[2#a|||] 2.0#a|2.0#|2.0#
[1] 1.0|1.0|1.0|1.0
Harmony
[|||]
[2#a|||]
[1]
2006/9/5, Richard Liang [EMAIL PROTECTED]:
On 9/5/06, Denis Kishenko [EMAIL PROTECTED] wrote:
People what do you think about HARMONY-1110?
Problem is we have to reproduce behavior of ChoiceFormat pattern parser
without
specification. There is only one example in Java doc which doesn't
allow understand when RI assumes that pattern is incorrect.
According the sample in sepc, the rule is very straightforward except
there's no explicit description about expcetional cases.
IMHO, 2#ok #ab and 2#ok ab are illegal patterns, we shall follow
RI. I'm a bit confused about 2|, it's illegal too. But maybe we
could also follow RI if it's not too hard to follow RI. ;-)
Best regards,
Richard
Thanks
--
Denis M. Kishenko
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]
--
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]
--
Denis M. Kishenko
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] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
The coverage information was updated on the wiki to current state. thanks, Vladimir
Re: [drlvm] Cleaning insides of Class.h header
+1 for cleanup, I could even assist you. Please also consider possible dependency on issue #1363. -- Regards, Alexey 2006/9/5, Pavel Pervov [EMAIL PROTECTED]: It's been long time this discussion stopped. This may mean three things: - first, everyone agrees this should be done and I'm ok to provide consecutive patches; - second, noone clearly understand the purpose of what is suggested to do; if this is the case, do not hesitate to ask (again?); - third, noone is really interested in making source code of DRLVM more readable and more understandable, and I should drop this activity. Meanwhile, I'd like to open jira and start posting patches there. Regards, Pavel. On 7/25/06, Pavel Pervov [EMAIL PROTECTED] wrote: Geir, well, it is the argument at least for me to start thinking in this direction and initiate this discussion. And there are places in VM core code where only definition of members of a class is required, but whole Class.h is included anyway. This is also about localizing potential development in separate functional groups to reduce recompilation when working intensively with these files. Hope, I answered, what you were asking about. :) Regards, Pavel. On 7/24/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Pavel Pervov wrote: On 7/24/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/7/24, Pavel Pervov [EMAIL PROTECTED]: First thing I would like to do is to split the file into a group of files, each of which would contain only one entity (and some closely related entities, if any). This would produce the following headers: 1) Class.h – constant pool and class 2) vtable.h – vtable 3) class_member.h – field and method entities descriptors, exception handler descriptor 4) cci.h – code chunk entity (part of compiled method code) Will these header files be useful separately? Yes, sure, they will be. This is one of the arguments for doing so. To whom? 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]
Re: [DRLVM] GC heap verification infrastructure
+1 from me. Another (better) approach would be to write a REMSET sanity checker. When enabled by a command-line switch it would inject an extra phase into the GC phase list (like the existing sanity checker does), and before a nursery collection it would: - do a full-heap trace, using private side metadata - Record all references that point into the nursery - when done, check this against the remset and report discrepancies. The remset should contain a superset of the references that this sanity checker finds. There's no real reason this couldn't live in MMTk permanently. Well, the checker can be a layer between VM and GC. In C variant of write barriers it just inject some code before actual GC's write barrier which does mirroring of slot. When doing the full-heap trace it can compare slots and its mirrors (even not possessing information about organization of heap, e.g nurseries). -- Ivan - 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]A subject to profiling instrumenting
Hi Qiong, What do you think about putting your diffs to the JIRA? Doing this way we can write and test the code together? Apache gurus, is JIRA the standard tool to simulate SVN branching for developers that are not commiters? Should we gain some success in a feature implementation before we get a commiter's help and separate branch in SVN? On 9/4/06, zouqiong [EMAIL PROTECTED] wrote: 在06-9-4，Salikh Zakirov [EMAIL PROTECTED] 写道： zouqiong wrote: I am now doing two things: 1. track accesses to the three things you refer. And just the same implementation as some rt_helper_***, but the following error happens: java.exec: /root/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg_ia32.cpp： 1621： void Jitrino::Jet::Compiler::gen_patch(const char*, const Jitrino::Jet::CodePatchItem): 断言cpi.target_offset != 0失败。 abort_handler() This error has been fixed. But I still want to know How to dump out the native code generated by the VM. Should the liblwdis.so be written by ourselves? Now, although the above error has been resolved, I encounter an new issue. SIGSEGV in VM code. This error seems some error happens in generated code. This issue has been solved. Thanks. Segmentation faults in compiled java code are always treated as NullPointerException, no matter what address or operation caused a segmentation fault. SIGSEGV in VM code. means that the segmentation code occured in C++ code of the VM. gdb should be of much help in this case. - 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, Qiong,Zou -- Mikhail Fursov
Re: [jira] Assigned: (HARMONY-1297) Dependencies for awt native libraries
Alexey I think putting some third-party code into JIRA and downloading it on the fly when build means that we redistribute that third-party code. We intenationally do it for yoko.jar, because we've discussed here that we host it. My question is: did we discussed here that we redistribute 3rd-party awt code? Thanks, Mikhail 2006/9/5, Mikhail Loenko (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1297?page=all ] Mikhail Loenko reassigned HARMONY-1297: --- Assignee: Mikhail Loenko Dependencies for awt native libraries - Key: HARMONY-1297 URL: http://issues.apache.org/jira/browse/HARMONY-1297 Project: Harmony Issue Type: Improvement Components: Classlib Environment: Win32 Reporter: Alexey Petrenko Assigned To: Mikhail Loenko Attachments: awt_win32_depends.zip, HARMONY-1297.diff Dependencies for awt native libraries for Windows platform. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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][text] ChoiceFormat pattern parser compatibility
Wow, How many examples do you have? ;-)
As ChoiceFormat is a format engine, it's impossible to list all the
exceptional cases.
IMHO, maybe we could 1) *guess* the rules behind RI's strange behavior
by adding more test cases. 2) try our best to implement the rules of
RI. 3) And then, leave this issue as bug-driven, that is, if there are
user applications fail due to the difference between RI and Harmony,
we fix our code.
Does it make sense? Thanks a lot.
Best regards,
Richard
On 9/5/06, Denis Kishenko [EMAIL PROTECTED] wrote:
One more example of strange RI behaviour
-
import java.text.*;
public class Test {
static void test(String pattern) {
System.err.print([ + pattern + ] );
try {
System.err.println(new ChoiceFormat(pattern).toPattern());
} catch (Exception e) {
System.err.println(e);
}
}
public static void main(String[] args) {
test(|||);
test(2#a|||);
test(1);
}
}
- Output
RI
[|||] 0.0#|0.0#|0.0#
[2#a|||] 2.0#a|2.0#|2.0#
[1] 1.0|1.0|1.0|1.0
Harmony
[|||]
[2#a|||]
[1]
2006/9/5, Richard Liang [EMAIL PROTECTED]:
On 9/5/06, Denis Kishenko [EMAIL PROTECTED] wrote:
People what do you think about HARMONY-1110?
Problem is we have to reproduce behavior of ChoiceFormat pattern parser
without
specification. There is only one example in Java doc which doesn't
allow understand when RI assumes that pattern is incorrect.
According the sample in sepc, the rule is very straightforward except
there's no explicit description about expcetional cases.
IMHO, 2#ok #ab and 2#ok ab are illegal patterns, we shall follow
RI. I'm a bit confused about 2|, it's illegal too. But maybe we
could also follow RI if it's not too hard to follow RI. ;-)
Best regards,
Richard
Thanks
--
Denis M. Kishenko
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]
--
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]
--
Denis M. Kishenko
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]
--
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: [drlvm] DRLVM, jre/bin/default and launcher
HI All, Good news! I have a patch to run DRLVM with the classlib's launcher (I've checked Hello and Eclipse applications on Windows only). Actually, there are two patches. The first one is for classlib which changes vm default directory to drlvm. The second one is for build system and VM itself. Unfortunatelly, it is impossible to eliminate all problems in a short period of time. There is still a bunch of work in initialization and jni modules. So this patch is just a one more step to our goal. The vm patch is quite heavy so I attach it and classlib patch. Hope it will work not only for me :-) On 9/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix the DRLVM layout - rename vmcore to harmonyvm and move ..dll/.so into the default subdirectory such that one doesn't have to type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be the only Harmony VM. On the contrary, I thought Harmony project is about *encouraging* diversity. I think having library named libdrlvm.so would be much better. No - the launcher picks up the vm from harmonyvm.dll (or .so) so that's what we'll name it. Then it makes it easy. put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm and then java -vmdir:j9 or java -vmdir:drlvm etc geir 2. Exclude building of the original launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called java). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). - 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: [doc] no images on website pages
Morozova, Nadezhda wrote: Best regards, Nadya Morozova Folks, I have just submitted a patch that fixing the conflict in styles on the website [1]. When doing this, I noticed another issue with the docs deployed: There are no images! The image files used in individual documents are stored in the SVN repository at their initial location and not copied into the website. This way, the links are broken. What do we do with this? I see at least 2 solutions: 1. Move the images to corresponding folders in the website (for example, site/docs/subcomponents/drlvm/images) and configure SVN to make a read-only copy from there to the initial location of files Yes. We should just move them. 2. Leave as is and change the links to the images: add checkout links instead specifying the current location of the file Any other suggestions? Your feedback is most welcome. Cheers, Nadya [1] JIRA issue 1384, https://issues.apache.org/jira/browse/HARMONY-1384 - 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: [jira] Assigned: (HARMONY-1297) Dependencies for awt native libraries
Mikhail Loenko wrote: Alexey I think putting some third-party code into JIRA and downloading it on the fly when build means that we redistribute that third-party code. We intenationally do it for yoko.jar, because we've discussed here that we host it. My question is: did we discussed here that we redistribute 3rd-party awt code? No. I'm not sure what the best thing is, but putting in third party source code in SVN isn't going to happen. This was near the top of my list of things to look at when I got back from this little teeny vacation I'm on. Worst case, we can setup a binary distro somewhere (like sourceforge) with a SDK for it to make it easy for people to download and build. geir Thanks, Mikhail 2006/9/5, Mikhail Loenko (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1297?page=all ] Mikhail Loenko reassigned HARMONY-1297: --- Assignee: Mikhail Loenko Dependencies for awt native libraries - Key: HARMONY-1297 URL: http://issues.apache.org/jira/browse/HARMONY-1297 Project: Harmony Issue Type: Improvement Components: Classlib Environment: Win32 Reporter: Alexey Petrenko Assigned To: Mikhail Loenko Attachments: awt_win32_depends.zip, HARMONY-1297.diff Dependencies for awt native libraries for Windows platform. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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]A subject to profiling instrumenting
Hi, Mikhail: Ok, I will put my diffs to the JIRA later. And I have solved the issue I asked two days ago. I want to know how to use the option -Xdumpfile, It needs liblwdis.sosupporting. If it need to be written by ourselves, I will finish it. If not, could you please tell me where can I get it? Thanks. 在06-9-5，Mikhail Fursov [EMAIL PROTECTED] 写道： Hi Qiong, What do you think about putting your diffs to the JIRA? Doing this way we can write and test the code together? Apache gurus, is JIRA the standard tool to simulate SVN branching for developers that are not commiters? Should we gain some success in a feature implementation before we get a commiter's help and separate branch in SVN? On 9/4/06, zouqiong [EMAIL PROTECTED] wrote: 在06-9-4，Salikh Zakirov [EMAIL PROTECTED] 写道： zouqiong wrote: I am now doing two things: 1. track accesses to the three things you refer. And just the same implementation as some rt_helper_***, but the following error happens: java.exec: /root/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg_ia32.cpp： 1621： void Jitrino::Jet::Compiler::gen_patch(const char*, const Jitrino::Jet::CodePatchItem): 断言cpi.target_offset != 0失败。 abort_handler() This error has been fixed. But I still want to know How to dump out the native code generated by the VM. Should the liblwdis.so be written by ourselves? Now, although the above error has been resolved, I encounter an new issue. SIGSEGV in VM code. This error seems some error happens in generated code. This issue has been solved. Thanks. Segmentation faults in compiled java code are always treated as NullPointerException, no matter what address or operation caused a segmentation fault. SIGSEGV in VM code. means that the segmentation code occured in C++ code of the VM. gdb should be of much help in this case. - 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, Qiong,Zou -- Mikhail Fursov -- Best Regards, Qiong,Zou
Re: [DRLVM][GC] MMTk port now ready for write barrier integration
On 9/4/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Weldon, what is the user-mode? Thanks for asking. Basically I call MMTk's object alloc() routine from java application code instead of from DRLVM JIT runtime helper. I use vmmagic to patch up stuff. The trick is to hide the objects allocated out of MMTk's heap from the underlying GCV4. For more detail, please look at drlvm/trunk/vm/mmtk/*.java files. -- Ivan On 9/1/06, Weldon Washburn [EMAIL PROTECTED] wrote: All, A late night IM debug session with Steve Blackburn got the DRLVM/MMTk port to the point where it makes sense to try write barrier integration. All the mods I have been working on plus simple gc regression tests have been committed to drlvm\trunk\vm\mmtk. DRLVM/MMTk now runs the following garabage collector algorithms in user-mode: marksweep semispace copyms genms (with IGNORE_REMSETS = true) By setting IGNORE_REMSETS=false, MMTk depends on fully implemented, correct write barriers to do its job. -- Weldon Washburn Intel Middleware Products Division -- Ivan 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] -- Weldon Washburn Intel Middleware Products Division
[DRLVM][GC] MMTk w/ Jitrino.JET write barrier now pass simple tests
Using MMTk's GenMS collector, I was able to cause an object to be promoted to mature generation. Then write the ref ptr of nursery object X in a slot of the mature object. This caused the write barrier to add the mature object to the remembered set. Then a bunch of throw away objects were allocated which causes a nursery collection and object X gets promoted to mature generation. Details on how this test is constructed is in TestGenMS.java. The next step is to revector Jitrino.JET object allocation helper so that I calls MMTk java alloc() method instead of C code. I will start a seperate email thiread on this topic shortly. -- Weldon Washburn Intel Middleware Products Division
[DRLVM][JIT] can Jitrino.JET call MMTk alloc() instead of C helper?
A question for Jitrino.JET developers. How hard would it be to modify the existing Jitrino.JET code so that the new opcode calls MMTk alloc()? Thanks -- Weldon Washburn Intel Middleware Products Division
Re: [drlvm] DRLVM, jre/bin/default and launcher
Hi Geir, It seems not all of us are able to see my attachments :-( I've created new jira HARMONY-1390 with attachments. Thanks Evgueni. On 9/6/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: HI All, Good news! I have a patch to run DRLVM with the classlib's launcher (I've checked Hello and Eclipse applications on Windows only). Actually, there are two patches. The first one is for classlib which changes vm default directory to drlvm. The second one is for build system and VM itself. Unfortunatelly, it is impossible to eliminate all problems in a short period of time. There is still a bunch of work in initialization and jni modules. So this patch is just a one more step to our goal. The vm patch is quite heavy so I attach it and classlib patch. Hope it will work not only for me :-) On 9/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix the DRLVM layout - rename vmcore to harmonyvm and move ..dll/.so into the default subdirectory such that one doesn't have to type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be the only Harmony VM. On the contrary, I thought Harmony project is about *encouraging* diversity. I think having library named libdrlvm.so would be much better. No - the launcher picks up the vm from harmonyvm.dll (or .so) so that's what we'll name it. Then it makes it easy. put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm and then java -vmdir:j9 or java -vmdir:drlvm etc geir 2. Exclude building of the original launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called java). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). - 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: [result] Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
Seems like a new patch is a better way. If apply it as is then some tests fail some hang up... Thanks, Mikhail 2006/8/31, Geir Magnusson Jr. [EMAIL PROTECTED]: Well, that's 3 days :) +1 from geir, alexey, vladimir, Ilya, the other alexey, sergey, mark, oleg, paulex, mikhail, kenny, no other votes (other than interest in getting the dependency thing fixed once and for all, and some chat about patching the patch) so this passes. Once we finish arguing about *how* it should be committed, I'll be happy to commit it so people can focus new work on it. geir Geir Magnusson Jr wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. 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]
