Re: [classlib]volunteer to supply patches for old JIRAs
Paulex Yang 写道: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. There are already JIRA categorized as Non-bug differences from RI(JIRA 858), shall we just close it or leave it as-is. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- 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: [drlvm] Need help debugging
vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp
...
* /*
*// skip Thread.runImpl()
size--;
// skip the VMStart$MainThread if one exits from the bottom of the stack
// along with 2 reflection frames used to invoke method main
static String* starter_String =
genv-string_pool.lookup(java/lang/VMStart$MainThread);
Method_Handle method = frames[size].method;
assert(method);
// skip only for main application thread
if (!strcmp(method_get_name(method), runImpl)
method-get_class()-name == starter_String) {
int rem = size - skip-1;
size -= rem 2 ? rem : 2;
}
ASSERT(size = skip, Trying to skip skip
frames but there are only
size frames in stack);
**/*
...
Thanks,
Vladimir.
On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I was able to sucessfully run both applications (Eclipse ActiveMQ) for
the
recent build.
what changed?
geir
Thanks,
Vladimir.
On 9/12/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
doh. Thanks. I feel dumb for not trying the simplest thing first :)
There's a test...
geir
Anton Luht wrote:
Hello,
The 'java -jar' launcher prints dump and exits even on a minimal
HelloWorld app jar - please see
http://issues.apache.org/jira/browse/HARMONY-1444
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
No, I used hand-made build from SVN.
BTW, sorry for confusion about 'broken data'. The pointer value is
changed inside the method - this assignment should be removed.
On 9/12/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
Did you run this application for the recent binaries got from the
SVN
sources?
As for me my results differ from Geir ones, namely, DRLVM crashes
for both
Windows Linux as follows:
===
Windows
===
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo JAVA_HOME
JAVA_HOME
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo $CLASSPATH
c:/Tools/incubator-activemq-4.0/lib
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ which java
/cygdrive/c/DrlSrc/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/java
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ bin/activemq
cygpath: can't convert empty path
An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=00F3D648
ContextFlags=0001003f
Handler1=00401010
Handler2=11105D20
InaccessibleAddress=00F3D648
EDI=0013F9D4
ESI=0013F768
EAX=
EBX=000B
ECX=0001
EDX=000C
EIP=00F3D648
ESP=0013F764
EBP=0013F770
Module=
Module_base_address=00F3
Offset_in_DLL=d648
Linux
sh bin/activemq
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/exception/exceptions.cpp:143:
_jobject* create_exception(const char*): Assertion
`hythread_is_suspend_enabled()' failed.
abort_handler()
Aborted
Thanks,
Vladimir.
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
I'm observing the same problem - ActiveMQ can't start - on DRLVM
+
Classlibrary build 442240 .
The problem I see first is that in
classlib
root\modules\luni\src\main\native\launcher\shared\main.c
in function 'static int invocation' after call 'createVMArgs'
variable
'mainClassJar' contains garbale while in the very end of 'static
int
createVMArgs' it contains valid string
'org.apache.harmony.kernel.vm.JarRunner' . If we comment out
'hymem_allocate_memory' in that function:
if (isStandaloneJar)
{
if (useDefaultJarRunner == 0)
{
//:::commented out mainClassJar =
hymem_allocate_memory (50);
if (mainClassJar == NULL)
the application will crash a little later. Note: we can comment
this
out because memory for mainClassJar is already allocated in the
calling method.
I believe that the general problem is that contents of memory
alocated
with hymem_allocate_memory get somehow broken on exit from a
method.
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I applied the GCv4.1 patch and now I pass smoke test. I
suspect
it may
be because the patch modifies the LOS test, but I'm not so
sure.
that patch (HARMONY-1269) is a sole-author patch to our
existing
codebase, and while I do have a BCC to put in SVN, I think
that
this is
a patch, and not a bulk contribution, so I'll go forward and
commit
it.
geir
Geir Magnusson Jr. wrote:
More news - I'm not passing the smoke tests. gc.LOC just
spins
(and
sucks a lot of memory in).
Clearly what I thought were trivial changes to switch to use
the
launcher had hidden effects. Any suggestions where to start
looking?
geir
Re: [classlib]volunteer to supply patches for old JIRAs
I think that we should close non-bug defferencies as wont fix or something like that. 2006/9/13, Spark Shen [EMAIL PROTECTED]: Paulex Yang 写道: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. There are already JIRA categorized as Non-bug differences from RI(JIRA 858), shall we just close it or leave it as-is. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- 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] -- Alexey A. Petrenko Intel Middleware Products Division
Re: [drlvm] putting kernel.jar in jre/bin/default
2006/9/13, Paulex Yang [EMAIL PROTECTED]: Alexey Varlamov wrote: Looks like sending my reply failed, here is a second try: I'm not sure I catch up what you mean, about Emma, Harmony's current test coverage exclude list[1] shows that not all classes can be instrumented, I don't think it is due to the position of kernel classes. Paulex, I'm sorry for causing confusion - I was a bit wrong. I experienced troubles with complete overriiding via -Xbootclasspath: argument, and just prepending -Xbootclasspath/p: works OK. Not all kernel classes are instrumented due to dependencies in instrumentation code itself, this is of course different thing. Agreed. Further, for the special requirement(instrument, AOP, or so), anything prevent the user to add -Xbootclasspath/p to replace the kernel class implementation? Or, what's the difference on this between RI and current Harmony? So the difference is that for -Xbootclasspath:, launcher+j9 always stealthily prepend luni-kernel.jar to user-specified bootclasspath, while RI allows fully custom bootclasspath. This is interesting. Yes, I think we should handle it, although it probably won't work to replace the kernel class implementation due to the VM dependency, we have no reason forbidding user to do this. Just had a look at how the normal bootclasspath(luni.jar, text.jar...) is processed, the interesting thing is they are loaded by JNI_OnLoad of hyluni.dll(libhyluni.so), with the source codes located in modules/luni/src/native/luni/shared/luniglob.c (It is interesting because I thought it was in launcher, but maybe the original author had similar issues to get the absolute path of jre/lib/boot). And it takes a straightforward way to handle the -Xbootclasspath: if this argument is passed in command line, just give up parsing the default bootclasspath. I have two thoughts on this: 1. If this is acceptable, we can deal with kernel class in similar way. 2. Supposing we can have better solution to locate the jre path, is there any chance to merge the both bootclasspath handling(kernel and normal) to launcher, so that it doesn't need to deal with bootclasspath twice? Or any other proposals? We had a discussion about this month ago [1], and the main argument against the launcher was there may be several launchers, moreover bootclasspath has to be set for any application that calls JNI_CreateJavaVM. So no better place than luni natives was suggested for the shared part of the bootlclasspath. BTW, there is reliability fix HARMONY-1243 related to this and still unresolved... But as kernel classes packaging is VM-specific, the VM should take care of them. Evidently the same argument about launcher applies to kernels as well, so current way with harmonyvm.properties is a sort of workaround anyway. And to handle the -Xbooclasspath: issue, there should be double filtering: check user-supplied arguments then filter autoloaded ones from harmonyvm.properties. Smells not really good ;). More logical would be to get rid of handling harmonyvm.properties in launcher entirely, leaving this to VM if it needs it. [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/11776/focus=11818 -- 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] - 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]volunteer to supply patches for old JIRAs
Nathan Beyer 写道: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. There are also very specific cases. Some JIRAs are about kernal classes( e.p. JIRA 921). When IBM vm is concerned, they are not in the scope of Harmony project. It is better be feeded back to IBM. When DRLVM is concerned, we may solve it in the scope of Harmony project. So I suggest to split JIRA 921 into two JIRAs. One for DRLVM, one for IBM vm. Any suggestions? -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. 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 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]volunteer to supply patches for old JIRAs
Spark Shen wrote: Paulex Yang 写道: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. There are already JIRA categorized as Non-bug differences from RI(JIRA 858), shall we just close it or leave it as-is. Those should be a log, rather than bugs to work on... geir And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. - 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]volunteer to supply patches for old JIRAs
Spark Shen wrote: Paulex Yang 写道: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. There are already JIRA categorized as Non-bug differences from RI(JIRA 858), shall we just close it or leave it as-is. Those should be a log, rather than bugs to work on... geir And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. - 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] Need help debugging
I'm a little skeptical, as I had that change in before you first tested
and found a problem, right?
geir
Vladimir Gorr wrote:
vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp
...
* /*
*// skip Thread.runImpl()
size--;
// skip the VMStart$MainThread if one exits from the bottom of the stack
// along with 2 reflection frames used to invoke method main
static String* starter_String =
genv-string_pool.lookup(java/lang/VMStart$MainThread);
Method_Handle method = frames[size].method;
assert(method);
// skip only for main application thread
if (!strcmp(method_get_name(method), runImpl)
method-get_class()-name == starter_String) {
int rem = size - skip-1;
size -= rem 2 ? rem : 2;
}
ASSERT(size = skip, Trying to skip skip
frames but there are only
size frames in stack);
**/*
...
Thanks,
Vladimir.
On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I was able to sucessfully run both applications (Eclipse ActiveMQ)
for
the
recent build.
what changed?
geir
Thanks,
Vladimir.
On 9/12/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
doh. Thanks. I feel dumb for not trying the simplest thing first :)
There's a test...
geir
Anton Luht wrote:
Hello,
The 'java -jar' launcher prints dump and exits even on a minimal
HelloWorld app jar - please see
http://issues.apache.org/jira/browse/HARMONY-1444
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
No, I used hand-made build from SVN.
BTW, sorry for confusion about 'broken data'. The pointer value is
changed inside the method - this assignment should be removed.
On 9/12/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
Did you run this application for the recent binaries got from the
SVN
sources?
As for me my results differ from Geir ones, namely, DRLVM crashes
for both
Windows Linux as follows:
===
Windows
===
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo JAVA_HOME
JAVA_HOME
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo $CLASSPATH
c:/Tools/incubator-activemq-4.0/lib
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ which java
/cygdrive/c/DrlSrc/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/java
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ bin/activemq
cygpath: can't convert empty path
An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=00F3D648
ContextFlags=0001003f
Handler1=00401010
Handler2=11105D20
InaccessibleAddress=00F3D648
EDI=0013F9D4
ESI=0013F768
EAX=
EBX=000B
ECX=0001
EDX=000C
EIP=00F3D648
ESP=0013F764
EBP=0013F770
Module=
Module_base_address=00F3
Offset_in_DLL=d648
Linux
sh bin/activemq
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/exception/exceptions.cpp:143:
_jobject* create_exception(const char*): Assertion
`hythread_is_suspend_enabled()' failed.
abort_handler()
Aborted
Thanks,
Vladimir.
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
I'm observing the same problem - ActiveMQ can't start - on
DRLVM
+
Classlibrary build 442240 .
The problem I see first is that in
classlib
root\modules\luni\src\main\native\launcher\shared\main.c
in function 'static int invocation' after call 'createVMArgs'
variable
'mainClassJar' contains garbale while in the very end of
'static
int
createVMArgs' it contains valid string
'org.apache.harmony.kernel.vm.JarRunner' . If we comment out
'hymem_allocate_memory' in that function:
if (isStandaloneJar)
{
if (useDefaultJarRunner == 0)
{
//:::commented out mainClassJar =
hymem_allocate_memory (50);
if (mainClassJar == NULL)
the application will crash a little later. Note: we can comment
this
out because memory for mainClassJar is already allocated in the
calling method.
I believe that the general problem is that contents of memory
alocated
with hymem_allocate_memory get somehow broken on exit from a
method.
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I applied the GCv4.1 patch and now I pass smoke test. I
suspect
it may
be because the patch modifies the LOS test, but I'm not so
sure.
that patch (HARMONY-1269) is a sole-author patch to our
existing
codebase, and while I do have a BCC to put in SVN, I think
that
this is
a patch, and not a bulk contribution, so I'll go forward
and
commit
it.
geir
Geir Magnusson Jr. wrote:
More news - I'm not passing the smoke tests. gc.LOC just
spins
(and
sucks a lot of memory in).
Clearly what I
Re: [classlib]volunteer to supply patches for old JIRAs
Geir Magnusson Jr. 写道: Spark Shen wrote: Paulex Yang 写道: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. There are already JIRA categorized as Non-bug differences from RI(JIRA 858), shall we just close it or leave it as-is. Those should be a log, rather than bugs to work on... So, we will leave it as-is. geir And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Need help debugging
Hello,
With a very fresh build: DRLVM + classlib
svn = r442859, (Sep 13 2006), Windows/ia32/msvc 1310, debug build
I see no problems with 'java -version' (and I've never seen) but still
see the problems with '-jar ...' launching .
On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm a little skeptical, as I had that change in before you first tested
and found a problem, right?
geir
Vladimir Gorr wrote:
vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp
...
* /*
*// skip Thread.runImpl()
size--;
// skip the VMStart$MainThread if one exits from the bottom of the stack
// along with 2 reflection frames used to invoke method main
static String* starter_String =
genv-string_pool.lookup(java/lang/VMStart$MainThread);
Method_Handle method = frames[size].method;
assert(method);
// skip only for main application thread
if (!strcmp(method_get_name(method), runImpl)
method-get_class()-name == starter_String) {
int rem = size - skip-1;
size -= rem 2 ? rem : 2;
}
ASSERT(size = skip, Trying to skip skip
frames but there are only
size frames in stack);
**/*
...
Thanks,
Vladimir.
On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I was able to sucessfully run both applications (Eclipse ActiveMQ)
for
the
recent build.
what changed?
geir
Thanks,
Vladimir.
On 9/12/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
doh. Thanks. I feel dumb for not trying the simplest thing first :)
There's a test...
geir
Anton Luht wrote:
Hello,
The 'java -jar' launcher prints dump and exits even on a minimal
HelloWorld app jar - please see
http://issues.apache.org/jira/browse/HARMONY-1444
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
No, I used hand-made build from SVN.
BTW, sorry for confusion about 'broken data'. The pointer value is
changed inside the method - this assignment should be removed.
On 9/12/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
Did you run this application for the recent binaries got from the
SVN
sources?
As for me my results differ from Geir ones, namely, DRLVM crashes
for both
Windows Linux as follows:
===
Windows
===
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo JAVA_HOME
JAVA_HOME
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo $CLASSPATH
c:/Tools/incubator-activemq-4.0/lib
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ which java
/cygdrive/c/DrlSrc/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/java
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ bin/activemq
cygpath: can't convert empty path
An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=00F3D648
ContextFlags=0001003f
Handler1=00401010
Handler2=11105D20
InaccessibleAddress=00F3D648
EDI=0013F9D4
ESI=0013F768
EAX=
EBX=000B
ECX=0001
EDX=000C
EIP=00F3D648
ESP=0013F764
EBP=0013F770
Module=
Module_base_address=00F3
Offset_in_DLL=d648
Linux
sh bin/activemq
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/exception/exceptions.cpp:143:
_jobject* create_exception(const char*): Assertion
`hythread_is_suspend_enabled()' failed.
abort_handler()
Aborted
Thanks,
Vladimir.
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
I'm observing the same problem - ActiveMQ can't start - on
DRLVM
+
Classlibrary build 442240 .
The problem I see first is that in
classlib
root\modules\luni\src\main\native\launcher\shared\main.c
in function 'static int invocation' after call 'createVMArgs'
variable
'mainClassJar' contains garbale while in the very end of
'static
int
createVMArgs' it contains valid string
'org.apache.harmony.kernel.vm.JarRunner' . If we comment out
'hymem_allocate_memory' in that function:
if (isStandaloneJar)
{
if (useDefaultJarRunner == 0)
{
//:::commented out mainClassJar =
hymem_allocate_memory (50);
if (mainClassJar == NULL)
the application will crash a little later. Note: we can comment
this
out because memory for mainClassJar is already allocated in the
calling method.
I believe that the general problem is that contents of memory
alocated
with hymem_allocate_memory get somehow broken on exit from a
method.
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I applied the GCv4.1 patch and now I pass smoke test. I
suspect
it may
be because the patch modifies the LOS test,
Re: [general] Marking JIRA issues before creation of patches.
If I am going to work with whole module then Harmony class library development status[1] page is useful but if I want to work with several classes, for example fix some JAPI issues or make serious changes, then existing wiki page can't be used. I agree with creating JIRA issue and sending notification to dev-list, but I think more detailed status list is necessary, not only modules but packages and classes too. [1] http://wiki.apache.org/harmony/component_development_status 2006/9/7, Paulex Yang [EMAIL PROTECTED]: Geir Magnusson Jr. wrote: Good. Also, don't just do things in JIRA. Add the comment in JIRA, but also send something to the dev list. That way, people who are interested will more easily notice and maybe offer to help, or such... +1, and for classlib, we have had some wiki pages[1]-[3] to list the ToDos and to record who is doing or has interest on what. [1] http://wiki.apache.org/harmony/component_development_status [2] http://wiki.apache.org/harmony/Excluded_tests [3] http://wiki.apache.org/harmony/ClassLibrary geir Oleg Khaschansky wrote: Hi all, There were situations when several people started work on the same issue simultaneously. This happens because it is impossible to assign an issue to a non-committer. I suggest the following process to prevent these collisions: 1. If non-committer starts investigation and is pretty sure that he will proceed with the patch then he adds a comment like starting investigation to the JIRA issue. Maybe we should have a special keyword for this to make a search easier. 2. If for some reason he is unable to provide the patch, he adds a comment about this also. What do you think about this? -- Oleg - 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] -- 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] -- 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: [drlvm] Need help debugging
Probably, you didn't note I've commented this fragment of code (firts last
lines).
Sorry I didn't mention about this before. After these changes I could
sucessfully start the ActiveMQ.
Before I have the following error:
Assertion failed: size = skip
Trying to skip 6 frames but there are only 5 frames in stack
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/kernel_classes/native/org_apache_harmony_vm_VMStack.cpp:301:
_jobject* Java_org_apache_harmony_vm_VMStack_getStackTrace(JNIEnv*,
_jobject*, _jobject*): Assertion `size = skip' failed.
abort_handler()
Thanks,
Vladimir.
On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm a little skeptical, as I had that change in before you first tested
and found a problem, right?
geir
Vladimir Gorr wrote:
vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp
...
* /*
*// skip Thread.runImpl()
size--;
// skip the VMStart$MainThread if one exits from the bottom of the
stack
// along with 2 reflection frames used to invoke method main
static String* starter_String =
genv-string_pool.lookup(java/lang/VMStart$MainThread);
Method_Handle method = frames[size].method;
assert(method);
// skip only for main application thread
if (!strcmp(method_get_name(method), runImpl)
method-get_class()-name == starter_String) {
int rem = size - skip-1;
size -= rem 2 ? rem : 2;
}
ASSERT(size = skip, Trying to skip skip
frames but there are only
size frames in stack);
**/*
...
Thanks,
Vladimir.
On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I was able to sucessfully run both applications (Eclipse ActiveMQ)
for
the
recent build.
what changed?
geir
Thanks,
Vladimir.
On 9/12/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
doh. Thanks. I feel dumb for not trying the simplest thing first
:)
There's a test...
geir
Anton Luht wrote:
Hello,
The 'java -jar' launcher prints dump and exits even on a minimal
HelloWorld app jar - please see
http://issues.apache.org/jira/browse/HARMONY-1444
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
No, I used hand-made build from SVN.
BTW, sorry for confusion about 'broken data'. The pointer value
is
changed inside the method - this assignment should be removed.
On 9/12/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
Did you run this application for the recent binaries got from
the
SVN
sources?
As for me my results differ from Geir ones, namely, DRLVM
crashes
for both
Windows Linux as follows:
===
Windows
===
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo JAVA_HOME
JAVA_HOME
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo $CLASSPATH
c:/Tools/incubator-activemq-4.0/lib
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ which java
/cygdrive/c/DrlSrc/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/java
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ bin/activemq
cygpath: can't convert empty path
An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=00F3D648
ContextFlags=0001003f
Handler1=00401010
Handler2=11105D20
InaccessibleAddress=00F3D648
EDI=0013F9D4
ESI=0013F768
EAX=
EBX=000B
ECX=0001
EDX=000C
EIP=00F3D648
ESP=0013F764
EBP=0013F770
Module=
Module_base_address=00F3
Offset_in_DLL=d648
Linux
sh bin/activemq
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/exception/exceptions.cpp:143:
_jobject* create_exception(const char*): Assertion
`hythread_is_suspend_enabled()' failed.
abort_handler()
Aborted
Thanks,
Vladimir.
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
I'm observing the same problem - ActiveMQ can't start - on
DRLVM
+
Classlibrary build 442240 .
The problem I see first is that in
classlib
root\modules\luni\src\main\native\launcher\shared\main.c
in function 'static int invocation' after call 'createVMArgs'
variable
'mainClassJar' contains garbale while in the very end of
'static
int
createVMArgs' it contains valid string
'org.apache.harmony.kernel.vm.JarRunner' . If we comment out
'hymem_allocate_memory' in that function:
if (isStandaloneJar)
{
if (useDefaultJarRunner == 0)
{
//:::commented out mainClassJar =
hymem_allocate_memory (50);
if (mainClassJar == NULL)
the application will crash a little later. Note: we can
comment
this
out because memory for mainClassJar is already allocated in
the
calling
Re: [classlib]volunteer to supply patches for old JIRAs
2006/9/13, Spark Shen [EMAIL PROTECTED]: Nathan Beyer 写道: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. There are also very specific cases. Some JIRAs are about kernal classes( e.p. JIRA 921). When IBM vm is concerned, they are not in the scope of Harmony project. It is better be feeded back to IBM. When DRLVM is concerned, we may solve it in the scope of Harmony project. So I suggest to split JIRA 921 into two JIRAs. One for DRLVM, one for IBM vm. Did you check this is applicable to both VMs? If it is for DRLVM only, then better just change component (and summary prefix ;)). Any suggestions? -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. 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 - 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: [drlvm] putting kernel.jar in jre/bin/default
Alexey Varlamov wrote: 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Alexey Varlamov wrote: Looks like sending my reply failed, here is a second try: I'm not sure I catch up what you mean, about Emma, Harmony's current test coverage exclude list[1] shows that not all classes can be instrumented, I don't think it is due to the position of kernel classes. Paulex, I'm sorry for causing confusion - I was a bit wrong. I experienced troubles with complete overriiding via -Xbootclasspath: argument, and just prepending -Xbootclasspath/p: works OK. Not all kernel classes are instrumented due to dependencies in instrumentation code itself, this is of course different thing. Agreed. Further, for the special requirement(instrument, AOP, or so), anything prevent the user to add -Xbootclasspath/p to replace the kernel class implementation? Or, what's the difference on this between RI and current Harmony? So the difference is that for -Xbootclasspath:, launcher+j9 always stealthily prepend luni-kernel.jar to user-specified bootclasspath, while RI allows fully custom bootclasspath. This is interesting. Yes, I think we should handle it, although it probably won't work to replace the kernel class implementation due to the VM dependency, we have no reason forbidding user to do this. Just had a look at how the normal bootclasspath(luni.jar, text.jar...) is processed, the interesting thing is they are loaded by JNI_OnLoad of hyluni.dll(libhyluni.so), with the source codes located in modules/luni/src/native/luni/shared/luniglob.c (It is interesting because I thought it was in launcher, but maybe the original author had similar issues to get the absolute path of jre/lib/boot). And it takes a straightforward way to handle the -Xbootclasspath: if this argument is passed in command line, just give up parsing the default bootclasspath. I have two thoughts on this: 1. If this is acceptable, we can deal with kernel class in similar way. 2. Supposing we can have better solution to locate the jre path, is there any chance to merge the both bootclasspath handling(kernel and normal) to launcher, so that it doesn't need to deal with bootclasspath twice? Or any other proposals? We had a discussion about this month ago [1], and the main argument against the launcher was there may be several launchers, moreover bootclasspath has to be set for any application that calls JNI_CreateJavaVM. So no better place than luni natives was suggested for the shared part of the bootlclasspath. BTW, there is reliability fix HARMONY-1243 related to this and still unresolved... OK, I'll look at it. But as kernel classes packaging is VM-specific, the VM should take care of them. Evidently the same argument about launcher applies to kernels as well, so current way with harmonyvm.properties is a sort of workaround anyway. And to handle the -Xbooclasspath: issue, there should be double filtering: check user-supplied arguments then filter autoloaded ones from harmonyvm.properties. Smells not really good ;). That's what I meant... More logical would be to get rid of handling harmonyvm.properties in launcher entirely, leaving this to VM if it needs it. I thought about this, but launcher actually uses standard invocation API to create VM, so if VM's invocation API implementation takes care of the kernel class(which are part of Harmony VMI), it's a little difficult for VM vendor to provide an adaptive VM, adaptive here means it can adapt Harmony classlib as well as others without too much effort, say, GNU Classpath(or maybe Sun's Open Sourced Classlib). I still prefer to handle the Harmony VMI related things in *Harmony* Launcher. And anyway, if the normal bootclasspath should be taken care of in luni, while kernel bootclasspath must be dealed with elsewhere, the double filtering is hard to avoid, [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/11776/focus=11818 -- 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] - 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]
[classlib][pack200] Patch in queue
Is anyone able to apply http://issues.apache.org/jira/browse/HARMONY-1386 into the codebase? It's basically more of the same; but I'm waiting until it's applied and I've updated before continuing with development. Thanks, Alex. - 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] Commented: (HARMONY-1439) [classlib][swing] javax.swing.JEditorPaneTest failed
Mikhail, I have looked at this issue again and others testing issues. Let's stay this issue as is. Yesterday I didn't clearly understand build - test - ci component meaning. Could you change component name to classlib and summary prefix to [classlib][awt] for H-1441? Thanks a lot 2006/9/12, Mikhail Loenko [EMAIL PROTECTED]: Hi Denis, thanks for you patch! could you please add some comments, why you think this change is necessary? Thanks, Mikhail 2006/9/12, Denis Kishenko (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1439?page=comments#action_12434133 ] Denis Kishenko commented on HARMONY-1439: - May be it would be better to move this issue to build - test - ci and change summary prefix to [testing], sorry for misunderstanding. [classlib][swing] javax.swing.JEditorPaneTest failed Key: HARMONY-1439 URL: http://issues.apache.org/jira/browse/HARMONY-1439 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Denis Kishenko Attachments: 1439-build.patch, 1439-JEditorPaneTest.patch This test javax.swing.JEditorPaneTest failed and was excluded from test list. -- 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] -- 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][corba] How are we doing?
Using a latest link wouldn't work well since the md5sum checking would keep breaking. I like using named versions and planned/controlled changes. -Mark. On 13 September 2006 at 1:20, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: +1 Mikhail Loenko wrote: Actually on other externals we are not liked to latest. At least we discuss here each time we move to a newer version of Junit or BouncyCastle provider Thanks, Mikihail 2006/9/12, Alexey Petrenko [EMAIL PROTECTED]: Great! Jars are better then the full snashot of 15Mbytes. Is that possible to create latest link to allow script to find the latest jar at the same url? SY, Alexey 2006/9/12, Mosur Ravi, Balaji [EMAIL PROTECTED]: http://people.apache.org/maven-snapshot-repository/ I am in the process of deploying the latest yoko artifacts... - Balaji -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 9:34 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? Can you give me a link? 2006/9/12, Mosur Ravi, Balaji [EMAIL PROTECTED]: We might have already discussed this... But can't you use the maven artifacts published in the apache snapshot repository? - Balaji -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 7:42 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? Ok, thanks. I'll prepare a patch for Harmony to use this build. SY, Alexey 2006/9/12, Nolan, Edell [EMAIL PROTECTED]: Hi, My home directory will be the official place for the moment. There will be more of an official download area as soon as we get it setup. I will send an email with the new location when that occurs but for the moment There is a build on http://people.apache.org/~enolan/ Rgds, Edell. -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: 12 September 2006 12:13 To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? 2006/9/12, Nolan, Edell [EMAIL PROTECTED]: Hi, I am having a build problem at the moment trying to connect to the maven repository Yes, I've seen your message on yoko-dev but can not say anything since my build is broken by new javax.rmi classes :) but as soon as I get this sorted - I can do a new build and put it up on my home directory if you want. Do you plan to put it to some official place where everebody can get it? Or your home dir will be the official place? SY, Alexey -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: 12 September 2006 12:01 To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? Hi, Edell. Yes, we can use new M1 build or build it ourself. As we did first time. When do you plan to prepare new M1 build? SY, Alexey 2006/9/12, Nolan, Edell [EMAIL PROTECTED]: Hi Alexey, Are you just waiting on a new build of milestone 1. Cheers, Edell. -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: 12 September 2006 11:48 To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? 2006/9/12, Mark Hindess [EMAIL PROTECTED]: On 9 September 2006 at 1:38, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: What's the status of the missing javax.rmi.CORBA classes? I've started to work on javax.rmi implementation for Yoko. Also, but less important, has anyone thought about the final/nonfinal JAPI issues? That is, lots of failures like: class org.omg.CORBA.AnySeqHelper: nonfinal in japi/jdk15, but final in classlib/harmony I fixed the major part of such issues in Yoko. So we just need to get a new Yoko jar. SY, Alexey -- Alexey A. Petrenko 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
Re: [general] Marking JIRA issues before creation of patches.
Denis Kishenko wrote: If I am going to work with whole module then Harmony class library development status[1] page is useful but if I want to work with several classes, for example fix some JAPI issues or make serious changes, then existing wiki page can't be used. Anyone can create detail page for some component, there already has been some, for example, luni page[2]. I agree with creating JIRA issue and sending notification to dev-list, but I think more detailed status list is necessary, not only modules but packages and classes too. Discussion on dev-list is generally first choice, I totally agree with that. Wiki is just supplement to record somewhat significant work needs longer time or relative big effort, for example, the luni page[2], as well as others, has shown to be very useful when several volunteers from different party worked together to bring the original luni contribution up to 5.0 compatible, especially when someone has interested in some component, the relevant page can be subscribed so that he/she can get update notification. Wiki is useful also because of mailing list's traffic, it's hard for new comer (and often for regular Harmony watcher) to see what's going on, what is most expected to contribute, etc, only in mailing list. Further, I guess many potential user may not visit dev-list at all... However, as others said for several times, it is not necessary to record everything on Wiki(even in list), and it is still good suggestion to discuss at the mailing list before/when trying to update Wiki. [1] http://wiki.apache.org/harmony/component_development_status [2] http://wiki.apache.org/harmony/LUNI 2006/9/7, Paulex Yang [EMAIL PROTECTED]: Geir Magnusson Jr. wrote: Good. Also, don't just do things in JIRA. Add the comment in JIRA, but also send something to the dev list. That way, people who are interested will more easily notice and maybe offer to help, or such... +1, and for classlib, we have had some wiki pages[1]-[3] to list the ToDos and to record who is doing or has interest on what. [1] http://wiki.apache.org/harmony/component_development_status [2] http://wiki.apache.org/harmony/Excluded_tests [3] http://wiki.apache.org/harmony/ClassLibrary geir Oleg Khaschansky wrote: Hi all, There were situations when several people started work on the same issue simultaneously. This happens because it is impossible to assign an issue to a non-committer. I suggest the following process to prevent these collisions: 1. If non-committer starts investigation and is pretty sure that he will proceed with the patch then he adds a comment like starting investigation to the JIRA issue. Maybe we should have a special keyword for this to make a search easier. 2. If for some reason he is unable to provide the patch, he adds a comment about this also. What do you think about this? -- Oleg - 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] -- 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] -- 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: [vm] ArgoUML application crashes IBM VME
Oliver Deakin wrote: Thanks for the link Paulex - sorry it's taken a while to reply. I have added ArgoUML to the list of apps on the page you linked, and have put in the details at [1]. If there's anything that needs adding, please let me know. Nice page! Thank you:). Hopefully the problem can be fixed soon:). Regards, Oliver [1] http://wiki.apache.org/harmony/ArgoUML Paulex Yang wrote: Vladimir Gorr wrote: Yes, it makes sense, I think. Although I don't know what the right place is? there is a section named what can it do[1], and it would be very useful to add a new page for Argo on the test procedure/result/missing class etc, and add the link to that section. [1] http://wiki.apache.org/harmony/ClassLibrary Thanks, Vladimir. 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] Use tweaked TestNG
On 12 September 2006 at 14:44, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Richard, If this tweaking doesn't affect visible TestNG user interface then I see nothing bad about converting the sample module. Especially in case if we have volunteers who cannot stand without it any longer :) Another question is, where should we keep this tweaked version? Is there any place from which it can be downloaded during the build or we should keep tweaked jar in svn or ... Either of the options you mention would break the as long as we do not re-distributed it requirement that Cedric placed on the tweaked version. The only sane option would be to distribute the tweaking mechanism via svn (or a jar). I think I'd prefer waiting 'til we can run TestNG without tweaking. BTW, I'm still volunteering to convert beans. Excellent! -Mark. 2006/9/12, Richard Liang [EMAIL PROTECTED]: Hello, I have been discussing with the author of TestNG (Cedric) about Harmony using a tweaked TestNG which does not require java.util.concurrent. The feedback is we could use the tweaked TestNG as long as we do not re-distributed it. So now it's possible to deploy TestNG in Harmony. What do you think we take a simple module (prefs?) to run a pilot? Or let's waiting for the completion of j.u.concurrent. Thanks a lot. Best regards, -- Richard Liang China Development Lab, IBM -- Alexei Zakharov, Intel Middleware Product 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: [classlib][swing] set of passed swing tests
I've committed the changes to exclude list. Now the tests should pass on both linux and windows Thanks, Mikhail 2006/9/13, Geir Magnusson Jr. [EMAIL PROTECTED]: And? :) How did it turn out? geir Mikhail Loenko wrote: I've not tried. Right after I've send the previous mail all swing tests passed for me for the first time on linux :) Now I'll rerun them couple times and if they pass, i'll commit Thanks, Mikhail 2006/9/12, Stepan Mishura [EMAIL PROTECTED]: Can you run a single test? -Stepan On 9/12/06, Mikhail Loenko wrote: I'm trying to exclude all the swing tests that fail on linux. But every time I run, exclude failuing tests and rerun, new tests fail or hang up. And it looks endless. any receipt? Thanks, Mikhail -- 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] - 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] Use tweaked TestNG
On 9/13/06, Mark Hindess [EMAIL PROTECTED] wrote: On 12 September 2006 at 14:44, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Richard, If this tweaking doesn't affect visible TestNG user interface then I see nothing bad about converting the sample module. Especially in case if we have volunteers who cannot stand without it any longer :) Another question is, where should we keep this tweaked version? Is there any place from which it can be downloaded during the build or we should keep tweaked jar in svn or ... Either of the options you mention would break the as long as we do not re-distributed it requirement that Cedric placed on the tweaked version. The only sane option would be to distribute the tweaking mechanism via svn (or a jar). I think I'd prefer waiting 'til we can run TestNG without tweaking. Agree ;-) Hope we complete j.u.concurrent soon ;-) BTW, I'm still volunteering to convert beans. Excellent! -Mark. 2006/9/12, Richard Liang [EMAIL PROTECTED]: Hello, I have been discussing with the author of TestNG (Cedric) about Harmony using a tweaked TestNG which does not require java.util.concurrent. The feedback is we could use the tweaked TestNG as long as we do not re-distributed it. So now it's possible to deploy TestNG in Harmony. What do you think we take a simple module (prefs?) to run a pilot? Or let's waiting for the completion of j.u.concurrent. Thanks a lot. Best regards, -- Richard Liang China Development Lab, IBM -- Alexei Zakharov, Intel Middleware Product 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] -- Richard Liang China 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: [general] Marking JIRA issues before creation of patches.
Most of wiki module pages were updated last time several months ago. Do they have actual information? 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Discussion on dev-list is generally first choice, I totally agree with that. Wiki is just supplement to record somewhat significant work needs longer time or relative big effort, for example, the luni page[2], as well as others, has shown to be very useful when several volunteers from different party worked together to bring the original luni contribution up to 5.0 compatible, especially when someone has interested in some component, the relevant page can be subscribed so that he/she can get update notification. Wiki is useful also because of mailing list's traffic, it's hard for new comer (and often for regular Harmony watcher) to see what's going on, what is most expected to contribute, etc, only in mailing list. Further, I guess many potential user may not visit dev-list at all... However, as others said for several times, it is not necessary to record everything on Wiki(even in list), and it is still good suggestion to discuss at the mailing list before/when trying to update Wiki. [1] http://wiki.apache.org/harmony/component_development_status [2] http://wiki.apache.org/harmony/LUNI 2006/9/7, Paulex Yang [EMAIL PROTECTED]: Geir Magnusson Jr. wrote: Good. Also, don't just do things in JIRA. Add the comment in JIRA, but also send something to the dev list. That way, people who are interested will more easily notice and maybe offer to help, or such... +1, and for classlib, we have had some wiki pages[1]-[3] to list the ToDos and to record who is doing or has interest on what. [1] http://wiki.apache.org/harmony/component_development_status [2] http://wiki.apache.org/harmony/Excluded_tests [3] http://wiki.apache.org/harmony/ClassLibrary geir Oleg Khaschansky wrote: Hi all, There were situations when several people started work on the same issue simultaneously. This happens because it is impossible to assign an issue to a non-committer. I suggest the following process to prevent these collisions: 1. If non-committer starts investigation and is pretty sure that he will proceed with the patch then he adds a comment like starting investigation to the JIRA issue. Maybe we should have a special keyword for this to make a search easier. 2. If for some reason he is unable to provide the patch, he adds a comment about this also. What do you think about this? -- Oleg - 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] -- 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] -- 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] -- 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]volunteer to supply patches for old JIRAs
Spark Shen wrote: Alexey Varlamov 写道: 2006/9/13, Spark Shen [EMAIL PROTECTED]: Nathan Beyer 写道: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. There are also very specific cases. Some JIRAs are about kernal classes( e.p. JIRA 921). When IBM vm is concerned, they are not in the scope of Harmony project. It is better be feeded back to IBM. When DRLVM is concerned, we may solve it in the scope of Harmony project. So I suggest to split JIRA 921 into two JIRAs. One for DRLVM, one for IBM vm. Did you check this is applicable to both VMs? If it is for DRLVM only, then better just change component (and summary prefix ;)). Sorry, what do you mean by applicable? Do you mean will this bug reoccur on both VMs, 1 Or do you worry about whether this bug can be reported to both VMs? 2 If you worry 1, I tested it with IBM VME v4 and latest snapshot. java -cp . test res = null res = null And did not test it with DRLVM, and guess the bug still exists on DRLVM :-) If you worry 2, I think Oliver will respond to problems with IBM VME. May be we could involve him in this discussion. Yes, if you find bugs with the IBM VME, then please make them known to the list (as I think people have done successfully up to now) and I will try to get them fixed in the next VME version. Regards, Oliver Best regards Any suggestions? -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. 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 - 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] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED]
Re: [general] Marking JIRA issues before creation of patches.
Denis Kishenko wrote: Most of wiki module pages were updated last time several months ago. Do they have actual information? It is easier for Wiki to be out-dated, that's why it needs to be taken care of more:). Specific for the module page, AFAIK, the 5.0 bring up work on many modules are almost complete, so I'm not surprised they are not updated actively now, while some others are under actively working, say, the excluded tests[1]. Actually I just meant that Wiki is a tool to record the interest and ToDos. [1] http://wiki.apache.org/harmony/Excluded_tests 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Discussion on dev-list is generally first choice, I totally agree with that. Wiki is just supplement to record somewhat significant work needs longer time or relative big effort, for example, the luni page[2], as well as others, has shown to be very useful when several volunteers from different party worked together to bring the original luni contribution up to 5.0 compatible, especially when someone has interested in some component, the relevant page can be subscribed so that he/she can get update notification. Wiki is useful also because of mailing list's traffic, it's hard for new comer (and often for regular Harmony watcher) to see what's going on, what is most expected to contribute, etc, only in mailing list. Further, I guess many potential user may not visit dev-list at all... However, as others said for several times, it is not necessary to record everything on Wiki(even in list), and it is still good suggestion to discuss at the mailing list before/when trying to update Wiki. -- 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] -- 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]
[JIRA]what is non-bug difference issue?
When I looked though the old JIRA issues I noticed that many non-bug difference issues had patches and some of them was fixed already. e.g. harmony-401 836 1050 and so on. IMHO the non-bug difference indicates that it is an acceptable difference between RI and Harmony and won't be fixed. Am I right? -- Tony Wu China Software Development Lab, IBM
Re: [classlib]volunteer to supply patches for old JIRAs
So I suggest to split JIRA 921 into two JIRAs. One for DRLVM, one for IBM vm. Did you check this is applicable to both VMs? If it is for DRLVM only, then better just change component (and summary prefix ;)). Sorry, what do you mean by applicable? Do you mean will this bug reoccur on both VMs, 1 Or do you worry about whether this bug can be reported to both VMs? 2 If you worry 1, I tested it with IBM VME v4 and latest snapshot. java -cp . test res = null res = null Yep, this is what I meant. Still, as we do not track IBM VME bugs in JIRA, I see no point to create new JIRAs - enough to change the component. And did not test it with DRLVM, and guess the bug still exists on DRLVM :-) If you worry 2, I think Oliver will respond to problems with IBM VME. May be we could involve him in this discussion. Best regards Any suggestions? -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. 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 - 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] -- 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]
[doc] multiple unresolved JIRAs for website waiting for someone to apply them
All, We have not been paying too much attention to documentation for existing code. Here is a compilation of doc-related activities and discussions. It would be great if unresolved JIRAs were propagated and more discussion happened on the existing issues. This will help us make the website better and bigger :-) JIRAs 1170 https://issues.apache.org/jira/browse/HARMONY-1170 - update based on exception-throwing compatibility discussion; to be applied to Classlib Compatibility page (hanging there since Aug'14!) 1384 https://issues.apache.org/jira/browse/HARMONY-1384 - patches to port the website to a site-wide css; this helps docs by different authors look and read easily; initial patches + further enhancements ready for propagation; it would be great if somebody looked at these... 1401 https://issues.apache.org/jira/browse/HARMONY-1401 - new document that describes the execution manager; a potentially useful piece of info ready for integration into the site; relies on JIRA 1384 for styles 1443 https://issues.apache.org/jira/browse/HARMONY-1443 - issue opened yesterday to include various patches with content updates; the patches already in are ready to go, more are welcomed. As far as I can say, the patches mostly add new info or capabilities to the site, so why not apply them? The 1384 issue might need testing and further investigation. Everyone's invited ((C) Samsung? :-)) One more issue that is not in JIRA is the image problem, see mail thread [doc] no images. Nadya Morozova
Re: [jira] Updated: (HARMONY-1409) [classlib][beans] add missing get/setSource methods to PropertyEditorSupport
Ok, Stepan, in this case I suggest to leave the check and rise the additional Non-bug differences from RI JIRA (I can do if no one objects). I don't really think there are many applications that rely on this silent RI behavior, and IMHO we should not care until we encounter one. Regards, 2006/9/12, Stepan Mishura [EMAIL PROTECTED]: Just have found in java.beans package description: Unless explicitly stated, null values or empty Strings are not valid parameters for the methods in this package. You may expect to see exceptions if these parameters are used. So it is a bug in RI. -Stepan. On 9/12/06, Stepan Mishura wrote: Alexei, We have the following RI behaviour here: 1) Constructor doesn't allow 'null' value and throws NPE 2) setSource allow 'null' value This looks inconsistent - to assign soure null value we can not use constuctor directly! Thanks, Stepan. On 9/12/06, Alexei Zakharov wrote: Hi Stepan, Thank you for your attention to my patch first of all. IMHO everything is ok except for the null-check you add to the setSource() method. It seems RI does not check for null in this case. At least your regression test fails on Sun JDK 1.5.0_06: No expected NullPointerException junit.framework.AssertionFailedError: No expected NullPointerException at org.apache.harmony.beans.tests.java.beans.PropertyEditorSupportTest.test_setSourceLjava_lang_Object (PropertyEditorSupportTest.java:291) Thanks, 2006/9/12, Stepan Mishura (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1409?page=all ] Stepan Mishura updated HARMONY-1409: Summary: [classlib][beans] add missing get/setSource methods to PropertyEditorSupport (was: [classlib][beans] PropertyEditorSupport cleanup) [classlib][beans] add missing get/setSource methods to PropertyEditorSupport Key: HARMONY-1409 URL: http://issues.apache.org/jira/browse/HARMONY-1409 Project: Harmony Issue Type: Improvement Components: Classlib Environment: ws2003 Reporter: Alexei Zakharov Assigned To: Stepan Mishura Attachments: PropertyEditorSupport.patch Attached patch adds two missing API methods that were introduced in Java 1.5 API. In addition to that all unnecessary javadoc comments are removed (@author and etc.), the coding style is corrected. -- 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 -- 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] -- Alexei Zakharov, Intel Middleware Product 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-1409) [classlib][beans] add missing get/setSource methods to PropertyEditorSupport
On 9/13/06, Alexei Zakharov wrote: Ok, Stepan, in this case I suggest to leave the check and rise the additional Non-bug differences from RI JIRA (I can do if no one objects). I don't really think there are many applications that rely on this silent RI behavior, and IMHO we should not care until we encounter one. Agree. Go forward with JIRA. -Stepan. Regards, 2006/9/12, Stepan Mishura [EMAIL PROTECTED]: Just have found in java.beans package description: Unless explicitly stated, null values or empty Strings are not valid parameters for the methods in this package. You may expect to see exceptions if these parameters are used. So it is a bug in RI. -Stepan. On 9/12/06, Stepan Mishura wrote: Alexei, We have the following RI behaviour here: 1) Constructor doesn't allow 'null' value and throws NPE 2) setSource allow 'null' value This looks inconsistent - to assign soure null value we can not use constuctor directly! Thanks, Stepan. On 9/12/06, Alexei Zakharov wrote: Hi Stepan, Thank you for your attention to my patch first of all. IMHO everything is ok except for the null-check you add to the setSource() method. It seems RI does not check for null in this case. At least your regression test fails on Sun JDK 1.5.0_06: No expected NullPointerException junit.framework.AssertionFailedError: No expected NullPointerException at org.apache.harmony.beans.tests.java.beans.PropertyEditorSupportTest.test_setSourceLjava_lang_Object (PropertyEditorSupportTest.java:291) Thanks, 2006/9/12, Stepan Mishura (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1409?page=all ] Stepan Mishura updated HARMONY-1409: Summary: [classlib][beans] add missing get/setSource methods to PropertyEditorSupport (was: [classlib][beans] PropertyEditorSupport cleanup) [classlib][beans] add missing get/setSource methods to PropertyEditorSupport Key: HARMONY-1409 URL: http://issues.apache.org/jira/browse/HARMONY-1409 Project: Harmony Issue Type: Improvement Components: Classlib Environment: ws2003 Reporter: Alexei Zakharov Assigned To: Stepan Mishura Attachments: PropertyEditorSupport.patch Attached patch adds two missing API methods that were introduced in Java 1.5 API. In addition to that all unnecessary javadoc comments are removed (@author and etc.), the coding style is corrected. -- 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: [jira] Created: (HARMONY-1447) [classlib][awt] RI Polygon.add(int,int) throws exception after Polygon(new int[2], new int[2], 0)
On 9/12/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Hi all
This issue looks like RI bug so I filed it as Non-bug differences from
RI.
Spec doesn't say about any exceptions. Even if Polygon created with
empty point buffer (not null but zero length), method addPoint()
should reallocate buffer to append new point but RI throws
ArrayIndexOutOfBoundsException exception.
= Test.java ===
import java.awt.*;
public class Test {
static public void main(String[] args) {
Polygon p = new Polygon(new int[2], new int[2], 0);
p.addPoint(1, 1);
}
}
= RI
java.lang.ArrayIndexOutOfBoundsException
at java.awt.Polygon.addPoint(Polygon.java:262)
at Test.main(Test.java:8)
=== Harmony
nothing
Comments?
I would agree with you and vote for RI bug. New Point should be appended
without exceptions if the initial total number of points is 0, espessially
taking into account the code
Polygon p = new Polygon();
p.addPoint(1, 1);
behaves on RI as expected.
Thanks,
Ilya.
2006/9/12, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlib][awt] RI Polygon.add(int,int) throws exception after Polygon(new
int[2], new int[2], 0)
-
Key: HARMONY-1447
URL: http://issues.apache.org/jira/browse/HARMONY-1447
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
Spec doesn't say about any exceptions. Even if Polygon created with empty
point buffer (not null but zero length), method addPoint() should reallocate
buffer to append new point but RI throws ArrayIndexOutOfBoundsException
exception. Seems like RI bug.
= Test.java ===
import java.awt.*;
public class Test {
static public void main(String[] args) {
//Polygon p = new Polygon(); it works
Polygon p = new Polygon(new int[2], new int[2], 0);
p.addPoint(1, 1);
}
}
= RI
java.lang.ArrayIndexOutOfBoundsException
at java.awt.Polygon.addPoint(Polygon.java:262)
at Test.main(Test.java:8)
=== Harmony
nothing
--
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
--
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]
--
--
Ilya Okomin
Intel Middleware Products Division
Re: [classlib][security] problem processing SHA signatures in JBoss installer manifest
Collegues, thanks a lot for identifying the bug !!!
The fix you propose is correct.
Thanks,
Yuri
Nice work all. You guys are amazing. Definitely create that patch and
attach to the initial JIRA.
geir
Jimmy, Jing Lv wrote:
Richard Liang wrote:
After two-day struggling with JarFile, ObjectInputStream and
MessageDigest, in the end, I have identified the root cause. And now I
have two panda-eyes[1] ;-)
It seems a bug of
org.apache.harmony.security.provider.crypto.SHA1Impl. As I have no
idea about SHA1. Could any one have a look at this problem?
The following test case passes on RI, but fails on Harmony.
public void testUpdate() throws NoSuchAlgorithmException {
byte[] bytes = { 0x6e, 0x61, 0x6d, 0x65};
MessageDigest sha1 = MessageDigest.getInstance(SHA1);
byte[] digest1 = sha1.digest();
byte b = 0x04;
sha1.update(b);
for (int i = 0; i bytes.length; i++) {
sha1.update(bytes[i]);
}
byte[] digest2 = sha1.digest();
sha1.reset();
byte[] digest3 = sha1.digest();
assertTrue(MessageDigest.isEqual(digest1, digest3));
sha1.update(b);
sha1.update(bytes, 0, bytes.length);
byte[] digest4 = sha1.digest();
assertTrue(MessageDigest.isEqual(digest2, digest4));
}
[1]http://www.panda.org.cn/zhuye/bbe.jpg
Poor Richard! Looking for a needle in a bottle of hay, right? ;)
A closer study on SHA1Impl, I find these lines(line 194) may be wrong:
for ( ; ( i = toByte ) ( byteIndex 4 ) ; i++ ) { // *NOTE* it use
// = here
intArray[wordIndex] |=
( byteInput[i] 0xFF ) ((3 - byteIndex)3) ;
byteIndex++;
}
if ( byteIndex == 4 ) {
wordIndex++;
if ( wordIndex == 16 ) {
computeHash(intArray);
wordIndex = 0;
}
}
if ( i = toByte ) { // *NOTE* it use = here
return ;
}
Though I don't know SHA1 well, I guess it must be in the line of
second *NOTE*.
This bug happens when byteIndex==1, and fromByte==0, toByte==3(that is,
input byte number is 4). The first circle inputs 3 bytes into array,
leaving the last byte for next step. But at that time i==toByte, so the
last byte is omitted, which is properly an mistake.
Change it to if (i toByte) will solve the problem, I've run all
tests, including Richard's test, and they all passes. It'll be better
someone knows SHA1 check it.
If no objection, we can create a patch.
Best regards,
Richard
On 9/11/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I was trying the latest snapshot with the JBoss installer (4.0.1) and
found a problem processing the SHA signatures int the jar manifest.
I've entered a JIRA - HARMONY-1412
I will have a look at it. ;-)
geir
-
Terms of use :
*http://incubator.apache.org/harmony/mailing.html*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*http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] missing underscores in native dll exports?
I've noticed that the vast majority of the exported function names in the classlib native libraries do not have underscores. For example, for luni.dll the export table looks like: dumpbin /EXPORTS hyluni.dll ... 233 E6 C230 Java_org_apache_harmony_math_util_BigInteger_subImpl On the other hand, MS compiler adds underscores to function names if they are declared as __stdcall (which is same as JNICALL) by default. If compile a native library as written in the JNI tutorial, the resulted dll would also contain the underscores, e.g. the exported name would be like: 10 1000 [EMAIL PROTECTED] Are the underscores switched off intentionally in the classlib's build? I've also noticed that the underscores are generated for DRLVM's kernel classes (those natives are in vmcore.dll): 543 222 00068660 [EMAIL PROTECTED] Any ideas which naming scheme is the correct one for Windows? -- Andrey Chernyshev 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][corba] How are we doing?
Yes, that is what Mikhail was saying, and I was supporting. geir Mark Hindess wrote: Using a latest link wouldn't work well since the md5sum checking would keep breaking. I like using named versions and planned/controlled changes. -Mark. On 13 September 2006 at 1:20, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: +1 Mikhail Loenko wrote: Actually on other externals we are not liked to latest. At least we discuss here each time we move to a newer version of Junit or BouncyCastle provider Thanks, Mikihail 2006/9/12, Alexey Petrenko [EMAIL PROTECTED]: Great! Jars are better then the full snashot of 15Mbytes. Is that possible to create latest link to allow script to find the latest jar at the same url? SY, Alexey 2006/9/12, Mosur Ravi, Balaji [EMAIL PROTECTED]: http://people.apache.org/maven-snapshot-repository/ I am in the process of deploying the latest yoko artifacts... - Balaji -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 9:34 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? Can you give me a link? 2006/9/12, Mosur Ravi, Balaji [EMAIL PROTECTED]: We might have already discussed this... But can't you use the maven artifacts published in the apache snapshot repository? - Balaji -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 7:42 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? Ok, thanks. I'll prepare a patch for Harmony to use this build. SY, Alexey 2006/9/12, Nolan, Edell [EMAIL PROTECTED]: Hi, My home directory will be the official place for the moment. There will be more of an official download area as soon as we get it setup. I will send an email with the new location when that occurs but for the moment There is a build on http://people.apache.org/~enolan/ Rgds, Edell. -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: 12 September 2006 12:13 To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? 2006/9/12, Nolan, Edell [EMAIL PROTECTED]: Hi, I am having a build problem at the moment trying to connect to the maven repository Yes, I've seen your message on yoko-dev but can not say anything since my build is broken by new javax.rmi classes :) but as soon as I get this sorted - I can do a new build and put it up on my home directory if you want. Do you plan to put it to some official place where everebody can get it? Or your home dir will be the official place? SY, Alexey -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: 12 September 2006 12:01 To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? Hi, Edell. Yes, we can use new M1 build or build it ourself. As we did first time. When do you plan to prepare new M1 build? SY, Alexey 2006/9/12, Nolan, Edell [EMAIL PROTECTED]: Hi Alexey, Are you just waiting on a new build of milestone 1. Cheers, Edell. -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: 12 September 2006 11:48 To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? 2006/9/12, Mark Hindess [EMAIL PROTECTED]: On 9 September 2006 at 1:38, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: What's the status of the missing javax.rmi.CORBA classes? I've started to work on javax.rmi implementation for Yoko. Also, but less important, has anyone thought about the final/nonfinal JAPI issues? That is, lots of failures like: class org.omg.CORBA.AnySeqHelper: nonfinal in japi/jdk15, but final in classlib/harmony I fixed the major part of such issues in Yoko. So we just need to get a new Yoko jar. SY, Alexey -- Alexey A. Petrenko 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] -- Alexey A. Petrenko 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] -- Alexey A. Petrenko Intel Middleware Products Division
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
On 9/13/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Gregory Shimansky wrote: Hello I have recently identified a problem which may potentially lead to an infinite recursion with the current implementation of some JVMTI functions in DRLVM. The functions like GetThreadInfo or GetThreadGroupInfo call Java methods like Thread.getName() to return the necessary information to the JVMTI agent. This works ok in most cases but in case an agent chooses to call such methods from inside of events like MethodEntry, MethodExit, SingleStep, Breakpoint, etc for the exact Java methods like Thread.getName() this may easily lead to an infinite recursion. For the current DRLVM Thread Manager implementation it doesn't seem to be possible to get all of the information about Thread or ThreadGroup from native code only, so it is necessary to call Java anyway and I see only one solution which may not be perfect. It is possible to create a thread local flag for JVMTI which will disable sending any events to the loaded agents while calling Java code from inside of JVMTI API functions. This may impact the results of profiler agents and potentially miss some methods in CompiledMethodLoad event for tools like VTune, ThreadChecker and other. So I am unsure whether this fix is necessary or should we change threading code to make it possible to provide all necessary information in the native. The currently called Java Methods are Thread.getName() Thread.getPriority() Thread.isDaemon() Thread.getThreadGroup() Thread.getContextClassLoader() Thread.setDaemon() ThreadGroup.getParent() ThreadGroup.getName() ThreadGroup.getMaxPriority() ThreadGroup.isDaemon() ThreadGroup.enumerate() Quite a lot of these functions return information which is available from native code, but functions like Thread.getContextClassLoader() require calling Java. IIRC, the class Thread(and ThreadGroup) itself is a kernel class, isn't it? It may be easier to get a inner field(e.g, thread name) than invoking a method. I don't know DRLVM well, However I doubt if JVMTI and kernel class are together there in VM, it may be a clear and easy way to know each other? To get specifically the name of the thread, it is true that one can read directly the name field of the j.l.Thread without calling getName() method. There could be also more complex cases like ThreadGroup.enumerate() where the code won't be like reading the specific field. Also, getting the field contained in the structure (in our case - j.l.Thread) through the accessor method is more clean way compared to reading it directly. In the current implementation, JVMTI code doesn't depend on the internal representation of j.l.Thread, which can also be good thing. I wouldn't assume that JVMTI functions should never be calling Java code, because there is always a possibility that some parts of the JVM itself are written in Java. For example, I could imagine Java monitors implementation written in Java code with help of j.u.concurrent locks, in this case all the monitor data and associated debugging info/logic (like getOwnedMonitorInfo) would reside in the Java space. Thanks, Andrey. -- 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] -- Andrey Chernyshev 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][TestNG] Use tweaked TestNG
Richard Liang wrote: Hello, I have been discussing with the author of TestNG (Cedric) about Harmony using a tweaked TestNG which does not require java.util.concurrent. The feedback is we could use the tweaked TestNG as long as we do not re-distributed it. So now it's possible to deploy TestNG in Harmony. Huh? TestNG is under the Apache License as far as I can tell. We can tweak to our heart's content, and distribute at will, as long as we don't call the tweaked version TestNG. But we don't want to distribute it anyway. What do you think we take a simple module (prefs?) to run a pilot? Or let's waiting for the completion of j.u.concurrent. Thanks a lot. Is there a way this tweak can be packaged as a patch to testNG that we keep here and use in Harmony until J.u.c is ready? geir 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: [doc] multiple unresolved JIRAs for website waiting for someone to apply them
Thank you! :) Morozova, Nadezhda wrote: All, We have not been paying too much attention to documentation for existing code. Here is a compilation of doc-related activities and discussions. It would be great if unresolved JIRAs were propagated and more discussion happened on the existing issues. This will help us make the website better and bigger :-) JIRAs 1170 https://issues.apache.org/jira/browse/HARMONY-1170 - update based on exception-throwing compatibility discussion; to be applied to Classlib Compatibility page (hanging there since Aug'14!) 1384 https://issues.apache.org/jira/browse/HARMONY-1384 - patches to port the website to a site-wide css; this helps docs by different authors look and read easily; initial patches + further enhancements ready for propagation; it would be great if somebody looked at these... 1401 https://issues.apache.org/jira/browse/HARMONY-1401 - new document that describes the execution manager; a potentially useful piece of info ready for integration into the site; relies on JIRA 1384 for styles 1443 https://issues.apache.org/jira/browse/HARMONY-1443 - issue opened yesterday to include various patches with content updates; the patches already in are ready to go, more are welcomed. As far as I can say, the patches mostly add new info or capabilities to the site, so why not apply them? The 1384 issue might need testing and further investigation. Everyone's invited ((C) Samsung? :-)) One more issue that is not in JIRA is the image problem, see mail thread [doc] no images. Nadya Morozova - 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] multiple unresolved JIRAs for website waiting for someone to apply them
You're welcome :) Do you need any help from me? I have been doing things pretty much on my own, so I could have missed something important. If you have some ideas on what needs to be done for the docs that we have, go ahead and share. I'll see what I can do. Cheers, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 3:19 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] multiple unresolved JIRAs for website waiting for someone to apply them Thank you! :) Morozova, Nadezhda wrote: All, We have not been paying too much attention to documentation for existing code. Here is a compilation of doc-related activities and discussions. It would be great if unresolved JIRAs were propagated and more discussion happened on the existing issues. This will help us make the website better and bigger :-) JIRAs 1170 https://issues.apache.org/jira/browse/HARMONY-1170 - update based on exception-throwing compatibility discussion; to be applied to Classlib Compatibility page (hanging there since Aug'14!) 1384 https://issues.apache.org/jira/browse/HARMONY-1384 - patches to port the website to a site-wide css; this helps docs by different authors look and read easily; initial patches + further enhancements ready for propagation; it would be great if somebody looked at these... 1401 https://issues.apache.org/jira/browse/HARMONY-1401 - new document that describes the execution manager; a potentially useful piece of info ready for integration into the site; relies on JIRA 1384 for styles 1443 https://issues.apache.org/jira/browse/HARMONY-1443 - issue opened yesterday to include various patches with content updates; the patches already in are ready to go, more are welcomed. As far as I can say, the patches mostly add new info or capabilities to the site, so why not apply them? The 1384 issue might need testing and further investigation. Everyone's invited ((C) Samsung? :-)) One more issue that is not in JIRA is the image problem, see mail thread [doc] no images. Nadya Morozova - 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][corba] How are we doing?
2006/9/13, Mark Hindess [EMAIL PROTECTED]: Using a latest link wouldn't work well since the md5sum checking would keep breaking. This would not be a problem.Since they post md5 as files. I like using named versions and planned/controlled changes. Agree here. SY, Alexey -Mark. On 13 September 2006 at 1:20, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: +1 Mikhail Loenko wrote: Actually on other externals we are not liked to latest. At least we discuss here each time we move to a newer version of Junit or BouncyCastle provider Thanks, Mikihail 2006/9/12, Alexey Petrenko [EMAIL PROTECTED]: Great! Jars are better then the full snashot of 15Mbytes. Is that possible to create latest link to allow script to find the latest jar at the same url? SY, Alexey 2006/9/12, Mosur Ravi, Balaji [EMAIL PROTECTED]: http://people.apache.org/maven-snapshot-repository/ I am in the process of deploying the latest yoko artifacts... - Balaji -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 9:34 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? Can you give me a link? 2006/9/12, Mosur Ravi, Balaji [EMAIL PROTECTED]: We might have already discussed this... But can't you use the maven artifacts published in the apache snapshot repository? - Balaji -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 7:42 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? Ok, thanks. I'll prepare a patch for Harmony to use this build. SY, Alexey 2006/9/12, Nolan, Edell [EMAIL PROTECTED]: Hi, My home directory will be the official place for the moment. There will be more of an official download area as soon as we get it setup. I will send an email with the new location when that occurs but for the moment There is a build on http://people.apache.org/~enolan/ Rgds, Edell. -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: 12 September 2006 12:13 To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? 2006/9/12, Nolan, Edell [EMAIL PROTECTED]: Hi, I am having a build problem at the moment trying to connect to the maven repository Yes, I've seen your message on yoko-dev but can not say anything since my build is broken by new javax.rmi classes :) but as soon as I get this sorted - I can do a new build and put it up on my home directory if you want. Do you plan to put it to some official place where everebody can get it? Or your home dir will be the official place? SY, Alexey -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: 12 September 2006 12:01 To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? Hi, Edell. Yes, we can use new M1 build or build it ourself. As we did first time. When do you plan to prepare new M1 build? SY, Alexey 2006/9/12, Nolan, Edell [EMAIL PROTECTED]: Hi Alexey, Are you just waiting on a new build of milestone 1. Cheers, Edell. -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: 12 September 2006 11:48 To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? 2006/9/12, Mark Hindess [EMAIL PROTECTED]: On 9 September 2006 at 1:38, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: What's the status of the missing javax.rmi.CORBA classes? I've started to work on javax.rmi implementation for Yoko. Also, but less important, has anyone thought about the final/nonfinal JAPI issues? That is, lots of failures like: class org.omg.CORBA.AnySeqHelper: nonfinal in japi/jdk15, but final in classlib/harmony I fixed the major part of such issues in Yoko. So we just need to get a new Yoko jar. SY, Alexey -- Alexey A. Petrenko 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 :
Re: [JIRA]what is non-bug difference issue?
On 9/13/06, Tony Wu wrote: When I looked though the old JIRA issues I noticed that many non-bug difference issues had patches and some of them was fixed already. e.g. harmony-401 836 1050 and so on. IMHO the non-bug difference indicates that it is an acceptable difference between RI and Harmony and won't be fixed. Am I right? Yes, I think you are right. Thanks for catching this. IIRC we created this JIRA category just to document difference with RI but not to fix it. IMO you should add comments to such JIRAs asking why a difference was fixed. 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] Updated: (HARMONY-1392) Different properties are used to run awt and swing tests
Mark Hindess wrote: On 11 September 2006 at 16:29, Alexey Petrenko [EMAIL PROTECTED] wrote: Mark, I did not get your point... What is the problem with the same property for both awt and swing tests? I understand that we need to set dome property to run them since we got problems with building awt native libraries and do not want them while usual run. But why we need different properties for one task: run hidden tests? I mean that 'with.awt.swing.tests' as it is currently used should really be called 'run.tests.that.might.kill.your.xsession' - for me at least. Say what you will about our swing code, the fact that our bugs can take down an XServer is darn impressive in my book. Ideally I'd like to fix the dependency issues and the tests and have no extra variables. ;-) +1 Part of the problem is that I don't really know which tests are interfering with my window manager... because when I run the tests I can no longer type anything and it doesn't seem to happen 100% of the time so my attempt to use a binary chop to find the problematic tests didn't work. I will try to narrow it down again but I was hoping someone who knew the code better might have an idea what might cause focus to be stolen by the tests. -Mark. SY, Alexey 2006/9/11, Mark Hindess [EMAIL PROTECTED]: Just to explain, if I build and test with 'with.awt.swing=true' then I don't see any problems with hangs or tests stealing keyboard/mouse events and effectively killing my window manager. The same is *not* true if I set with.awt.swing.tests. I should have called the second variable something else, but that is the reason I used a different variable for the problematic tests. -Mark. On 6 September 2006 at 17:23, Alexey Petrenko [EMAIL PROTECTED] wrote: Both solutions are possible. 2006/9/6, Mikhail Loenko [EMAIL PROTECTED]: Is there a reason to have two different options for classes and for tes ts? Why not have -Dwith.awt.swing for both? Thanks, Mikhail 2006/9/6, Alexey Petrenko (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1392?page=all ] Alexey Petrenko updated HARMONY-1392: - Attachment: HARMONY-1392.diff Different properties are used to run awt and swing tests Key: HARMONY-1392 URL: http://issues.apache.org/jira/browse/HARMONY-1 392 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Petrenko Attachments: HARMONY-1392.diff We need to set different properties to run awt and swing tests. And thi s is wrong. I suggest set with.awt.swing.tests property as for awt. I'll prepare the patch shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrator s: h ttp://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] -- Alexey A. Petrenko 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] -- Alexey A. Petrenko 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] - 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][internationalization]Are log messages and tools usage text to be internationalized?
Hi, Are there any non-exception messages in the other modules which are already internationalized? I think, if there are any, they should be modified to follow the new convention. -- Oleg On 9/12/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi, Jimmy, Jing Lv wrote: 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. Ilya Okomin wrote: The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient Nice idea guys, +1 from me Regards, 2006/9/11, Ilya Okomin [EMAIL PROTECTED]: Thanks all for useful comments! The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient. If there are no objections I would use default key names module.id for exception messages, and module.prefix.id for certain messages where prefix is log or console (or any other key word depending on the purpose). Regards, Ilya. On 9/11/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Ilya Okomin wrote: Hi all, During rmi module internationalization I've faced with loads of log messages (e.g. take a look at o.a.h.rmi.DefaultRMIClassLoaderSpi). Also some classes (e.g. o.a.h.rmi.compiler.RmicStrings) have strings that are the usage texts of any console tool. I think we shouldn't internationalize such messages, however I'm not really sure about that. If we internationalize them - we'll obtain fully internationalized module it is an advantage. From the other hand - if you have to analyse someone's log, it is useful if the common langauge was used. Moreover, messages.properties file with the list of all messages will be too huge to find appropriate messages for new classes developed later. Any thoughts? IMHO, we have agree on that all console output can be internationalized. If the only problem of a too huge messages.properties file is to find appropriate, I guess we can: 1. Separate the file into several smaller ones, one for console, one for error message, etc. Or 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. In this way we can find some certain message easy. And I prefer 2. -- 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] -- -- Ilya Okomin Intel Middleware Products Division -- Alexei Zakharov, Intel Middleware Product 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: [classlib][internationalization]Are log messages and tools usage text to be internationalized?
I believe it could be done in lazy way... But it defenetly should be done. SY, Alexey 2006/9/13, Oleg Khaschansky [EMAIL PROTECTED]: Hi, Are there any non-exception messages in the other modules which are already internationalized? I think, if there are any, they should be modified to follow the new convention. -- Oleg On 9/12/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi, Jimmy, Jing Lv wrote: 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. Ilya Okomin wrote: The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient Nice idea guys, +1 from me Regards, 2006/9/11, Ilya Okomin [EMAIL PROTECTED]: Thanks all for useful comments! The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient. If there are no objections I would use default key names module.id for exception messages, and module.prefix.id for certain messages where prefix is log or console (or any other key word depending on the purpose). Regards, Ilya. On 9/11/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Ilya Okomin wrote: Hi all, During rmi module internationalization I've faced with loads of log messages (e.g. take a look at o.a.h.rmi.DefaultRMIClassLoaderSpi). Also some classes (e.g. o.a.h.rmi.compiler.RmicStrings) have strings that are the usage texts of any console tool. I think we shouldn't internationalize such messages, however I'm not really sure about that. If we internationalize them - we'll obtain fully internationalized module it is an advantage. From the other hand - if you have to analyse someone's log, it is useful if the common langauge was used. Moreover, messages.properties file with the list of all messages will be too huge to find appropriate messages for new classes developed later. Any thoughts? IMHO, we have agree on that all console output can be internationalized. If the only problem of a too huge messages.properties file is to find appropriate, I guess we can: 1. Separate the file into several smaller ones, one for console, one for error message, etc. Or 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. In this way we can find some certain message easy. And I prefer 2. -- 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] -- -- Ilya Okomin Intel Middleware Products Division -- Alexei Zakharov, Intel Middleware Product 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] -- Alexey A. Petrenko 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][swing] set of passed swing tests
AFAIK some of tests wrongly release resources which are necessary for the next one. So each single test passes, but if you run series - it fails. Using flag forkmode=perTest allows avoid this. 2006/9/13, Mikhail Loenko [EMAIL PROTECTED]: I've committed the changes to exclude list. Now the tests should pass on both linux and windows Thanks, Mikhail 2006/9/13, Geir Magnusson Jr. [EMAIL PROTECTED]: And? :) How did it turn out? geir Mikhail Loenko wrote: I've not tried. Right after I've send the previous mail all swing tests passed for me for the first time on linux :) Now I'll rerun them couple times and if they pass, i'll commit Thanks, Mikhail 2006/9/12, Stepan Mishura [EMAIL PROTECTED]: Can you run a single test? -Stepan On 9/12/06, Mikhail Loenko wrote: I'm trying to exclude all the swing tests that fail on linux. But every time I run, exclude failuing tests and rerun, new tests fail or hang up. And it looks endless. any receipt? Thanks, Mikhail -- 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] - 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][swing] set of passed swing tests
And this is already done for swing tests as Mikhail said. 2006/9/13, Denis Kishenko [EMAIL PROTECTED]: AFAIK some of tests wrongly release resources which are necessary for the next one. So each single test passes, but if you run series - it fails. Using flag forkmode=perTest allows avoid this. 2006/9/13, Mikhail Loenko [EMAIL PROTECTED]: I've committed the changes to exclude list. Now the tests should pass on both linux and windows Thanks, Mikhail 2006/9/13, Geir Magnusson Jr. [EMAIL PROTECTED]: And? :) How did it turn out? geir Mikhail Loenko wrote: I've not tried. Right after I've send the previous mail all swing tests passed for me for the first time on linux :) Now I'll rerun them couple times and if they pass, i'll commit Thanks, Mikhail 2006/9/12, Stepan Mishura [EMAIL PROTECTED]: Can you run a single test? -Stepan On 9/12/06, Mikhail Loenko wrote: I'm trying to exclude all the swing tests that fail on linux. But every time I run, exclude failuing tests and rerun, new tests fail or hang up. And it looks endless. any receipt? Thanks, Mikhail -- 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] - 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] -- Alexey A. Petrenko 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]
[j9] Doesn't deal with -showversion
Oliver and Co : I don't know if you caught this in another thread, but I recently changed the launcher to pass the -showversion cmd line param through to the VM after the launcher prints out its version, so that we can also know the version of the VM. The problem with this brilliant strategy is that J9 doesn't actually deal with -showversion. Can you add that to the list of things to tweak? Either silently swallow it, or print something useful would be my suggestion... 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: [drlvm] [jvmti] Question about JVMTI calling Java code
Gregory, You might want to look closely at the code paths in the JVMTI functions. If the functions in question happen to be arbitrary Java code, then these code paths could lead to many other parts of the JVM which in turn might be written in Java. In the future the JIT runtime helpers or the GC may be written in Java. For example, an innocent looking object new, poll for GC or poll for preemption inside a JVMTI function could take the execution path deep inside of MMTk, or as mentioned below, deep inside java.util.concurrent . Rather than develop a general solution at this point, it may make sense to make all the data JVMTI needs to read/write accessible from C code. On 9/13/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 9/13/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Gregory Shimansky wrote: Hello I have recently identified a problem which may potentially lead to an infinite recursion with the current implementation of some JVMTI functions in DRLVM. The functions like GetThreadInfo or GetThreadGroupInfo call Java methods like Thread.getName() to return the necessary information to the JVMTI agent. This works ok in most cases but in case an agent chooses to call such methods from inside of events like MethodEntry, MethodExit, SingleStep, Breakpoint, etc for the exact Java methods like Thread.getName() this may easily lead to an infinite recursion. For the current DRLVM Thread Manager implementation it doesn't seem to be possible to get all of the information about Thread or ThreadGroup from native code only, so it is necessary to call Java anyway and I see only one solution which may not be perfect. It is possible to create a thread local flag for JVMTI which will disable sending any events to the loaded agents while calling Java code from inside of JVMTI API functions. This may impact the results of profiler agents and potentially miss some methods in CompiledMethodLoad event for tools like VTune, ThreadChecker and other. So I am unsure whether this fix is necessary or should we change threading code to make it possible to provide all necessary information in the native. The currently called Java Methods are Thread.getName() Thread.getPriority() Thread.isDaemon() Thread.getThreadGroup() Thread.getContextClassLoader() Thread.setDaemon() ThreadGroup.getParent() ThreadGroup.getName() ThreadGroup.getMaxPriority() ThreadGroup.isDaemon() ThreadGroup.enumerate() Quite a lot of these functions return information which is available from native code, but functions like Thread.getContextClassLoader() require calling Java. IIRC, the class Thread(and ThreadGroup) itself is a kernel class, isn't it? It may be easier to get a inner field(e.g, thread name) than invoking a method. I don't know DRLVM well, However I doubt if JVMTI and kernel class are together there in VM, it may be a clear and easy way to know each other? To get specifically the name of the thread, it is true that one can read directly the name field of the j.l.Thread without calling getName() method. There could be also more complex cases like ThreadGroup.enumerate() where the code won't be like reading the specific field. Also, getting the field contained in the structure (in our case - j.l.Thread) through the accessor method is more clean way compared to reading it directly. In the current implementation, JVMTI code doesn't depend on the internal representation of j.l.Thread, which can also be good thing. I wouldn't assume that JVMTI functions should never be calling Java code, because there is always a possibility that some parts of the JVM itself are written in Java. For example, I could imagine Java monitors implementation written in Java code with help of j.u.concurrent locks, in this case all the monitor data and associated debugging info/logic (like getOwnedMonitorInfo) would reside in the Java space. Thanks, Andrey. -- 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] -- Andrey Chernyshev 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
Re: Re: Re: [classlib][TestNG] groups of Harmony test
Stepan, All, This is not a good argument for using os.any. Even more it may sound like we are going to choose wrong tool - why we have to add os.any to 99% of classlib tests? just because the harness can not do without it? Well, we have to add the new stuff to these 99% anyway, I mean the annotation itself. And the copy-pasting of longer block doesn't seem to be harder than copy-pasting of short block to me. As I understand arguments in the old thread - TestNG makes us to use os.any annotation otherwise we have to do a lot of tricks to run tests, right? This was the one of the arguments. So a test's annotation should point out that the test is a special one. I was thinking about a little bit different approach. I will try to explain. The idea was to use annotations as a *single* place for the complete information about test: its type, target OS(es) and etc. Something like inlined test descriptor. Not a red flag. In case someone is looking at the test at the first time he will get a complete information just by reading the annotation located at the same place with the java code. If the annotation itself is not obvious then the developer is obliged to go to some page with annotation descriptions, read it carefully and etc. And it seems we get two places with information about single test: the test's source file and the page with decoding rules for annotations. This IMHO reduces the value of the main TestNG benefit - to have all information about the test in single place. But if we are ok to have several places - we may use Junit TestSuites instead of TestNG. No refactoring is needed at all. To put this another way, these efforts doesn't seem to be so unnecessary to me. Efforts are required to make the life better sometimes IMHO. Does this make sense to anyone? Thanks for the reading, 2006/9/12, Stepan Mishura [EMAIL PROTECTED]: On 9/11/06, Alexei Zakharov wrote: Hi all, One more note (seems it already was said sorry if I repeat): the test without any marks should be run in all configurations (i.e. we have 'default' group but declaration of this group may be missed). I'd like to point your attention on the previous discussion about default groups : http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] I am still for using os.any since it is more self-descriptive and the build script will be simpler with os.any. This is not a good argument for using os.any. Even more it may sound like we are going to choose wrong tool - why we have to add os.any to 99% of classlib tests? just because the harness can not do without it? It will be nice to hear more arguments for using defaults because it seems the arguments that were gathered in that old thread hasn't been taken into account by participants of this thread. As I understand arguments in the old thread - TestNG makes us to use os.any annotation otherwise we have to do a lot of tricks to run tests, right? IMO a test annotation should be used as red flag for developer, for example * state.broken - hey, i'm broken fix me please * os.win - i'm valid only for Windows, don't try to run me on Linux So a test's annotation should point out that the test is a special one. But if most of tests will contain a similar block of annotations then nobody will looked at them. Does this make sense? Thanks, Stepan. Thanks, 2006/9/5, Vladimir Ivanov [EMAIL PROTECTED]: One more note (seems it already was said sorry if I repeat): the test without any marks should be run in all configurations (i.e. we have 'default' group but declaration of this group may be missed). thanks, Vladimir On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: OK, let's return back to the usage model. If I understood it correctly, before the commit of any changes each developer run *all* tests (at least all which we have now) on all available to him platforms. 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. thanks, Vladimir By the way, our regression tests are 'classic' regression tests that demonstrate some issues
Re: [j9] Doesn't deal with -showversion
Hi Geir, I just spotted that in the other thread as Im catching up with my mail. Ill take a look at it and see if we can get it fixed in the next VME version. Regards, Oliver Geir Magnusson Jr. wrote: Oliver and Co : I don't know if you caught this in another thread, but I recently changed the launcher to pass the -showversion cmd line param through to the VM after the launcher prints out its version, so that we can also know the version of the VM. The problem with this brilliant strategy is that J9 doesn't actually deal with -showversion. Can you add that to the list of things to tweak? Either silently swallow it, or print something useful would be my suggestion... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - 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]what is non-bug difference issue?
On 9/13/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 9/13/06, Tony Wu wrote: When I looked though the old JIRA issues I noticed that many non-bug difference issues had patches and some of them was fixed already. e.g. harmony-401 836 1050 and so on. IMHO the non-bug difference indicates that it is an acceptable difference between RI and Harmony and won't be fixed. Am I right? Yes, I think you are right. Thanks for catching this. IIRC we created this JIRA category just to document difference with RI but not to fix it. IMO you should add comments to such JIRAs asking why a difference was fixed. I suggest that if the bug was fixed for some reason, we should change the component too, i.e, classlib instead of non-bug difference from RI. Another question is for those real non-bug difference from RI JIRAs, what should be the final status, opened or closed? I suggest the latter so that all of JIRAs could be closed eventually. Comments? Thanks! 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] -- Andrew Zhang China Software Development Lab, IBM
Re: [j9] Doesn't deal with -showversion
Is it just me, or does something similar happen with -version? I get: $ java -version Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. JVMJ9VM007E Command-line option unrecognised: -version HMYEXEL062E Internal VM error: Failed to create Java VM FAILED. Ill take a look at this too. Regards, Oliver Geir Magnusson Jr. wrote: Oliver and Co : I don't know if you caught this in another thread, but I recently changed the launcher to pass the -showversion cmd line param through to the VM after the launcher prints out its version, so that we can also know the version of the VM. The problem with this brilliant strategy is that J9 doesn't actually deal with -showversion. Can you add that to the list of things to tweak? Either silently swallow it, or print something useful would be my suggestion... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [j9] Doesn't deal with -showversion
You are correct. As I recall, I've never seen J8 actually output a version, ever. It's always been the launcher's version msg. geir Oliver Deakin wrote: Is it just me, or does something similar happen with -version? I get: $ java -version Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. JVMJ9VM007E Command-line option unrecognised: -version HMYEXEL062E Internal VM error: Failed to create Java VM FAILED. Ill take a look at this too. Regards, Oliver Geir Magnusson Jr. wrote: Oliver and Co : I don't know if you caught this in another thread, but I recently changed the launcher to pass the -showversion cmd line param through to the VM after the launcher prints out its version, so that we can also know the version of the VM. The problem with this brilliant strategy is that J9 doesn't actually deal with -showversion. Can you add that to the list of things to tweak? Either silently swallow it, or print something useful would be my suggestion... 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: [JIRA]what is non-bug difference issue?
I vote for closing non-bug issues. 2006/9/13, Andrew Zhang [EMAIL PROTECTED]: On 9/13/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 9/13/06, Tony Wu wrote: When I looked though the old JIRA issues I noticed that many non-bug difference issues had patches and some of them was fixed already. e.g. harmony-401 836 1050 and so on. IMHO the non-bug difference indicates that it is an acceptable difference between RI and Harmony and won't be fixed. Am I right? Yes, I think you are right. Thanks for catching this. IIRC we created this JIRA category just to document difference with RI but not to fix it. IMO you should add comments to such JIRAs asking why a difference was fixed. I suggest that if the bug was fixed for some reason, we should change the component too, i.e, classlib instead of non-bug difference from RI. Another question is for those real non-bug difference from RI JIRAs, what should be the final status, opened or closed? I suggest the latter so that all of JIRAs could be closed eventually. Comments? Thanks! 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] -- Andrew Zhang China Software Development Lab, IBM -- Alexey A. Petrenko 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]volunteer to supply patches for old JIRAs
I have opened a new page at harmony wiki, http://wiki.apache.org/harmony/OLDJIRAS You can get the guideline, the process and a list of old jira issues there. In the list there is a column called ASSIGNEE, you can sign your name there if you are working on that issue. And you may check from this list to ensure there is no one also decide to working on the same issue before you start. If you notice there is something wrong or I missed, feel free to update that page, your effort will bring convenience to whole harmony community: ) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: You might also consider creating a page on the wiki where you outline this process, and record who is signing up for what... geir Tony Wu wrote: so helpful suggestion, thank you Nathan. According to Nathan's suggestion, I suggest we go ahead as below, 1. verify all the issues without patch, supply a patch if possible. 2. for the issues already has a patch, verify the reason why it was ignored, and then a.write testcase if caused by lack of test. b.supply another patch if the patch is out of date. c.add comments to support it if the patch is ok. On 9/13/06, Nathan Beyer [EMAIL PROTECTED] wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. 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 - 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] -- Tony Wu China Software Development Lab, IBM
Re: [classlib][internationalization]Are log messages and tools usage text to be internationalized?
It is unclear what do you mean by the lazy way. If it means that every new message will follow the new convention, then we will never be consistent. If you mean that this task have low priority, then I agree, but, probably, somebody have to open a JIRA issue for this. On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I believe it could be done in lazy way... But it defenetly should be done. SY, Alexey 2006/9/13, Oleg Khaschansky [EMAIL PROTECTED]: Hi, Are there any non-exception messages in the other modules which are already internationalized? I think, if there are any, they should be modified to follow the new convention. -- Oleg On 9/12/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi, Jimmy, Jing Lv wrote: 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. Ilya Okomin wrote: The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient Nice idea guys, +1 from me Regards, 2006/9/11, Ilya Okomin [EMAIL PROTECTED]: Thanks all for useful comments! The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient. If there are no objections I would use default key names module.id for exception messages, and module.prefix.id for certain messages where prefix is log or console (or any other key word depending on the purpose). Regards, Ilya. On 9/11/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Ilya Okomin wrote: Hi all, During rmi module internationalization I've faced with loads of log messages (e.g. take a look at o.a.h.rmi.DefaultRMIClassLoaderSpi). Also some classes (e.g. o.a.h.rmi.compiler.RmicStrings) have strings that are the usage texts of any console tool. I think we shouldn't internationalize such messages, however I'm not really sure about that. If we internationalize them - we'll obtain fully internationalized module it is an advantage. From the other hand - if you have to analyse someone's log, it is useful if the common langauge was used. Moreover, messages.properties file with the list of all messages will be too huge to find appropriate messages for new classes developed later. Any thoughts? IMHO, we have agree on that all console output can be internationalized. If the only problem of a too huge messages.properties file is to find appropriate, I guess we can: 1. Separate the file into several smaller ones, one for console, one for error message, etc. Or 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. In this way we can find some certain message easy. And I prefer 2. -- 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] -- -- Ilya Okomin Intel Middleware Products Division -- Alexei Zakharov, Intel Middleware Product 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] -- Alexey A. Petrenko 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: [classlib]volunteer to supply patches for old JIRAs
My suggestion is to use the wiki page to augment rather than replace what the JIRA can do. For example, I'd suggest that people who are working on a given JIRA note that *in the JIRA*. geir Tony Wu wrote: I have opened a new page at harmony wiki, http://wiki.apache.org/harmony/OLDJIRAS You can get the guideline, the process and a list of old jira issues there. In the list there is a column called ASSIGNEE, you can sign your name there if you are working on that issue. And you may check from this list to ensure there is no one also decide to working on the same issue before you start. If you notice there is something wrong or I missed, feel free to update that page, your effort will bring convenience to whole harmony community: ) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: You might also consider creating a page on the wiki where you outline this process, and record who is signing up for what... geir Tony Wu wrote: so helpful suggestion, thank you Nathan. According to Nathan's suggestion, I suggest we go ahead as below, 1. verify all the issues without patch, supply a patch if possible. 2. for the issues already has a patch, verify the reason why it was ignored, and then a.write testcase if caused by lack of test. b.supply another patch if the patch is out of date. c.add comments to support it if the patch is ok. On 9/13/06, Nathan Beyer [EMAIL PROTECTED] wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. 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 - 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][internationalization]Are log messages and tools usage text to be internationalized?
Low priority. As far as I know Ilya creates subtasks for one JIRA issue to internationalize each module. I think that reinternationalization can be done in same way. SY, Alexey 2006/9/13, Oleg Khaschansky [EMAIL PROTECTED]: It is unclear what do you mean by the lazy way. If it means that every new message will follow the new convention, then we will never be consistent. If you mean that this task have low priority, then I agree, but, probably, somebody have to open a JIRA issue for this. On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I believe it could be done in lazy way... But it defenetly should be done. SY, Alexey 2006/9/13, Oleg Khaschansky [EMAIL PROTECTED]: Hi, Are there any non-exception messages in the other modules which are already internationalized? I think, if there are any, they should be modified to follow the new convention. -- Oleg On 9/12/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi, Jimmy, Jing Lv wrote: 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. Ilya Okomin wrote: The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient Nice idea guys, +1 from me Regards, 2006/9/11, Ilya Okomin [EMAIL PROTECTED]: Thanks all for useful comments! The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient. If there are no objections I would use default key names module.id for exception messages, and module.prefix.id for certain messages where prefix is log or console (or any other key word depending on the purpose). Regards, Ilya. On 9/11/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Ilya Okomin wrote: Hi all, During rmi module internationalization I've faced with loads of log messages (e.g. take a look at o.a.h.rmi.DefaultRMIClassLoaderSpi). Also some classes (e.g. o.a.h.rmi.compiler.RmicStrings) have strings that are the usage texts of any console tool. I think we shouldn't internationalize such messages, however I'm not really sure about that. If we internationalize them - we'll obtain fully internationalized module it is an advantage. From the other hand - if you have to analyse someone's log, it is useful if the common langauge was used. Moreover, messages.properties file with the list of all messages will be too huge to find appropriate messages for new classes developed later. Any thoughts? IMHO, we have agree on that all console output can be internationalized. If the only problem of a too huge messages.properties file is to find appropriate, I guess we can: 1. Separate the file into several smaller ones, one for console, one for error message, etc. Or 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. In this way we can find some certain message easy. And I prefer 2. -- 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] -- -- Ilya Okomin Intel Middleware Products Division -- Alexei Zakharov, Intel Middleware Product 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] -- Alexey A. Petrenko 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] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [classlib]volunteer to supply patches for old JIRAs
Yes, This wiki page is just a place to record who are working on a given old JIRA issue for avoiding duplicate work. maybe the ASSIGNEE causes misunderstanding. I have replaced it to VOLUNTEER :) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: My suggestion is to use the wiki page to augment rather than replace what the JIRA can do. For example, I'd suggest that people who are working on a given JIRA note that *in the JIRA*. geir Tony Wu wrote: I have opened a new page at harmony wiki, http://wiki.apache.org/harmony/OLDJIRAS You can get the guideline, the process and a list of old jira issues there. In the list there is a column called ASSIGNEE, you can sign your name there if you are working on that issue. And you may check from this list to ensure there is no one also decide to working on the same issue before you start. If you notice there is something wrong or I missed, feel free to update that page, your effort will bring convenience to whole harmony community: ) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: You might also consider creating a page on the wiki where you outline this process, and record who is signing up for what... geir Tony Wu wrote: so helpful suggestion, thank you Nathan. According to Nathan's suggestion, I suggest we go ahead as below, 1. verify all the issues without patch, supply a patch if possible. 2. for the issues already has a patch, verify the reason why it was ignored, and then a.write testcase if caused by lack of test. b.supply another patch if the patch is out of date. c.add comments to support it if the patch is ok. On 9/13/06, Nathan Beyer [EMAIL PROTECTED] wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. 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 - 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] -- Tony Wu China Software Development Lab, IBM
Re: [JIRA]what is non-bug difference issue?
+1. My understanding is that when the non-bug difference is discussed it should be opened, but when there's an agreement on it it should be closed. On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I vote for closing non-bug issues. 2006/9/13, Andrew Zhang [EMAIL PROTECTED]: On 9/13/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 9/13/06, Tony Wu wrote: When I looked though the old JIRA issues I noticed that many non-bug difference issues had patches and some of them was fixed already. e.g. harmony-401 836 1050 and so on. IMHO the non-bug difference indicates that it is an acceptable difference between RI and Harmony and won't be fixed. Am I right? Yes, I think you are right. Thanks for catching this. IIRC we created this JIRA category just to document difference with RI but not to fix it. IMO you should add comments to such JIRAs asking why a difference was fixed. I suggest that if the bug was fixed for some reason, we should change the component too, i.e, classlib instead of non-bug difference from RI. Another question is for those real non-bug difference from RI JIRAs, what should be the final status, opened or closed? I suggest the latter so that all of JIRAs could be closed eventually. Comments? Thanks! 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] -- Andrew Zhang China Software Development Lab, IBM -- Alexey A. Petrenko 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: [classlib]volunteer to supply patches for old JIRAs
+1 2006/9/13, Geir Magnusson Jr. [EMAIL PROTECTED]: My suggestion is to use the wiki page to augment rather than replace what the JIRA can do. For example, I'd suggest that people who are working on a given JIRA note that *in the JIRA*. geir Tony Wu wrote: I have opened a new page at harmony wiki, http://wiki.apache.org/harmony/OLDJIRAS You can get the guideline, the process and a list of old jira issues there. In the list there is a column called ASSIGNEE, you can sign your name there if you are working on that issue. And you may check from this list to ensure there is no one also decide to working on the same issue before you start. If you notice there is something wrong or I missed, feel free to update that page, your effort will bring convenience to whole harmony community: ) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: You might also consider creating a page on the wiki where you outline this process, and record who is signing up for what... geir Tony Wu wrote: so helpful suggestion, thank you Nathan. According to Nathan's suggestion, I suggest we go ahead as below, 1. verify all the issues without patch, supply a patch if possible. 2. for the issues already has a patch, verify the reason why it was ignored, and then a.write testcase if caused by lack of test. b.supply another patch if the patch is out of date. c.add comments to support it if the patch is ok. On 9/13/06, Nathan Beyer [EMAIL PROTECTED] wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. 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 - 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] -- Alexey A. Petrenko Intel Middleware Products Division
Re: [classlib][internationalization]Are log messages and tools usage text to be internationalized?
Agree, we should follow the conventions we've reached. For future updates I'll add the convention to the HARMONY-1308 comments, where the way to internationalize messages is described. As for already processed modules, I've found only few error strings and console messages in beans, auth, security, instrument and logging modules. Thus we can leave it as is now for these modules and do it later in lazy way. Messages naming convention is seems to me more important for modules with a huge number of messages of different types, such as x-net and rmi. These modules have not been internationalized yet. Regards, Ilya. On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I believe it could be done in lazy way... But it defenetly should be done. SY, Alexey 2006/9/13, Oleg Khaschansky [EMAIL PROTECTED]: Hi, Are there any non-exception messages in the other modules which are already internationalized? I think, if there are any, they should be modified to follow the new convention. -- Oleg On 9/12/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi, Jimmy, Jing Lv wrote: 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. Ilya Okomin wrote: The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient Nice idea guys, +1 from me Regards, 2006/9/11, Ilya Okomin [EMAIL PROTECTED]: Thanks all for useful comments! The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient. If there are no objections I would use default key names module.id for exception messages, and module.prefix.id for certain messages where prefix is log or console (or any other key word depending on the purpose). Regards, Ilya. On 9/11/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Ilya Okomin wrote: Hi all, During rmi module internationalization I've faced with loads of log messages (e.g. take a look at o.a.h.rmi.DefaultRMIClassLoaderSpi). Also some classes (e.g. o.a.h.rmi.compiler.RmicStrings) have strings that are the usage texts of any console tool. I think we shouldn't internationalize such messages, however I'm not really sure about that. If we internationalize them - we'll obtain fully internationalized module it is an advantage. From the other hand - if you have to analyse someone's log, it is useful if the common langauge was used. Moreover, messages.properties file with the list of all messages will be too huge to find appropriate messages for new classes developed later. Any thoughts? IMHO, we have agree on that all console output can be internationalized. If the only problem of a too huge messages.properties file is to find appropriate, I guess we can: 1. Separate the file into several smaller ones, one for console, one for error message, etc. Or 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. In this way we can find some certain message easy. And I prefer 2. -- 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] -- -- Ilya Okomin Intel Middleware Products Division -- Alexei Zakharov, Intel Middleware Product 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] -- Alexey A. Petrenko 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] -- -- Ilya Okomin Intel Middleware Products Division
Re: [classlib]volunteer to supply patches for old JIRAs
oops! may be just record *someone is in the JIRA* is more lightweight. I'll fix it. any suggest is welcome: ) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: My suggestion is to use the wiki page to augment rather than replace what the JIRA can do. For example, I'd suggest that people who are working on a given JIRA note that *in the JIRA*. geir Tony Wu wrote: I have opened a new page at harmony wiki, http://wiki.apache.org/harmony/OLDJIRAS You can get the guideline, the process and a list of old jira issues there. In the list there is a column called ASSIGNEE, you can sign your name there if you are working on that issue. And you may check from this list to ensure there is no one also decide to working on the same issue before you start. If you notice there is something wrong or I missed, feel free to update that page, your effort will bring convenience to whole harmony community: ) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: You might also consider creating a page on the wiki where you outline this process, and record who is signing up for what... geir Tony Wu wrote: so helpful suggestion, thank you Nathan. According to Nathan's suggestion, I suggest we go ahead as below, 1. verify all the issues without patch, supply a patch if possible. 2. for the issues already has a patch, verify the reason why it was ignored, and then a.write testcase if caused by lack of test. b.supply another patch if the patch is out of date. c.add comments to support it if the patch is ok. On 9/13/06, Nathan Beyer [EMAIL PROTECTED] wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. 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 - 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] -- Tony Wu China Software Development Lab, IBM
Re: [classlib]volunteer to supply patches for old JIRAs
Put comment to the jira issue when you start work on it. You may also change the wiki page if you like, but, please, add a comment right into the jira. And another comment if you can't provide a patch for some reason. It was discussed already. On 9/13/06, Tony Wu [EMAIL PROTECTED] wrote: Yes, This wiki page is just a place to record who are working on a given old JIRA issue for avoiding duplicate work. maybe the ASSIGNEE causes misunderstanding. I have replaced it to VOLUNTEER :) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: My suggestion is to use the wiki page to augment rather than replace what the JIRA can do. For example, I'd suggest that people who are working on a given JIRA note that *in the JIRA*. geir Tony Wu wrote: I have opened a new page at harmony wiki, http://wiki.apache.org/harmony/OLDJIRAS You can get the guideline, the process and a list of old jira issues there. In the list there is a column called ASSIGNEE, you can sign your name there if you are working on that issue. And you may check from this list to ensure there is no one also decide to working on the same issue before you start. If you notice there is something wrong or I missed, feel free to update that page, your effort will bring convenience to whole harmony community: ) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: You might also consider creating a page on the wiki where you outline this process, and record who is signing up for what... geir Tony Wu wrote: so helpful suggestion, thank you Nathan. According to Nathan's suggestion, I suggest we go ahead as below, 1. verify all the issues without patch, supply a patch if possible. 2. for the issues already has a patch, verify the reason why it was ignored, and then a.write testcase if caused by lack of test. b.supply another patch if the patch is out of date. c.add comments to support it if the patch is ok. On 9/13/06, Nathan Beyer [EMAIL PROTECTED] wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. 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 - 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]
Re: [JIRA]what is non-bug difference issue?
2006/9/13, Andrew Zhang [EMAIL PROTECTED]: I suggest that if the bug was fixed for some reason, we should change the component too, i.e, classlib instead of non-bug difference from RI. +1 Another question is for those real non-bug difference from RI JIRAs, what should be the final status, opened or closed? I suggest the latter so that all of JIRAs could be closed eventually. Comments? Thanks! As Oleg I think we should close all discussed and voted non-bug issues but all others let's stay open. - 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]volunteer to supply patches for old JIRAs
Ok, I'll write into guideline and comply with it. On 9/13/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Put comment to the jira issue when you start work on it. You may also change the wiki page if you like, but, please, add a comment right into the jira. And another comment if you can't provide a patch for some reason. It was discussed already. On 9/13/06, Tony Wu [EMAIL PROTECTED] wrote: Yes, This wiki page is just a place to record who are working on a given old JIRA issue for avoiding duplicate work. maybe the ASSIGNEE causes misunderstanding. I have replaced it to VOLUNTEER :) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: My suggestion is to use the wiki page to augment rather than replace what the JIRA can do. For example, I'd suggest that people who are working on a given JIRA note that *in the JIRA*. geir Tony Wu wrote: I have opened a new page at harmony wiki, http://wiki.apache.org/harmony/OLDJIRAS You can get the guideline, the process and a list of old jira issues there. In the list there is a column called ASSIGNEE, you can sign your name there if you are working on that issue. And you may check from this list to ensure there is no one also decide to working on the same issue before you start. If you notice there is something wrong or I missed, feel free to update that page, your effort will bring convenience to whole harmony community: ) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: You might also consider creating a page on the wiki where you outline this process, and record who is signing up for what... geir Tony Wu wrote: so helpful suggestion, thank you Nathan. According to Nathan's suggestion, I suggest we go ahead as below, 1. verify all the issues without patch, supply a patch if possible. 2. for the issues already has a patch, verify the reason why it was ignored, and then a.write testcase if caused by lack of test. b.supply another patch if the patch is out of date. c.add comments to support it if the patch is ok. On 9/13/06, Nathan Beyer [EMAIL PROTECTED] wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. 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 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail:
Re: [JIRA]what is non-bug difference issue?
On 9/13/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: +1. My understanding is that when the non-bug difference is discussed it should be opened, but when there's an agreement on it it should be closed. +1 from me. On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I vote for closing non-bug issues. 2006/9/13, Andrew Zhang [EMAIL PROTECTED]: On 9/13/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 9/13/06, Tony Wu wrote: When I looked though the old JIRA issues I noticed that many non-bug difference issues had patches and some of them was fixed already. e.g. harmony-401 836 1050 and so on. IMHO the non-bug difference indicates that it is an acceptable difference between RI and Harmony and won't be fixed. Am I right? Yes, I think you are right. Thanks for catching this. IIRC we created this JIRA category just to document difference with RI but not to fix it. IMO you should add comments to such JIRAs asking why a difference was fixed. I suggest that if the bug was fixed for some reason, we should change the component too, i.e, classlib instead of non-bug difference from RI. Another question is for those real non-bug difference from RI JIRAs, what should be the final status, opened or closed? I suggest the latter so that all of JIRAs could be closed eventually. Comments? Thanks! 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] -- Andrew Zhang China Software Development Lab, IBM -- Alexey A. Petrenko 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] -- -- Ilya Okomin Intel Middleware Products Division
[jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help community to prepare good fixes and will help committers to spend less time on applying other's patches. As a start we can take Nathan's post with additions from Paulex. I'll add few points from me... Issue reporter: 1. Reporter should try to create as small test case as possible. Patch to test will be highly appreciated. 2. Do not forget to use issue links if applicable. Resolution provider :) : 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on dev-list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. If reporter did not provide patch to test: 2.1.1. If it is possible to create a patch to test then create it. 2.1.2. If it is not possible then note it in the comment. 2.2. Create a patch to fix the issue 2.2.1. Any concerns? Discuss on dev list. Add a link to discussion as a comment. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close the issue. 2. Issue is a bug: 2.1. Apply the patch to test if it exists. 2.2. Check that test fails. 2.3. Apply the fix for the issue 2.4. Check that test does not fail any more 2.5. If there is a problem on previous steps post a comment to JIRA and let resolution provider to resolve. Thoughts? Comments? Additions? SY, Alexey 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- Alexey A. Petrenko 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] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help community to prepare good fixes and will help committers to spend less time on applying other's patches. As a start we can take Nathan's post with additions from Paulex. I'll add few points from me... Issue reporter: 1. Reporter should try to create as small test case as possible. Patch to test will be highly appreciated. 2. Do not forget to use issue links if applicable. Resolution provider :) : 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on dev-list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. If reporter did not provide patch to test: 2.1.1. If it is possible to create a patch to test then create it. 2.1.2. If it is not possible then note it in the comment. 2.2. Create a patch to fix the issue 2.2.1. Any concerns? Discuss on dev list. Add a link to discussion as a comment. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close the issue. 2. Issue is a bug: 2.1. Apply the patch to test if it exists. 2.2. Check that test fails. 2.3. Apply the fix for the issue 2.4. Check that test does not fail any more 2.5. If there is a problem on previous steps post a comment to JIRA and let resolution provider to resolve. Thoughts? Comments? Additions? Sounds excellent! SY, Alexey 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- Alexey A. Petrenko 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] -- Andrew Zhang China Software Development Lab, IBM
Re: [drlvm] Cleaning insides of Class.h header
2006/9/11, Weldon Washburn [EMAIL PROTECTED]: On 9/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/9/10, Pavel Pervov [EMAIL PROTECTED]: Weldon, one of good examples is static_method_block member variable of struct Class. Its size if calculated, memory is allocated for it, but it is never used throughout the code. Roughly 3K classes loaded in simple Eclipse usage scenario (open Eclipse, create hello, world application, run it, exit Eclipse), which means 3K useless memory allocations are made during this simple run. Heap is fragmented and Visual C runtime has locking on each memory allocation. Regards, Pavel. Pavel, I believe the first step should be re-structuring of this ubiquitous and huge (~1800 lines!) header to several more dedicated ones, and regrouping of other related headers, like class_interface.h and classloader.h. Then we can go with reduction of possible duplicates in interfaces, and optimizing structures layouts and memory usage. What do you think? This works also! In any case, please attempt to break the work into several stages. As the very first step, I volunteer to extract items related to class-file parsing. The idea is to move methods like Class_Member::parseXXX() to a new ClassFileParser class and declare this class a friend of Class_Member's descendants. This way we'll isolate CFF parsing utilities from ordinary user interface of Class members. I will proceed if nobody objects. -- Alexey [snip] - 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] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
And the resolution provider should not forget to add a comment when he is starting development of the patch to prevent collisions. If the resolution provider is a committer he simply assigns the bug. On 9/13/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help community to prepare good fixes and will help committers to spend less time on applying other's patches. As a start we can take Nathan's post with additions from Paulex. I'll add few points from me... Issue reporter: 1. Reporter should try to create as small test case as possible. Patch to test will be highly appreciated. 2. Do not forget to use issue links if applicable. Resolution provider :) : 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on dev-list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. If reporter did not provide patch to test: 2.1.1. If it is possible to create a patch to test then create it. 2.1.2. If it is not possible then note it in the comment. 2.2. Create a patch to fix the issue 2.2.1. Any concerns? Discuss on dev list. Add a link to discussion as a comment. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close the issue. 2. Issue is a bug: 2.1. Apply the patch to test if it exists. 2.2. Check that test fails. 2.3. Apply the fix for the issue 2.4. Check that test does not fail any more 2.5. If there is a problem on previous steps post a comment to JIRA and let resolution provider to resolve. Thoughts? Comments? Additions? Sounds excellent! SY, Alexey 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- Alexey A. Petrenko 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] -- Andrew Zhang 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: [general] svn:eol-style = native (LF vs CRLF)
On 8/17/06, Tim Ellison [EMAIL PROTECTED] wrote: Sure -- just blat them all in one go. Regards, Tim Nathan Beyer wrote: Does anyone have objections to setting the svn:eol-style to native for *.java, *.c, *.h, *.cpp, *.xml as we move forward with updates and changes? I believe this is the suggested setting for committers [1][2]. The only file types that I know of that must have a specific line ending are *.dsp and *.dsw, which must be CRLF. Some files are already set this way and others are not, but if we go about updating these as we move forward, this should normalize checkouts for everyone. Hi to all! Is anything done on this issue? I found some classes in [security] module has different eol style even within one package. When I make a patch for these classes, apply it (on Windows) - I find, that classes, that were in svn reporitory with 'unix' eol now have 'dos' eol. Thus if I make diff again - it shows me, that some files are to be fully rewrited with 'dos' eol, and I can't see the differences I've made. Probably I've missed something with svn settings or smth else? Thanks, Ilya. -Nathan Beyer [1] http://www.apache.org/dev/version-control.html#https-svn [2] http://www.apache.org/dev/svn-eol-style.txt -- 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: [drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints
2006/9/13, Pavel Rebriy [EMAIL PROTECTED]: I'm starting the implementation of Single Step event for JIT mode. The initial draft is filed in H-1422 [1]. The implemented function jvmti_SingleStepLocation predicts the next execution bytecode which can be used from Single Step event. [1] http://issues.apache.org/jira/browse/HARMONY-1422 Hello Pavel. Thanks a lot for your assistance. I like the interface for next bytecode prediction and started to use it in my SingleStep implementation. The current state of work looks like it is mostly done so I decided to publish it in JIRA [1]. I've just made it to compile, so it may contain bugs :) bug I decided to share the code since it looks like this work interests other people. [1] http://issues.apache.org/jira/browse/HARMONY-1455?page=all -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] Cleaning insides of Class.h header
Not sure C++ friends are good design. Although class format is something one might want to localize to be known to only one entity (like ClassFileParser), it is much better to provide format extractor to anybody interested in its use and let them manage their content by themselves. This is how current implementation is designed. If something should be improved, ByteReader can be extended to provide more advanced format extraction methods than it has now. Treat the above as I object. :) If you see some design issues in current class parsing code, please, fill free to share. Best regards, Pavel. On 9/13/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/9/11, Weldon Washburn [EMAIL PROTECTED]: On 9/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/9/10, Pavel Pervov [EMAIL PROTECTED]: Weldon, one of good examples is static_method_block member variable of struct Class. Its size if calculated, memory is allocated for it, but it is never used throughout the code. Roughly 3K classes loaded in simple Eclipse usage scenario (open Eclipse, create hello, world application, run it, exit Eclipse), which means 3K useless memory allocations are made during this simple run. Heap is fragmented and Visual C runtime has locking on each memory allocation. Regards, Pavel. Pavel, I believe the first step should be re-structuring of this ubiquitous and huge (~1800 lines!) header to several more dedicated ones, and regrouping of other related headers, like class_interface.h and classloader.h. Then we can go with reduction of possible duplicates in interfaces, and optimizing structures layouts and memory usage. What do you think? This works also! In any case, please attempt to break the work into several stages. As the very first step, I volunteer to extract items related to class-file parsing. The idea is to move methods like Class_Member::parseXXX() to a new ClassFileParser class and declare this class a friend of Class_Member's descendants. This way we'll isolate CFF parsing utilities from ordinary user interface of Class members. I will proceed if nobody objects. -- Alexey [snip] - 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] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
and resolution provider should verify the application. On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help community to prepare good fixes and will help committers to spend less time on applying other's patches. As a start we can take Nathan's post with additions from Paulex. I'll add few points from me... Issue reporter: 1. Reporter should try to create as small test case as possible. Patch to test will be highly appreciated. 2. Do not forget to use issue links if applicable. Resolution provider :) : 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on dev-list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. If reporter did not provide patch to test: 2.1.1. If it is possible to create a patch to test then create it. 2.1.2. If it is not possible then note it in the comment. 2.2. Create a patch to fix the issue 2.2.1. Any concerns? Discuss on dev list. Add a link to discussion as a comment. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close the issue. 2. Issue is a bug: 2.1. Apply the patch to test if it exists. 2.2. Check that test fails. 2.3. Apply the fix for the issue 2.4. Check that test does not fail any more 2.5. If there is a problem on previous steps post a comment to JIRA and let resolution provider to resolve. Thoughts? Comments? Additions? SY, Alexey 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- Alexey A. Petrenko 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] -- Tony Wu China Software Development Lab, IBM
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help community to prepare good fixes and will help committers to spend less time on applying other's patches. As a start we can take Nathan's post with additions from Paulex. I'll add few points from me... Excellent ;-) Only a few comments. Issue reporter: 1. Reporter should try to create as small test case as possible. Patch to test will be highly appreciated. 2. Do not forget to use issue links if applicable. 0. Explicitly address: what is the expected behavior, and what's the actual behavior of Harmony? Resolution provider :) : 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on dev-list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. If reporter did not provide patch to test: 2.1.1. If it is possible to create a patch to test then create it. 2.1.2. If it is not possible then note it in the comment. 2.2. Create a patch to fix the issue 2.2.1. Any concerns? Discuss on dev list. Add a link to discussion as a comment. We could also suggest some requirements for patch: e.g., avoid using absolute path, provide a shell if necessary, 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close the issue. 2. Issue is a bug: 2.1. Apply the patch to test if it exists. 2.2. Check that test fails. 2.3. Apply the fix for the issue 2.4. Check that test does not fail any more And make sure all tests pass ;-) 2.5. If there is a problem on previous steps post a comment to JIRA and let resolution provider to resolve. Thoughts? Comments? Additions? SY, Alexey 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- Alexey A. Petrenko 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 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] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
and resolution provider should verify the application. Or, probably, the reporter may do it also. On 9/13/06, Tony Wu [EMAIL PROTECTED] wrote: and resolution provider should verify the application. On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help community to prepare good fixes and will help committers to spend less time on applying other's patches. As a start we can take Nathan's post with additions from Paulex. I'll add few points from me... Issue reporter: 1. Reporter should try to create as small test case as possible. Patch to test will be highly appreciated. 2. Do not forget to use issue links if applicable. Resolution provider :) : 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on dev-list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. If reporter did not provide patch to test: 2.1.1. If it is possible to create a patch to test then create it. 2.1.2. If it is not possible then note it in the comment. 2.2. Create a patch to fix the issue 2.2.1. Any concerns? Discuss on dev list. Add a link to discussion as a comment. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close the issue. 2. Issue is a bug: 2.1. Apply the patch to test if it exists. 2.2. Check that test fails. 2.3. Apply the fix for the issue 2.4. Check that test does not fail any more 2.5. If there is a problem on previous steps post a comment to JIRA and let resolution provider to resolve. Thoughts? Comments? Additions? SY, Alexey 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- Alexey A. Petrenko 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] -- Tony Wu 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]A subject to profiling instrumenting
Qiong, I tried to build your vm.tar.bz2 file and have the following problems: 1) RUNTIME_OBJ_PATTERN_FILE_NAME is not defined but used 2) open/write_thread.h file is absent 3) mutex_write_thread is used in jit_runtime_support.cpp but is not declared. Can you post only diffs file to JIRA with write_thread.h file included? On 9/7/06, zouqiong [EMAIL PROTECTED] wrote: This is the JIRA number. https://issues.apache.org/jira/browse/HARMONY-1406 I upload the vm code, it`s not so large, 3.8 Megabytes. And the code still have bugs when profile the AALOAD. But I am not sure the GETFIELD and GETSTATIC are totally right. :( If you want to profile the AALOAD, please look at the _TEST_ macro in gen_aload() method. And the GETFIELD and GETSTATIC is opened automatically. Now I have the following schedule: 1.First implement the instrument which helps to profile the access patterns 2.Second using sampling to implement the instrument. 2006/9/7, Mikhail Fursov [EMAIL PROTECTED]: On 9/6/06, zouqiong [EMAIL PROTECTED] wrote: Ok, I will put my diffs to the JIRA later. And I have solved the issue I asked two days ago. Ok, I will wait the JIRA number from you. It needs liblwdis.so supporting. Check JIRA 1402 for it. http://issues.apache.org/jira/browse/HARMONY-1402 -- Mikhail Fursov -- Best Regards, Qiong,Zou -- Mikhail Fursov
Re: [drlvm] putting kernel.jar in jre/bin/default
2006/9/13, Paulex Yang [EMAIL PROTECTED]: Alexey Varlamov wrote: 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Alexey Varlamov wrote: Looks like sending my reply failed, here is a second try: I'm not sure I catch up what you mean, about Emma, Harmony's current test coverage exclude list[1] shows that not all classes can be instrumented, I don't think it is due to the position of kernel classes. Paulex, I'm sorry for causing confusion - I was a bit wrong. I experienced troubles with complete overriiding via -Xbootclasspath: argument, and just prepending -Xbootclasspath/p: works OK. Not all kernel classes are instrumented due to dependencies in instrumentation code itself, this is of course different thing. Agreed. Further, for the special requirement(instrument, AOP, or so), anything prevent the user to add -Xbootclasspath/p to replace the kernel class implementation? Or, what's the difference on this between RI and current Harmony? So the difference is that for -Xbootclasspath:, launcher+j9 always stealthily prepend luni-kernel.jar to user-specified bootclasspath, while RI allows fully custom bootclasspath. This is interesting. Yes, I think we should handle it, although it probably won't work to replace the kernel class implementation due to the VM dependency, we have no reason forbidding user to do this. Just had a look at how the normal bootclasspath(luni.jar, text.jar...) is processed, the interesting thing is they are loaded by JNI_OnLoad of hyluni.dll(libhyluni.so), with the source codes located in modules/luni/src/native/luni/shared/luniglob.c (It is interesting because I thought it was in launcher, but maybe the original author had similar issues to get the absolute path of jre/lib/boot). And it takes a straightforward way to handle the -Xbootclasspath: if this argument is passed in command line, just give up parsing the default bootclasspath. I have two thoughts on this: 1. If this is acceptable, we can deal with kernel class in similar way. 2. Supposing we can have better solution to locate the jre path, is there any chance to merge the both bootclasspath handling(kernel and normal) to launcher, so that it doesn't need to deal with bootclasspath twice? Or any other proposals? We had a discussion about this month ago [1], and the main argument against the launcher was there may be several launchers, moreover bootclasspath has to be set for any application that calls JNI_CreateJavaVM. So no better place than luni natives was suggested for the shared part of the bootlclasspath. BTW, there is reliability fix HARMONY-1243 related to this and still unresolved... OK, I'll look at it. But as kernel classes packaging is VM-specific, the VM should take care of them. Evidently the same argument about launcher applies to kernels as well, so current way with harmonyvm.properties is a sort of workaround anyway. And to handle the -Xbooclasspath: issue, there should be double filtering: check user-supplied arguments then filter autoloaded ones from harmonyvm.properties. Smells not really good ;). That's what I meant... More logical would be to get rid of handling harmonyvm.properties in launcher entirely, leaving this to VM if it needs it. I thought about this, but launcher actually uses standard invocation API to create VM, so if VM's invocation API implementation takes care of the kernel class(which are part of Harmony VMI), it's a little difficult for VM vendor to provide an adaptive VM, adaptive here means it can adapt Harmony classlib as well as others without too much effort, say, GNU Classpath(or maybe Sun's Open Sourced Classlib). I still prefer to handle the Harmony VMI related things in *Harmony* Launcher. Hmm, I'm not sure I understand how the Harmony launcher could be helpful to an adaptive VM, until the VM can detect by which launcher it is invoked and adapt accordingly. But the latter is evidently unnecessary complication... The launcher imposes certain requirements to VM: - to handle luni part of bootclasspath on it's own; - to recognize Harmony-specifc arguments, as _org.apache.harmony.vmi.portlib; And there are other implications of Harmony classlib, like explicit loading of certain natives, etc. So the VM must have an adaptive harmony layer anyway... And anyway, if the normal bootclasspath should be taken care of in luni, while kernel bootclasspath must be dealed with elsewhere, the double filtering is hard to avoid. [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/11776/focus=11818 -- 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 :
Re: [drlvm] putting kernel.jar in jre/bin/default
2006/9/13, Alexey Varlamov [EMAIL PROTECTED]: 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Alexey Varlamov wrote: 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Alexey Varlamov wrote: Looks like sending my reply failed, here is a second try: I'm not sure I catch up what you mean, about Emma, Harmony's current test coverage exclude list[1] shows that not all classes can be instrumented, I don't think it is due to the position of kernel classes. Paulex, I'm sorry for causing confusion - I was a bit wrong. I experienced troubles with complete overriiding via -Xbootclasspath: argument, and just prepending -Xbootclasspath/p: works OK. Not all kernel classes are instrumented due to dependencies in instrumentation code itself, this is of course different thing. Agreed. Further, for the special requirement(instrument, AOP, or so), anything prevent the user to add -Xbootclasspath/p to replace the kernel class implementation? Or, what's the difference on this between RI and current Harmony? So the difference is that for -Xbootclasspath:, launcher+j9 always stealthily prepend luni-kernel.jar to user-specified bootclasspath, while RI allows fully custom bootclasspath. This is interesting. Yes, I think we should handle it, although it probably won't work to replace the kernel class implementation due to the VM dependency, we have no reason forbidding user to do this. Just had a look at how the normal bootclasspath(luni.jar, text.jar...) is processed, the interesting thing is they are loaded by JNI_OnLoad of hyluni.dll(libhyluni.so), with the source codes located in modules/luni/src/native/luni/shared/luniglob.c (It is interesting because I thought it was in launcher, but maybe the original author had similar issues to get the absolute path of jre/lib/boot). And it takes a straightforward way to handle the -Xbootclasspath: if this argument is passed in command line, just give up parsing the default bootclasspath. I have two thoughts on this: 1. If this is acceptable, we can deal with kernel class in similar way. 2. Supposing we can have better solution to locate the jre path, is there any chance to merge the both bootclasspath handling(kernel and normal) to launcher, so that it doesn't need to deal with bootclasspath twice? Or any other proposals? We had a discussion about this month ago [1], and the main argument against the launcher was there may be several launchers, moreover bootclasspath has to be set for any application that calls JNI_CreateJavaVM. So no better place than luni natives was suggested for the shared part of the bootlclasspath. BTW, there is reliability fix HARMONY-1243 related to this and still unresolved... OK, I'll look at it. But as kernel classes packaging is VM-specific, the VM should take care of them. Evidently the same argument about launcher applies to kernels as well, so current way with harmonyvm.properties is a sort of workaround anyway. And to handle the -Xbooclasspath: issue, there should be double filtering: check user-supplied arguments then filter autoloaded ones from harmonyvm.properties. Smells not really good ;). That's what I meant... More logical would be to get rid of handling harmonyvm.properties in launcher entirely, leaving this to VM if it needs it. I thought about this, but launcher actually uses standard invocation API to create VM, so if VM's invocation API implementation takes care of the kernel class(which are part of Harmony VMI), it's a little difficult for VM vendor to provide an adaptive VM, adaptive here means it can adapt Harmony classlib as well as others without too much effort, say, GNU Classpath(or maybe Sun's Open Sourced Classlib). I still prefer to handle the Harmony VMI related things in *Harmony* Launcher. Hmm, I'm not sure I understand how the Harmony launcher could be helpful to an adaptive VM, until the VM can detect by which launcher it is invoked and adapt accordingly. But the latter is evidently unnecessary complication... The launcher imposes certain requirements to VM: - to handle luni part of bootclasspath on it's own; - to recognize Harmony-specifc arguments, as _org.apache.harmony.vmi.portlib; And there are other implications of Harmony classlib, like explicit loading of certain natives, etc. So the VM must have an adaptive harmony layer anyway... And again, an Invocation-capable VM is supposed to work with arbitrary launcher, therefore the Harmony launcher should be minimized. And anyway, if the normal bootclasspath should be taken care of in luni, while kernel bootclasspath must be dealed with elsewhere, the double filtering is hard to avoid. [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/11776/focus=11818 -- Alexey - Terms of use :
Re: [general] svn:eol-style = native (LF vs CRLF)
I noticed that there are some .java files in security module has set the svn:eol-style to native, that is, a EOL marker will be added to every line of this file when commit to repository. And when you checkout them, the EOL marker will be replaced according your os, CRLF on windows and LF on Unix. so, I think you should create and apply patch on the same platform because diff file can not handle the EOL marker :( IMHO, the svn:eol-style is not necessary, so that svn can store the file as original bytes and you can retrieve it without any change. Many IDEs are well prepared to understand the both EOL formats. On 9/13/06, Ilya Okomin [EMAIL PROTECTED] wrote: On 8/17/06, Tim Ellison [EMAIL PROTECTED] wrote: Sure -- just blat them all in one go. Regards, Tim Nathan Beyer wrote: Does anyone have objections to setting the svn:eol-style to native for *.java, *.c, *.h, *.cpp, *.xml as we move forward with updates and changes? I believe this is the suggested setting for committers [1][2]. The only file types that I know of that must have a specific line ending are *.dsp and *.dsw, which must be CRLF. Some files are already set this way and others are not, but if we go about updating these as we move forward, this should normalize checkouts for everyone. Hi to all! Is anything done on this issue? I found some classes in [security] module has different eol style even within one package. When I make a patch for these classes, apply it (on Windows) - I find, that classes, that were in svn reporitory with 'unix' eol now have 'dos' eol. Thus if I make diff again - it shows me, that some files are to be fully rewrited with 'dos' eol, and I can't see the differences I've made. Probably I've missed something with svn settings or smth else? Thanks, Ilya. -Nathan Beyer [1] http://www.apache.org/dev/version-control.html#https-svn [2] http://www.apache.org/dev/svn-eol-style.txt -- 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 -- Tony Wu China Software Development Lab, IBM
Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?
Geir Magnusson Jr. wrote: This came up in another thread. Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on there being a setInterruptAction() method on java.lang.Thread. I certainly think that this kind of thing should be documented, so the question - should we add this to our Thread stub class? Yes we should - I didn't realise initially that this method was being used (since it was private). Now we know it's in use in AbstractInterruptibleChannel, we'd better put some doc in for future kernel writers. Can someone just bring back the original comments and method stub that was there? Regards, Oliver geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (HARMONY-1453) [classlib][awt] Incorrect behavior of methods Graphics.draw3DRect and Graphics.fill3DRect
Committers,
Could someone be so kind and change the component for this issue to
the classlib, please? Unfortunately, I forgot to set it when created
the issue and unable to change.
And, probably, apply the patch also :)
thanks,
--
Oleg
-- Forwarded message --
From: Oleg Khaschansky (JIRA) [EMAIL PROTECTED]
Date: Sep 13, 2006 3:10 PM
Subject: [jira] Updated: (HARMONY-1453) [classlib][awt] Incorrect
behavior of methods Graphics.draw3DRect and Graphics.fill3DRect
To: [EMAIL PROTECTED]
[ http://issues.apache.org/jira/browse/HARMONY-1453?page=all ]
Oleg Khaschansky updated HARMONY-1453:
--
Attachment: harmony-1453.patch
Patch with reimplemented draw3DRect and fill3DRect methods. All listed
issues fixed. AWT tests passed on win32 with this patch.
[classlib][awt] Incorrect behavior of methods Graphics.draw3DRect and
Graphics.fill3DRect
-
Key: HARMONY-1453
URL: http://issues.apache.org/jira/browse/HARMONY-1453
Project: Harmony
Issue Type: Bug
Reporter: Oleg Khaschansky
Priority: Minor
Attachments: harmony-1453.patch
1. Methods Graphics.draw3DRect(int x, int y, int width, int height, boolean
raised) and Graphics.fill3DRect(int x, int y, int width, int height, boolean
raised) use their width parameter instead of height to draw the lines. This
result in a quads instead of rectangles.
2. Calling these methods will reset paint attribute of the graphics context.
Harmony implementation of these methods calls setColor method, which updates
the paint attribute. This behavior is illogical and differs from RI.
3. Rendering of lines and filled rectangles in these methods uses paint and stroke
defined in the Graphics2D. This behavior contradicts the spec for the Graphics2D class:
The draw3DRect and fill3DRect methods were implemented in terms of the drawLine and
fillRect methods in the Graphics class which would predicate their behavior upon the
current Stroke and Paint objects in a Graphics2D context. This class overrides those
implementations with versions that use the current Color exclusively, overriding the
current Paint and which uses fillRect to describe the exact same behavior as the
preexisting methods regardless of the setting of the current Stroke.
4. If the rectangle is not raised then fill3Drect fills it with the incorrect
color (behavior differs from RI).
5. There are per-pixel differences between RI and harmony implementations.
I will attach a patch for this issue soon.
The following test reveals all this incorrect behavior:
== test.java ===
import java.awt.*;
import java.awt.geom.AffineTransform;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
public class test {
public static void main(String[] args) {
Frame f = new Frame(test);
f.add( new Canvas(){
public void paint(Graphics g) {
Graphics2D g2 = (Graphics2D) g;
g2.setColor(Color.lightGray);
g2.setStroke(new BasicStroke(5));
g2.setPaint(new GradientPaint(0,0,Color.red,100,100,Color.blue,
true));
g2.fill3DRect(20, 20, g.getClipBounds().width-40,
g.getClipBounds().height-40, true);
g2.draw3DRect(10, 10, g.getClipBounds().width-20,
g.getClipBounds().height-20, true);
g2.fillRect(40, 40, g.getClipBounds().width-80,
g.getClipBounds().height-80);
int y1 = (g.getClipBounds().height / 30);
int x1 = (g.getClipBounds().width / 20);
g2.setTransform(AffineTransform.getScaleInstance(10, 10));
g2.setColor(Color.gray);
g2.draw3DRect(x1, y1, 3, 3, false);
g2.fill3DRect(x1, y1*2, 4, 4, false);
}
});
f.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent we) {
we.getWindow().dispose();
}
});
f.setSize(200, 300);
f.show();
}
}
--
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: [general] svn:eol-style = native (LF vs CRLF)
After going through this thread, I realize there is another possibility to encounter the problem even you are working on single platform, 1.the file you are working on does not have eol-style property and the latest commit is performed on Unix system. 2.you create a patch. 3.when applying the patch, your patch-apply tool consider it is on win32 system and convert all the LF to CRLF. 4.your local copy is dos style and the remote copy is unix style so you get totally different files when compare the bytes. I have no idea wyh some of the .java files have the property but others doesnt in the meanwhile. hope it will do some help. On 9/13/06, Ilya Okomin [EMAIL PROTECTED] wrote: On 8/17/06, Tim Ellison [EMAIL PROTECTED] wrote: Sure -- just blat them all in one go. Regards, Tim Nathan Beyer wrote: Does anyone have objections to setting the svn:eol-style to native for *.java, *.c, *.h, *.cpp, *.xml as we move forward with updates and changes? I believe this is the suggested setting for committers [1][2]. The only file types that I know of that must have a specific line ending are *.dsp and *.dsw, which must be CRLF. Some files are already set this way and others are not, but if we go about updating these as we move forward, this should normalize checkouts for everyone. Hi to all! Is anything done on this issue? I found some classes in [security] module has different eol style even within one package. When I make a patch for these classes, apply it (on Windows) - I find, that classes, that were in svn reporitory with 'unix' eol now have 'dos' eol. Thus if I make diff again - it shows me, that some files are to be fully rewrited with 'dos' eol, and I can't see the differences I've made. Probably I've missed something with svn settings or smth else? Thanks, Ilya. -Nathan Beyer [1] http://www.apache.org/dev/version-control.html#https-svn [2] http://www.apache.org/dev/svn-eol-style.txt -- 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 -- Tony Wu China Software Development Lab, IBM
Re: [drlvm] Cleaning insides of Class.h header
Alexey, I agree with what Pavel Pervov says below. In looking at the code in vmcore/src/class_support, creating another class adds another layer of complexity and will make removal of unnecessary code more difficult. C++ friends should be used very sparingly. Can you try Pavel's suggestion below as a first step? - Weldon On 9/13/06, Pavel Pervov [EMAIL PROTECTED] wrote: Not sure C++ friends are good design. Although class format is something one might want to localize to be known to only one entity (like ClassFileParser), it is much better to provide format extractor to anybody interested in its use and let them manage their content by themselves. This is how current implementation is designed. If something should be improved, ByteReader can be extended to provide more advanced format extraction methods than it has now. Treat the above as I object. :) If you see some design issues in current class parsing code, please, fill free to share. Best regards, Pavel. On 9/13/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/9/11, Weldon Washburn [EMAIL PROTECTED]: On 9/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/9/10, Pavel Pervov [EMAIL PROTECTED]: Weldon, one of good examples is static_method_block member variable of struct Class. Its size if calculated, memory is allocated for it, but it is never used throughout the code. Roughly 3K classes loaded in simple Eclipse usage scenario (open Eclipse, create hello, world application, run it, exit Eclipse), which means 3K useless memory allocations are made during this simple run. Heap is fragmented and Visual C runtime has locking on each memory allocation. Regards, Pavel. Pavel, I believe the first step should be re-structuring of this ubiquitous and huge (~1800 lines!) header to several more dedicated ones, and regrouping of other related headers, like class_interface.h and classloader.h. Then we can go with reduction of possible duplicates in interfaces, and optimizing structures layouts and memory usage. What do you think? This works also! In any case, please attempt to break the work into several stages. As the very first step, I volunteer to extract items related to class-file parsing. The idea is to move methods like Class_Member::parseXXX() to a new ClassFileParser class and declare this class a friend of Class_Member's descendants. This way we'll isolate CFF parsing utilities from ordinary user interface of Class members. I will proceed if nobody objects. -- Alexey [snip] - 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
Re: [general] svn:eol-style = native (LF vs CRLF)
2006/9/13, Tony Wu [EMAIL PROTECTED]: I noticed that there are some .java files in security module has set the svn:eol-style to native, that is, a EOL marker will be added to every line of this file when commit to repository. And when you checkout them, the EOL marker will be replaced according your os, CRLF on windows and LF on Unix. so, I think you should create and apply patch on the same platform because diff file can not handle the EOL marker :( As far as I know Ilya experienced this problem on Windows platform without switching to Linux or elsewhere. SY, Alexey IMHO, the svn:eol-style is not necessary, so that svn can store the file as original bytes and you can retrieve it without any change. Many IDEs are well prepared to understand the both EOL formats. On 9/13/06, Ilya Okomin [EMAIL PROTECTED] wrote: On 8/17/06, Tim Ellison [EMAIL PROTECTED] wrote: Sure -- just blat them all in one go. Regards, Tim Nathan Beyer wrote: Does anyone have objections to setting the svn:eol-style to native for *.java, *.c, *.h, *.cpp, *.xml as we move forward with updates and changes? I believe this is the suggested setting for committers [1][2]. The only file types that I know of that must have a specific line ending are *.dsp and *.dsw, which must be CRLF. Some files are already set this way and others are not, but if we go about updating these as we move forward, this should normalize checkouts for everyone. Hi to all! Is anything done on this issue? I found some classes in [security] module has different eol style even within one package. When I make a patch for these classes, apply it (on Windows) - I find, that classes, that were in svn reporitory with 'unix' eol now have 'dos' eol. Thus if I make diff again - it shows me, that some files are to be fully rewrited with 'dos' eol, and I can't see the differences I've made. Probably I've missed something with svn settings or smth else? Thanks, Ilya. -Nathan Beyer [1] http://www.apache.org/dev/version-control.html#https-svn [2] http://www.apache.org/dev/svn-eol-style.txt -- 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 -- Tony Wu China Software Development Lab, IBM -- Alexey A. Petrenko 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] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
2006/9/13, Richard Liang [EMAIL PROTECTED]: On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help community to prepare good fixes and will help committers to spend less time on applying other's patches. As a start we can take Nathan's post with additions from Paulex. I'll add few points from me... Excellent ;-) Only a few comments. Issue reporter: 1. Reporter should try to create as small test case as possible. Patch to test will be highly appreciated. 2. Do not forget to use issue links if applicable. 0. Explicitly address: what is the expected behavior, and what's the actual behavior of Harmony? Right! With the link to spec if possible. Resolution provider :) : 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on dev-list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. If reporter did not provide patch to test: 2.1.1. If it is possible to create a patch to test then create it. 2.1.2. If it is not possible then note it in the comment. 2.2. Create a patch to fix the issue 2.2.1. Any concerns? Discuss on dev list. Add a link to discussion as a comment. We could also suggest some requirements for patch: e.g., avoid using absolute path, provide a shell if necessary, Probably such requirements can be done as separate paragraph or even separate document. And leave this instruction as a simple algorithm. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close the issue. 2. Issue is a bug: 2.1. Apply the patch to test if it exists. 2.2. Check that test fails. 2.3. Apply the fix for the issue 2.4. Check that test does not fail any more And make sure all tests pass ;-) Right! :) 2.5. If there is a problem on previous steps post a comment to JIRA and let resolution provider to resolve. Thoughts? Comments? Additions? SY, Alexey 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- Alexey A. Petrenko 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 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] -- Alexey A. Petrenko 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] Cleaning insides of Class.h header
2006/9/13, Pavel Pervov [EMAIL PROTECTED]:
Not sure C++ friends are good design.
Umm, what is wrong with friends?
Although class format is something
one might want to localize to be known to only one entity (like
ClassFileParser), it is much better to provide format extractor to anybody
interested in its use and let them manage their content by themselves.
This is how current implementation is designed.
Both approaches have pros cons, very good example in Java are
Serializable and Externalizable alternatives. Conceptually I have no
strong preference for our case. OK, we can choose the current design
for minimal disruption, then should follow it more consistently. For
example, private members of Method _parse_exceptions()
_parse_local_vars(), _parse_line_numbers(), _parse_code() actually
should be public members of respective entities. Those entities in
turn need not be declared in Class.h, as Method incapsulates pointers
to such members.
BTW, this would also allow us to economize on size of Method
instances, after we sort out such entities - e.g. instead of keeping
bunch of Code-related members (~10 members) directly, store just 1
pointer and win memory on absract and interface methods, etc. Of
course care should be taken to not incur performance penalty for extra
indirection, but you see the approach.
What do you think?
If something should be
improved, ByteReader can be extended to provide more advanced format
extraction methods than it has now.
I don't think so - if we follow the selected approach consistently,
ByteReader hardly needs to provide more... Please correct me if you
have concrete ideas.
Treat the above as I object. :)
If you see some design issues in current class parsing code, please, fill
free to share.
The problem is not parsing code itself, you know - just when someone
does a trivial fix in LocalVarTable parsing procedure, I have to
recompile the whole VM + GC (and maybe even JIT)! Where are you, vm
modularity ;)
Well, for the parsing code - I do not appreciate that JNI-like coding
pattern If (troubles) {RAISE_FAILURE(); return false;} used
everywhere in Class_File_Loader.cpp, would prefer using exceptions -
but that is another story.
Best regards,
Pavel.
On 9/13/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/9/11, Weldon Washburn [EMAIL PROTECTED]:
On 9/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/9/10, Pavel Pervov [EMAIL PROTECTED]:
Weldon,
one of good examples is static_method_block member variable of
struct
Class.
Its size if calculated, memory is allocated for it, but it is never
used
throughout the code. Roughly 3K classes loaded in simple Eclipse
usage
scenario (open Eclipse, create hello, world application, run it,
exit
Eclipse), which means 3K useless memory allocations are made during
this
simple run. Heap is fragmented and Visual C runtime has locking on
each
memory allocation.
Regards,
Pavel.
Pavel,
I believe the first step should be re-structuring of this ubiquitous
and huge (~1800 lines!) header to several more dedicated ones, and
regrouping of other related headers, like class_interface.h and
classloader.h.
Then we can go with reduction of possible duplicates in interfaces,
and optimizing structures layouts and memory usage.
What do you think?
This works also! In any case, please attempt to break the work into
several
stages.
As the very first step, I volunteer to extract items related to
class-file parsing. The idea is to move methods like
Class_Member::parseXXX() to a new ClassFileParser class and declare
this class a friend of Class_Member's descendants. This way we'll
isolate CFF parsing utilities from ordinary user interface of Class
members.
I will proceed if nobody objects.
--
Alexey
[snip]
-
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] Need help debugging
I'd like to understand why this is no longer necessary.
(Just provide some background for all of us to help start understanding
the structure and operation of DLRVM)
geir
Vladimir Gorr wrote:
Probably, you didn't note I've commented this fragment of code (firts
last
lines).
Sorry I didn't mention about this before. After these changes I could
sucessfully start the ActiveMQ.
Before I have the following error:
Assertion failed: size = skip
Trying to skip 6 frames but there are only 5 frames in stack
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/kernel_classes/native/org_apache_harmony_vm_VMStack.cpp:301:
_jobject* Java_org_apache_harmony_vm_VMStack_getStackTrace(JNIEnv*,
_jobject*, _jobject*): Assertion `size = skip' failed.
abort_handler()
Thanks,
Vladimir.
On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm a little skeptical, as I had that change in before you first tested
and found a problem, right?
geir
Vladimir Gorr wrote:
vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp
...
* /*
*// skip Thread.runImpl()
size--;
// skip the VMStart$MainThread if one exits from the bottom of the
stack
// along with 2 reflection frames used to invoke method main
static String* starter_String =
genv-string_pool.lookup(java/lang/VMStart$MainThread);
Method_Handle method = frames[size].method;
assert(method);
// skip only for main application thread
if (!strcmp(method_get_name(method), runImpl)
method-get_class()-name == starter_String) {
int rem = size - skip-1;
size -= rem 2 ? rem : 2;
}
ASSERT(size = skip, Trying to skip skip
frames but there are only
size frames in stack);
**/*
...
Thanks,
Vladimir.
On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I was able to sucessfully run both applications (Eclipse ActiveMQ)
for
the
recent build.
what changed?
geir
Thanks,
Vladimir.
On 9/12/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
doh. Thanks. I feel dumb for not trying the simplest thing first
:)
There's a test...
geir
Anton Luht wrote:
Hello,
The 'java -jar' launcher prints dump and exits even on a minimal
HelloWorld app jar - please see
http://issues.apache.org/jira/browse/HARMONY-1444
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
No, I used hand-made build from SVN.
BTW, sorry for confusion about 'broken data'. The pointer value
is
changed inside the method - this assignment should be removed.
On 9/12/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
Did you run this application for the recent binaries got from
the
SVN
sources?
As for me my results differ from Geir ones, namely, DRLVM
crashes
for both
Windows Linux as follows:
===
Windows
===
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo JAVA_HOME
JAVA_HOME
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo $CLASSPATH
c:/Tools/incubator-activemq-4.0/lib
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ which java
/cygdrive/c/DrlSrc/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/java
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ bin/activemq
cygpath: can't convert empty path
An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=00F3D648
ContextFlags=0001003f
Handler1=00401010
Handler2=11105D20
InaccessibleAddress=00F3D648
EDI=0013F9D4
ESI=0013F768
EAX=
EBX=000B
ECX=0001
EDX=000C
EIP=00F3D648
ESP=0013F764
EBP=0013F770
Module=
Module_base_address=00F3
Offset_in_DLL=d648
Linux
sh bin/activemq
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/exception/exceptions.cpp:143:
_jobject* create_exception(const char*): Assertion
`hythread_is_suspend_enabled()' failed.
abort_handler()
Aborted
Thanks,
Vladimir.
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
I'm observing the same problem - ActiveMQ can't start - on
DRLVM
+
Classlibrary build 442240 .
The problem I see first is that in
classlib
root\modules\luni\src\main\native\launcher\shared\main.c
in function 'static int invocation' after call
'createVMArgs'
variable
'mainClassJar' contains garbale while in the very end of
'static
int
createVMArgs' it contains valid string
'org.apache.harmony.kernel.vm.JarRunner' . If we comment out
'hymem_allocate_memory' in that function:
if (isStandaloneJar)
{
if (useDefaultJarRunner == 0)
{
//:::commented out mainClassJar =
Re: [jira] Resolved: (HARMONY-1386) Update to Pack200 decoding libraries
Yes, the HelloWorld.pack is different and needs to be replaced with the one in the bug report. Thanks, Alex. On 13/09/06, Mikhail Loenko (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-1386?page=all ] Mikhail Loenko resolved HARMONY-1386. - Resolution: Fixed Thanks for the patch! Ive applied it in revision 442918 the tests passed it's not clear what to do with HelloWorld.pack. should I replace that one in SVN? Update to Pack200 decoding libraries Key: HARMONY-1386 URL: http://issues.apache.org/jira/browse/HARMONY-1386 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Alex Blewitt Assigned To: Mikhail Loenko Priority: Minor Attachments: HelloWorld.pack, HelloWorld.pack, pack200.patch, pack200.patch I've updated the Pack200 decoding to take into account of the dynamic codec switching (although it currently throws an error if it's detected that such a dynamic switch is used) as well as adding more descriptive logging of what bands are being parsed, including remaining unimplemented bands. No output should be seen unless -Ddebug.pack200=true, but this is only for use whilst ensuring the unpacking is right. I'm not sure whether the patch contains the updated binary for HelloWorld.pack, so I'll attach that in addition to the patch. I've also fixed a couple of minor bugs in parsing the class and field bands. This patch passes all the tests with against the HEAD, but it wouldn't surprise me if the patch was missing some required file :-( -- 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: [result] Re: [vote] HARMONY-1363 - DRLVM fixes and additions
Anyone having problems building patch 1363 on Linux?
I can get 1363 to work on WinXP without problem. I first do:
svn update -r {2006-08-31}
Then a:
patch -p0 -i BBC.patch
The build is successful and build test is successful
When I roll back the Linux tree to {2006-08-31} the build fails with the
following:
build/targets/build.native.xml:150: gcc failed with return code 1
Note that the above is without adding in BBC.patch. Is there perhaps a
different revision date I should be using on Linux? Also, I am using GCC
3.4.1 20051202.
Thanks
Weldon
On 9/11/06, Magnusson, Geir [EMAIL PROTECTED] wrote:
Thanks - but don't commit it :) I'm working on that here on the
plane...
--
Geir Magnusson Jr
SSG/MPD
[EMAIL PROTECTED]
+1 203 665 6437
--
Weldon Washburn
Intel Middleware Products Division
Re: [result] Re: [vote] HARMONY-1363 - DRLVM fixes and additions
Where do I find regression tests for the recent drlvm patches? Right now, I am trying to drill down on Harmony-1417. I look in drlvm/trunk/vm/tests but don't see regression tests that look like they verify that lazy exception optimization works correctly. Maybe I overlooked something? -- Weldon Washburn Intel Middleware Products Division
Re: [result] Re: [vote] HARMONY-1363 - DRLVM fixes and additions
On Thursday 14 September 2006 00:12 Weldon Washburn wrote:
Anyone having problems building patch 1363 on Linux?
I can get 1363 to work on WinXP without problem. I first do:
svn update -r {2006-08-31}
Then a:
patch -p0 -i BBC.patch
The build is successful and build test is successful
When I roll back the Linux tree to {2006-08-31} the build fails with the
following:
build/targets/build.native.xml:150: gcc failed with return code 1
Note that the above is without adding in BBC.patch. Is there perhaps a
different revision date I should be using on Linux? Also, I am using GCC
3.4.1 20051202.
Do you have a compilation error like this?
[cc]
/home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/vm/port/include/port_atomic.h:
In function `uint64 port_atomic_cas64(volatile uint64*, uint64, uint64)':
[cc]
/home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/vm/port/include/port_atomic.h:168:
error: PIC register `%ebx' clobbered in `asm'
I see the same error when using gcc 3.4.6. I've created a JIRA 1459 with a
patch which should fixed this problem. While I don't know this code very much
this URL [1] has helped me to fix it. It looks like gcc starting with 3.4.x
has new rules for inline asm.
Since I don't know the exact compilation error that you have I can only guess.
Maybe this is not the problem you actually have. But this is definitely a
compilation problem for me.
[1] http://gcc.gnu.org/ml/gcc-help/2004-02/msg00077.html
--
Gregory Shimansky, 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] [jvmti] Question about JVMTI calling Java code
On Wednesday 13 September 2006 09:19 Alexey Varlamov wrote: The Thread.getContextClassLoader() just performs access restriction checks and return the corresponding field value. I think the only problematic function is ThreadGroup.enumerate() - unless security access control is applicable to JVMTI agent requests :). Actually this problematic function is used only in GetThreadGroupChildren for the information about threads and thread groups contained inside of this thread group. If this information is available from thread manager directly I would very much like to know how to get it. Looking at the current GetThreadGroupChildren implementation makes me very upset, it is clearly not meant for real usage. -- Gregory Shimansky, 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] [jvmti] Question about JVMTI calling Java code
On Wednesday 13 September 2006 16:14 Weldon Washburn wrote: Gregory, You might want to look closely at the code paths in the JVMTI functions. If the functions in question happen to be arbitrary Java code, then these code paths could lead to many other parts of the JVM which in turn might be written in Java. In the future the JIT runtime helpers or the GC may be written in Java. For example, an innocent looking object new, poll for GC or poll for preemption inside a JVMTI function could take the execution path deep inside of MMTk, or as mentioned below, deep inside java.util.concurrent . Rather than develop a general solution at this point, it may make sense to make all the data JVMTI needs to read/write accessible from C code. This is what I am trying to determine. Just how much of the data currently _cannot_ be taken from the native code. I am quite sure thread manager can provide a thread name or its priority. A more problematic data in my view may be something like Thread.getContextClassLoader(). Since it is not directly needed for threading model it isn't probably kept in any native structures. Getting it may be done through direct access to the field of j/l/Thread. It is a kernel class of course, but this will oblige a classlib implementation for Harmony to have the same field name. -- Gregory Shimansky, 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] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On Wednesday 13 September 2006 18:09 Andrew Zhang wrote: On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help community to prepare good fixes and will help committers to spend less time on applying other's patches. This all applies very well when test is ready and fix is simple. But when the bug requires running some application for 2 days in a row (e.g. race condition, memory leak or corruption, enumeration bug) and fix is not obvious (VM fixes are often like this) I hope such patches in JIRA won't be rejected according to these policies. -- Gregory Shimansky, 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] [jvmti] Question about JVMTI calling Java code
Weldon, It may be a little early to guard for architectural impact of large parts of the VM being written in Java? I don't think that we are quite there yet or need to consciously design to enable this till we have completed the MMTk integration and done exhaustive perf work. In addition to the more trivial thread related data being accessible from C, to support ThreadGroup.Enumerate() etc. functions do we want a lot of additional state in the thread manager for this? It may have been nice to be able to add some recursion detection/protection support to the JVMTI implementation, if not necessarily turning off events on all Java code. I think that some level of recursion protection in JVMTI or in JVMTI based agents is not uncommon. Thanks, Rana On 9/13/06, Weldon Washburn [EMAIL PROTECTED] wrote: You might want to look closely at the code paths in the JVMTI functions. If the functions in question happen to be arbitrary Java code, then these code paths could lead to many other parts of the JVM which in turn might be written in Java. In the future the JIT runtime helpers or the GC may be written in Java. For example, an innocent looking object new, poll for GC or poll for preemption inside a JVMTI function could take the execution path deep inside of MMTk, or as mentioned below, deep inside java.util.concurrent . Rather than develop a general solution at this point, it may make sense to make all the data JVMTI needs to read/write accessible from C code.
RE: [jira] Updated: (HARMONY-1453) [classlib][awt] Incorrect behavior of methods Graphics.draw3DRect and Graphics.fill3DRect
Done. -Original Message- From: Oleg Khaschansky [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 10:36 AM To: harmony-dev@incubator.apache.org Subject: [jira] Updated: (HARMONY-1453) [classlib][awt] Incorrect behavior of methods Graphics.draw3DRect and Graphics.fill3DRect Committers, Could someone be so kind and change the component for this issue to the classlib, please? Unfortunately, I forgot to set it when created the issue and unable to change. And, probably, apply the patch also :) thanks, -- Oleg - 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] java.net.URL(String, String, int, String) constructor exception thrown sequence (was re: [jira] Commented: (HARMONY-1158) [classlib][luni]Compatibility: java.net.URL new URL(ss,
Would any commiter like to confirm and close this non-bug differences from
RI jira? Thanks!
On 9/13/06, Andrew Zhang [EMAIL PROTECTED] wrote:
From: Andrew Zhang (JIRA) [EMAIL PROTECTED]
Date: Sep 13, 2006 11:02 AM
Subject: [jira] Commented: (HARMONY-1158) [classlib][luni]Compatibility:
java.net.URL new URL(ss, null, -3, null) throws MalformedURLException
while RI throws NPE
To: [EMAIL PROTECTED]
[
http://issues.apache.org/jira/browse/HARMONY-1158?page=comments#action_12434348]
Andrew Zhang commented on HARMONY-1158:
---
Ilya, I agree with you. Spec has explicitly pointed out No validation of
the inputs is performed by this constructor.
The tests show that the exception thrown sequence is uncertain and
implemention-dependent.
If no application and test cases are broken by currenty Harmony code, I
suggest not fix the problem.
Best regards,
Andrew
[classlib][luni]Compatibility: java.net.URL new URL(ss, null, -3,
null) throws MalformedURLException while RI throws NPE
--
Key: HARMONY-1158
URL: http://issues.apache.org/jira/browse/HARMONY-1158
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Ilya Okomin
Compatibility. Different order of exceptions.
RI throws unspecified NPE in java.net.URL(ss, null, -3, null)
constructor if host ==null while Harmony at first checks port and throws
MalformedURLException.
If host != null both RI and Harmony throw MalformedURLException.
=test.java=
import java.net.*;
public class test {
public static void main (String[] args) {
try {
new URL(ss, 0, -3, null);
} catch (Exception e) {
e.printStackTrace();
}
try {
new URL(ss, null, -3, null);
} catch (Exception e) {
e.printStackTrace();
}
}
}
===
Output on RI:
java.net.MalformedURLException : Invalid port number :-3
at java.net.URL.init(URL.java:373)
at java.net.URL.init(URL.java:283)
at test.main(test.java:7)
java.lang.NullPointerException
at java.net.Parts.init(URL.java:1259)
at java.net.URL.init(URL.java:380)
at java.net.URL.init(URL.java:283)
at test.main(test.java:13)
Output on Harmony:
java.net.MalformedURLException: Port out of range: -3
at java.net.URL.init(URL.java:393)
at java.net.URL.init(URL.java:367)
at test.main(test.java:7)
java.net.MalformedURLException: Port out of range: -3
at java.net.URL.init(URL.java:393)
at java.net.URL.init(URL.java:367)
--
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
--
Andrew Zhang
China Software Development Lab, IBM
--
Andrew Zhang
China Software Development Lab, IBM
[OLD JIRA]Deal with 780 866 1367 according to discussion
Hi All: Component attribute of JIRA 780 has been left as none, can any committer change it to [classlib]. The patch has already outdated and seems incorrect, I will provide a new patch. According to the 'Fighting Old JIRA Issues' guideline, I suggest to change component of JIRA 866 from 'Non-bug differences from RI' into 'classlib'. Since RI's behavior make sense here. An arbitrary object will not be found in a 0-length array, no matter it is comparable or not. The attached patch is already outdated, I will attach a new patch if no one objects. And of course, I will comment it on the JIRA. The patch acompany JIRA 1367 has not any test cases and already outdated, the patch should also be renewed. 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]
[General VM] GC strategy:how to garbage collect short-lived objects quickly.
Hi,all: As we all know, java objects are allocated on heap instead of stack, thus there is a problem about how to garbage collect short-lived objects quickly. In a recent real project I involved, a server built on java tries to send thousands of messages to client per second. A lot of short-lived messages is created as objects and discarded. (Although I can recycle these memory, there is still a byte array created during per call of nio read and write.) Since current GC strategy adopted by current RI starts to work only when the memory allocated approaching the limit of java heap, the work of GC is huge and will raise a wave on the server performance. Furthermore, after a long run, although I know GC will merge memory, the operating system reports there is memory fragment and in the worst case the OS will even report real memory is exhausted. Of course it is possible to limit the java heap so as to force gc frequently as a workround, is it preferrable to collect short-lived objects quickly such as adopt aged-related object queues as one of the gc strategy? What about the VMs here, drlvm or J9? Leo Li China Software Development Lab, IBM
