[classlib][luni]difference between RI and ICU
I encounter a problem when implement isWhiteSpace(int) in j.l.Character.
There is a difference between RI and ICU.
RI spec says,
It is a Unicode szpace character (SPACE_SEPARATOR, LINE_SEPARATOR, or
PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0',
'\u2007', '\u202F').
but ICU spec says,
It is a Unicode space separator (category Zs), but is not a no-break
space (\u00A0 or \u202F or \uFEFF).
RI excludes U+2007 however ICU excludes U+FEFF
And I looked up the definition of these 4 related characters on unicode.org:
00A0;NO-BREAK SPACE;Zs;0;CS;noBreak 0020N;NON-BREAKING SPACE
2007;FIGURE SPACE;Zs;0;WS;noBreak 0020N;
202F;NARROW NO-BREAK SPACE;Zs;0;CS;noBreak 0020N;
FEFF;ZERO WIDTH NO-BREAK SPACE;Cf;0;BN;N;BYTE ORDER MARK
I consider it is a bug of ICU because the U+FEFF is not in category *Zs* as
ICU spec described. And I purposed to report that to ICU team.
Should I handle the U+2007 by ourselves to follow RI or just document this
problem in testcase?
--
Tony Wu
China Software Development Lab, IBM
Re: [classlib][luni]difference between RI and ICU
Hello,
I will clarify this issue with ICU team. ;-)
Best regards,
Richard
Tony Wu wrote:
I encounter a problem when implement isWhiteSpace(int) in j.l.Character.
There is a difference between RI and ICU.
RI spec says,
It is a Unicode szpace character (SPACE_SEPARATOR, LINE_SEPARATOR, or
PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0',
'\u2007', '\u202F').
but ICU spec says,
It is a Unicode space separator (category Zs), but is not a no-break
space (\u00A0 or \u202F or \uFEFF).
RI excludes U+2007 however ICU excludes U+FEFF
And I looked up the definition of these 4 related characters on
unicode.org:
00A0;NO-BREAK SPACE;Zs;0;CS;noBreak 0020N;NON-BREAKING SPACE
2007;FIGURE SPACE;Zs;0;WS;noBreak 0020N;
202F;NARROW NO-BREAK SPACE;Zs;0;CS;noBreak 0020N;
FEFF;ZERO WIDTH NO-BREAK SPACE;Cf;0;BN;N;BYTE ORDER MARK
I consider it is a bug of ICU because the U+FEFF is not in category
*Zs* as
ICU spec described. And I purposed to report that to ICU team.
Should I handle the U+2007 by ourselves to follow RI or just document
this
problem in testcase?
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] putting kernel.jar in jre/bin/default
Alexey Varlamov wrote: 2006/9/11, Paulex Yang [EMAIL PROTECTED]: Alexey Varlamov wrote: 2006/9/11, Geir Magnusson Jr. [EMAIL PROTECTED]: Evgueni Brevnov wrote: On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: There seems to be no easy solution, other than parse LD_LIBRARY_PATH or PATH... Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside in one directory? I was thinking about this for packaging - that way you can have : jre/ bin/ j9/ drlvm/ and setup a symlink if you wish. if we have kernel.jar in jre/lib/boot as we do now, it's must less convenient and probably error prone to switch back and forth. If yes then we can take vmcore.dll base path as a location of kerenel.jar. Sure - where will you get that? and what do you w/ .so's in unix? I've come to the conclusion that the only way will be to manually run the PATH (win) and LD_LIBRARY_PATH (linux) IIUC, j9 does this in astonishingly simple way - it just specifies -Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar in the vmdir/harmonyvm.properties file, and the launcher does the rest. Namely, it automatically reads that file, replaces %LAUNCHER_HOME% with actual location and feeds extra arguments to VM among user's ones. This solution looks sufficient for now, but it seems to be only partial: it does not work for pure Invocation API usecase.Besides,those hardcoded arguments to VM appear confusing in some cases - e.g. it is impossible to override kernel.jar via command-line. Is it necessary to override the kernel.jar via command-line? The kernel class is provided by VM, so it is natural to locate it by VM specific property file. The first example which came to mind, how could you instrument the kernel classes, say for coverage analysis by emma or custom profiling? I'm sure there are more usecases, but anyway this is generally adopted behaviour and not following it may be far more disappointing than exception message incompatibility which we care so much ;) 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. 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? [1] http://viv.byethost15.com/exclude.list Also note hardcoded default vmdir. Agree, default should be replaced by some variables(%vmdir% or so), so it is easier to move VME to another directory. OK, I will file a JIRA for this. -- Regards, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni]difference between RI and ICU
Tony Wu 写道:
I encounter a problem when implement isWhiteSpace(int) in j.l.Character.
There is a difference between RI and ICU.
RI spec says,
It is a Unicode szpace character (SPACE_SEPARATOR, LINE_SEPARATOR, or
PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0',
'\u2007', '\u202F').
Anyway, spec is our first rule to follow.
but ICU spec says,
It is a Unicode space separator (category Zs), but is not a no-break
space (\u00A0 or \u202F or \uFEFF).
RI excludes U+2007 however ICU excludes U+FEFF
And I looked up the definition of these 4 related characters on
unicode.org:
00A0;NO-BREAK SPACE;Zs;0;CS;noBreak 0020N;NON-BREAKING SPACE
2007;FIGURE SPACE;Zs;0;WS;noBreak 0020N;
202F;NARROW NO-BREAK SPACE;Zs;0;CS;noBreak 0020N;
FEFF;ZERO WIDTH NO-BREAK SPACE;Cf;0;BN;N;BYTE ORDER MARK
So cool... :-)
I consider it is a bug of ICU because the U+FEFF is not in category
*Zs* as
ICU spec described. And I purposed to report that to ICU team.
Should I handle the U+2007 by ourselves to follow RI or just document
this
problem in testcase?
IMO, it's natural to follow RI, and the challenge is to fix it
gracefully with ICU implementation.
--
Robert Hu
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni]difference between RI and ICU
Robert Hu 写道:
Tony Wu 写道:
I encounter a problem when implement isWhiteSpace(int) in j.l.Character.
There is a difference between RI and ICU.
RI spec says,
It is a Unicode szpace character (SPACE_SEPARATOR, LINE_SEPARATOR, or
PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0',
'\u2007', '\u202F').
Anyway, spec is our first rule to follow.
Information from unicode.org is also spec. unicode.org is more official.
Since RI follows
unicode.org, we should also follow RI, in turn follows unicode.org
but ICU spec says,
It is a Unicode space separator (category Zs), but is not a no-break
space (\u00A0 or \u202F or \uFEFF).
RI excludes U+2007 however ICU excludes U+FEFF
And I looked up the definition of these 4 related characters on
unicode.org:
00A0;NO-BREAK SPACE;Zs;0;CS;noBreak 0020N;NON-BREAKING SPACE
2007;FIGURE SPACE;Zs;0;WS;noBreak 0020N;
202F;NARROW NO-BREAK SPACE;Zs;0;CS;noBreak 0020N;
FEFF;ZERO WIDTH NO-BREAK SPACE;Cf;0;BN;N;BYTE ORDER MARK
So cool... :-)
I consider it is a bug of ICU because the U+FEFF is not in category
*Zs* as
ICU spec described. And I purposed to report that to ICU team.
Should I handle the U+2007 by ourselves to follow RI or just document
this
problem in testcase?
IMO, it's natural to follow RI, and the challenge is to fix it
gracefully with ICU implementation.
--
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][luni]difference between RI and ICU
On 9/12/06, Tony Wu [EMAIL PROTECTED] wrote:
I encounter a problem when implement isWhiteSpace(int) in j.l.Character.
There is a difference between RI and ICU.
RI spec says,
It is a Unicode szpace character (SPACE_SEPARATOR, LINE_SEPARATOR, or
PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0',
'\u2007', '\u202F').
but ICU spec says,
It is a Unicode space separator (category Zs), but is not a no-break
space (\u00A0 or \u202F or \uFEFF).
RI excludes U+2007 however ICU excludes U+FEFF
And I looked up the definition of these 4 related characters on
unicode.org:
00A0;NO-BREAK SPACE;Zs;0;CS;noBreak 0020N;NON-BREAKING SPACE
2007;FIGURE SPACE;Zs;0;WS;noBreak 0020N;
202F;NARROW NO-BREAK SPACE;Zs;0;CS;noBreak 0020N;
FEFF;ZERO WIDTH NO-BREAK SPACE;Cf;0;BN;N;BYTE ORDER MARK
I consider it is a bug of ICU because the U+FEFF is not in category *Zs*
as
ICU spec described. And I purposed to report that to ICU team.
Should I handle the U+2007 by ourselves to follow RI or just document this
problem in testcase?
I think we could use workaround at first, add FIXME: before workaround,
and write corresponding test case.
When ICU team reponses (no matter accepts or rejects), we could make
decision then.
--
Tony Wu
China Software Development Lab, IBM
--
Andrew Zhang
China Software Development Lab, IBM
[build] anybody seeing MathTest failure?
I see this on both linux and windows. anybody else seeing it? Class org.apache.harmony.luni.tests.java.lang.MathTest test_hypot_DD Failure Should return NaN expected:NaN but was:NaN junit.framework.AssertionFailedError: Should return NaN expected:NaN but was:NaN at org.apache.harmony.luni.tests.java.lang.MathTest.test_hypot_DD(MathTest.java:277) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) 0.000 test_log1p_D Failure Should return NaN expected:NaN but was:NaN junit.framework.AssertionFailedError: Should return NaN expected:NaN but was:NaN at org.apache.harmony.luni.tests.java.lang.MathTest.test_log1p_D(MathTest.java:323) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) 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]
Re: [build] anybody seeing MathTest failure?
Mikhail Loenko 写道: I see this on both linux and windows. anybody else seeing it? Class org.apache.harmony.luni.tests.java.lang.MathTest test_hypot_DD Failure Should return NaN expected:NaN but was:NaN junit.framework.AssertionFailedError: Should return NaN expected:NaN but was:NaN at org.apache.harmony.luni.tests.java.lang.MathTest.test_hypot_DD(MathTest.java:277) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) 0.000 test_log1p_D Failure Should return NaN expected:NaN but was:NaN junit.framework.AssertionFailedError: Should return NaN expected:NaN but was:NaN at org.apache.harmony.luni.tests.java.lang.MathTest.test_log1p_D(MathTest.java:323) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) Yes, I have noticed that. It is caused by commit 442438. I suggest first mention the commitment on the mailing list and then provide a patch. The original code is: assertEquals(Should return NaN, Double.NaN, Math.hypot(Double.NaN, 2342301.89843)); After the commit, it becomes: assertEquals(Should return NaN, Double.NaN, Math.hypot(Double.NaN, 2342301.89843), 0D); 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] -- 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: [build] anybody seeing MathTest failure?
Seems caused by r442438, I have recovered part of the update to make the test pass at revision r442527, please verify. Mikhail Loenko wrote: I see this on both linux and windows. anybody else seeing it? Class org.apache.harmony.luni.tests.java.lang.MathTest test_hypot_DD Failure Should return NaN expected:NaN but was:NaN junit.framework.AssertionFailedError: Should return NaN expected:NaN but was:NaN at org.apache.harmony.luni.tests.java.lang.MathTest.test_hypot_DD(MathTest.java:277) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) 0.000 test_log1p_D Failure Should return NaN expected:NaN but was:NaN junit.framework.AssertionFailedError: Should return NaN expected:NaN but was:NaN at org.apache.harmony.luni.tests.java.lang.MathTest.test_log1p_D(MathTest.java:323) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) 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] -- 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: [build] anybody seeing MathTest failure?
it works! thanks, Paulex 2006/9/12, Paulex Yang [EMAIL PROTECTED]: Seems caused by r442438, I have recovered part of the update to make the test pass at revision r442527, please verify. Mikhail Loenko wrote: I see this on both linux and windows. anybody else seeing it? Class org.apache.harmony.luni.tests.java.lang.MathTest test_hypot_DD Failure Should return NaN expected:NaN but was:NaN junit.framework.AssertionFailedError: Should return NaN expected:NaN but was:NaN at org.apache.harmony.luni.tests.java.lang.MathTest.test_hypot_DD(MathTest.java:277) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) 0.000 test_log1p_D Failure Should return NaN expected:NaN but was:NaN junit.framework.AssertionFailedError: Should return NaN expected:NaN but was:NaN at org.apache.harmony.luni.tests.java.lang.MathTest.test_log1p_D(MathTest.java:323) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) 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] -- 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: [drlvm] Need help debugging
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
Geir Magnusson Jr. wrote:
I was testing the DRLVM-in-Launcher setup and something is seriously
broken.
On Ubuntu, both debug and release builds, it will run Tomcat ok, but
when I try something like Eclipse 3.2 or ActiveMQ 4.0.2 the program
runs and silently exits. No log output, no console output.
I've been trying to find a hint of what is making it unhappy, but so
far, no luck.
I've been staring at the output with -Xlog and -Xtrace, and there
doesn't seem to be any errors, but I don't know what to look for. (
I've captured the stream and placed it here :
http://people.apache.org/~geirm/activemq-logstream-20060909.txt
http://people.apache.org/~geirm/activemq-tracestream-20060909.txt
If anyone has any hints, I'd be mighty obliged...
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][internationalization]Are log messages and tools usage text to be internationalized?
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]
Re: [build] anybody seeing MathTest failure?
Mikhail Loenko wrote:
it works! thanks, Paulex
Welcome, thanks a lot for Spark's tips:).
However, I consider it as a JUnit's bug, because it's
assertEquals(String, double, double, double) method has special handling
code for INFINITE but not for NaN[1], but seems it is intended behavior
as the comment shows, hmm...
[1] snippet from junit.framework.Assert
static public void assertEquals(String message, double expected,
double actual, double delta) {
// handle infinity specially since subtracting to infinite
values gives NaN and the
// the following test fails
if (Double.isInfinite(expected)) {
if (!(expected == actual))
failNotEquals(message, new Double(expected), new
Double(actual));
} else if (!(Math.abs(expected-actual) = delta)) // Because
comparison with NaN always returns false(== Paulex: before this
line, seems should check the NaN at first)
failNotEquals(message, new Double(expected), new
Double(actual));
}
2006/9/12, Paulex Yang [EMAIL PROTECTED]:
Seems caused by r442438, I have recovered part of the update to make the
test pass at revision r442527, please verify.
--
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: [drlvm] Need help debugging
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
Geir Magnusson Jr. wrote:
I was testing the DRLVM-in-Launcher setup and something is seriously
broken.
On Ubuntu, both debug and release builds, it will run Tomcat ok, but
when I try something like Eclipse 3.2 or ActiveMQ 4.0.2 the program
runs and silently exits. No log output, no console output.
I've been trying to find a hint of what is making it unhappy, but so
far, no luck.
I've been staring at the output with -Xlog and -Xtrace, and there
doesn't seem to be any errors, but I don't know what to look for. (
I've captured the stream and placed it here :
http://people.apache.org/~geirm/activemq-logstream-20060909.txt
http://people.apache.org/~geirm/activemq-tracestream-20060909.txt
If anyone has any hints, I'd be mighty obliged...
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][TestNG] Use tweaked TestNG
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 - 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
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
Geir Magnusson Jr. wrote:
I was testing the DRLVM-in-Launcher setup and something is seriously
broken.
On Ubuntu, both debug and release builds, it will run Tomcat ok, but
when I try something like Eclipse 3.2 or ActiveMQ 4.0.2 the program
runs and silently exits. No log output, no console output.
I've been trying to find a hint of what is making it unhappy, but so
far, no luck.
I've been staring at the output with -Xlog and -Xtrace, and there
doesn't seem to be any errors, but I don't know what to look for. (
I've captured the stream and placed it here :
http://people.apache.org/~geirm/activemq-logstream-20060909.txt
http://people.apache.org/~geirm/activemq-tracestream-20060909.txt
If anyone has any hints, I'd be mighty obliged...
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To
Re: [classlib][corba] How are we doing?
On 9 September 2006 at 1:38, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: What's the status of the missing javax.rmi.CORBA classes? 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 Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][TestNG] Use tweaked TestNG
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 ... BTW, I'm still volunteering to convert beans. Regards, 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]
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]
RE: [classlib][corba] How are we doing?
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]
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]
RE: [classlib][corba] How are we doing?
Hi, I am having a build problem at the moment trying to connect to the maven repository 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. Cheers, Edell. -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]
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 - 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
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. 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. -- Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][corba] How are we doing?
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 - 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?
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 - 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: [jira] Updated: (HARMONY-1409) [classlib][beans] add missing get/setSource methods to PropertyEditorSupport
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 -- 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: [drlvm] Need help debugging
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
Geir Magnusson Jr. wrote:
I was testing the DRLVM-in-Launcher setup and something is seriously
broken.
On Ubuntu, both debug and release builds, it will run Tomcat ok, but
when I try something like Eclipse 3.2 or ActiveMQ 4.0.2 the program
runs and silently exits. No log output, no console output.
I've been trying to find a hint of what is making it unhappy, but so
far, no luck.
I've been staring at the output with -Xlog and -Xtrace, and there
doesn't seem to be any errors, but I don't know what to look for. (
I've captured the stream and placed it here :
http://people.apache.org/~geirm/activemq-logstream-20060909.txt
http://people.apache.org/~geirm/activemq-tracestream-20060909.txt
If anyone has any hints, I'd be mighty obliged...
geir
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HARMONY-1408) [classlib][beans] implementation of ProxyPersistenceDelegate
Ok, I'll fix it
2006/9/12, Alexei Zakharov (JIRA) [EMAIL PROTECTED]:
[
http://issues.apache.org/jira/browse/HARMONY-1408?page=comments#action_12434146
]
Alexei Zakharov commented on HARMONY-1408:
--
Mikhail, everything is correct. However, I think we may shorten the line
Statement:136 even greater:
} else if (methodName.equals(newInstance) //$NON-NLS-1$
- target instanceof Class target == Array.class) {
+target == Array.class) {
Class? componentType = (Class) arguments[0];
Thanks.
Alexei
[classlib][beans] implementation of ProxyPersistenceDelegate
Key: HARMONY-1408
URL: http://issues.apache.org/jira/browse/HARMONY-1408
Project: Harmony
Issue Type: Improvement
Components: Classlib
Environment: ws2003
Reporter: Alexei Zakharov
Assigned To: Mikhail Loenko
Attachments: CustomizedPDTest4.patch
The attached patch contains implementation of persistence delegate for all
dynamic proxy objects that can be created by means of the java.lang.reflect.Proxy
class methods. In the process of development of this persistence delegate a few
bugs in Statement and DefaultPersistenceDelegatesFactory were also fixed. After
applying this patch all tests from
org.apache.harmony.beans.tests.java.beans.CustomizedPersistenceDelegateTest will
be enabled so we can remove this class from the exclude list.
Thanks, Alexei
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][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 - 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]
RE: [classlib][corba] How are we doing?
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 - 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: [vm] ArgoUML application crashes IBM VME
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. 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, -- 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] Updated: (HARMONY-1409) [classlib][beans] add missing get/setSource methods to PropertyEditorSupport
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 -- 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] -- 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: Re: Re: [classlib][TestNG] groups of Harmony test
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 which were not resolved by initial code. But it provides less coverage than 'regression tests' + unit tests, of cause. On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote: If you've got fast and slow tests, then have a group for fast and slow tests. Then you can choose to just run the fast tests, and any automated build system can handle running the slow tests. IMHO, fast or slow may not be the key point. The question is whether we have any requirements to run only the regression tests. No, probably not the key point, but (a) groups don't have to be mutually exclusive (so you can decorate it with whatever groups you want) I agree. For example, os.win and os.linux are not mutually exclusive. Thanks a lot. and (b) it might be useful for an automated build system to run fast tests first, followed by slow (or non-fast) tests. That makes sense through we have not clear requirement currently. Mind you, I don't know what's going to happen with an automated test'n'build system; so it might not make sense to do it at this point. Really? ;-) We could also discuss whether it's feasible to move to TestNG. As you may know, there are already several threads about TestNG JUnit. Here I just review the open questions one by one so that we have sufficient preparation. [1]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [2]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [3]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] Best regards, Richard Alex.
Re: [classlib] [ldap] reuse of security parser
Hi Stephan, Ok I agree with your approach, we´ll make the changes on the parser and then upload a patch to the JIRA to open discussion. thanks, Daniel - Original Message - From: Stepan Mishura [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Sent: Monday, September 11, 2006 11:08 AM Subject: Re: [classlib] [ldap] reuse of security parser Hi Daniel, Yes, the parser used by 'security' code put some restrictions on distinguished names (see [1]) and IMO it is a good idea to try to improve the parser to make it possible to reuse it by 'jndi' module. When we developed security code we also thought about creating a common 'engine' for parsing distinguished names that can be extended by 'security' and 'ldap' code. But because of time limit we put off developing such 'engine' for a while. It is great to hear that you work on completing 'ldap' public API and I think that it is time to return this. As I understood you the current parser suits for 'ldap' code and can be used as common 'engine' for both modules (only minor updates are required, like changing visibility attributes). Then I think the best way is to submit a patch to JIRA and discuss it. And if we'll find out later that more updates are required then IMO we should think about redesigning the parser code. Thoughts? Ideas? Thanks, Stepan. [1] http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/x500/X500Principal.html On 9/9/06, Daniel Gandara wrote: Hi all, as you know at the ITC we are working to complete javax.naming.ldap package v 1.5. We are currently implementing the 1.5 classes and I have one question regarding the reuse of an already donated code from other package (org.apache.harmony.security.x509). The specific issue is as follow: in order to implement the classes LdapName and Rdn -from javax.naming.ldap- we need a Distinguished Name parser that parses according to the bnf syntax specified in RFC2253 and RFC1779. We've found a DNParser class in the package org.apache.harmony.security.x509 we could re-use, but it checks for valid AttributeTypes by looking in a table of valid OIDs. What we need is a less restrictive parser that allows types that do not have a valid OID. We could easily implement this behavior extending from this class and rewriting the specific functionality; but we would have to change some methods and attributes visibility of DNParser and AttributeTypeAndValue from private to protected. The specific question is: should we made this change on the security package and submit it with our contribution? or should we ask for this change to be made by the ones who wrote the security package? I'll wait for feedback, Thanks, Daniel -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][swing] set of passed swing tests
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]
Re: [jira] Updated: (HARMONY-1409) [classlib][beans] add missing get/setSource methods to PropertyEditorSupport
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]
Re: [classlib][swing] set of passed swing tests
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]
Re: [classlib][swing] set of passed swing tests
Sorry, my question was unclear - you can try to update the script to fork new VM for each test. -Stepan. On 9/12/06, Stepan Mishura [EMAIL PROTECTED] wrote: 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]
Re: [classlib][swing] set of passed swing tests
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]
Re: [drlvm] Need help debugging
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
Geir Magnusson Jr. wrote:
I was testing the DRLVM-in-Launcher setup and something is
seriously
broken.
On Ubuntu, both debug and release builds, it will run Tomcat
ok, but
when I try something like Eclipse 3.2 or ActiveMQ 4.0.2 the
program
runs and silently exits. No log output, no console output.
I've been trying to find a hint of what is making it unhappy,
but so
far, no luck.
I've been staring at the output with -Xlog and -Xtrace, and
there
doesn't seem to be any errors, but I don't know what to look
for. (
I've captured the stream and placed it here :
http://people.apache.org/~geirm/activemq-logstream-20060909.txt
http://people.apache.org/~geirm/activemq-tracestream-20060909.txt
If anyone has any hints, I'd be mighty obliged...
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][swing] set of passed swing tests
it's already that way: forkmode=perTest 2006/9/12, Stepan Mishura [EMAIL PROTECTED]: Sorry, my question was unclear - you can try to update the script to fork new VM for each test. -Stepan. On 9/12/06, Stepan Mishura [EMAIL PROTECTED] wrote: 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]
Re: [jira] Created: (HARMONY-1447) [classlib][awt] RI Polygon.add(int,int) throws exception after Polygon(new int[2], new int[2], 0)
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?
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]
RE: [classlib][corba] How are we doing?
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 - 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,
Re: [jira] Commented: (HARMONY-1439) [classlib][swing] javax.swing.JEditorPaneTest failed
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]
Re: [classlib][corba] How are we doing?
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 - 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?
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
RE: [classlib][corba] How are we doing?
Hi Alexey, Are you using maven? If so, it will just pull up the artifacts from the repository. The jar version number would change every time we deploy but you can choose to pick just the version you want. But if you use maven it will automatically pickup the latest version. - Balaji -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 11:35 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? 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:
Re: [classlib][corba] How are we doing?
No, we are using ant. 2006/9/12, Mosur Ravi, Balaji [EMAIL PROTECTED]: Hi Alexey, Are you using maven? If so, it will just pull up the artifacts from the repository. The jar version number would change every time we deploy but you can choose to pick just the version you want. But if you use maven it will automatically pickup the latest version. - Balaji -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 11:35 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][corba] How are we doing? 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 :
Re: [general] Marking JIRA issues before creation of patches.
On Wed, Sep 06, 2006 at 07:43:59PM +0400, Oleg Khaschansky wrote: 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. Its probably possible to create a group harmony-contributors or something like that and add those people to the potential assignees list. Whether its desireable, I don't know. 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? Personally, I like e-mail based workflow more than jira :) LSD - 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.
Does this apply to bug fixes as well? For significant fixes that have an architectural impact, certainly we need to inform the dev list, specially if there has been some discussion already. But for more local fixes, is it enough to add a comment to the issue on JIRA, stating current ownership, and then fix notes with the submission? At some point we will have many bugs, and will need to turn them around pretty fast. Thanks, Rana On 9/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: but again, I'll emphasize that you want to bring this to the dev list. Adding to a wiki or a JIRA is very silent compared to an introduction and discussion :)
[drlvm] [jvmti] Question about JVMTI calling Java code
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. -- 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]
Question on IntelliJ IDEA
Hello, I have a question on the usage of IntelliJ IDEA hope someone can help me with it. How i can make IntelliJ IDEA have preference over the packages in my project rather than the one in the Java JDK ? I am working on a class in a package in the Java sources. IDEA seems to be considering the packages inside the JDK and giving me wierd method not found errors. The package under consideration is the sun.rmi.transport.* package. Any help is appreciated. Thanks, - FaeLLe -- www.FaeLLe.com www.VikramMohan.com
Re: Question on IntelliJ IDEA
Problem solved thanks to the nice developers at IBM. Solution is, File, Settings, Modules, Order/Export Tab, Select Module Sources and click Move Up and click Ok. Now it reads the sun.rmi.transport.* package from my sources rather than the JDK. On 9/13/06, FaeLLe [EMAIL PROTECTED] wrote: Hello, I have a question on the usage of IntelliJ IDEA hope someone can help me with it. How i can make IntelliJ IDEA have preference over the packages in my project rather than the one in the Java JDK ? I am working on a class in a package in the Java sources. IDEA seems to be considering the packages inside the JDK and giving me wierd method not found errors. The package under consideration is the sun.rmi.transport.* package. Any help is appreciated. Thanks, - FaeLLe -- www.FaeLLe.com www.VikramMohan.com -- www.FaeLLe.com www.VikramMohan.com
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
It might be OK to disable the event notification on loopback for these thread/threadgroup java methods only? Would the misses of notification for such methods in CompiledMethodLoad be a major issue? Thanks, Rana
Re: Re: Re: [classlib][TestNG] groups of Harmony test
On 9/12/06, Stepan Mishura [EMAIL PROTECTED] wrote: 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? Yes. And we have found a way to avoid os.any ;-) 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? Yes. It really makes sense. We do not want to involve developers in unnecessary effort. 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 which were not resolved by initial code. But it provides less coverage than 'regression tests' + unit tests, of cause. On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote: If you've got fast and slow tests, then have a group for fast and slow tests. Then you can choose to just run the fast tests, and any automated build system can handle running the slow tests. IMHO, fast or slow may not be the key point. The question is whether we have any requirements to run only the regression tests. No, probably not the key point, but (a) groups don't have to be mutually exclusive (so you can decorate it with whatever groups you want) I agree. For example, os.win and os.linux are not mutually exclusive. Thanks a lot. and (b) it might be useful for an automated build system to run fast tests first, followed by slow (or non-fast) tests. That makes sense through we have not clear requirement currently. Mind you, I don't know what's going to happen with an automated test'n'build system; so it might not make sense to do it at this point. Really? ;-) We could also discuss whether it's feasible to move to TestNG. As you may know, there are already several threads about TestNG JUnit. Here I just review the open questions one by one so that we have sufficient preparation. [1]http://mail-
Re: [classlib][TestNG] Use tweaked TestNG
On 9/12/06, 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 :) I only redirect the concurrency support from java.util.concurrent to backport-util-concurrent which is used by TestNG for java14. It should not influence the UI. I will try the Eclipse plugin. ;-) 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 ... Temporarily, we will keep it in Harmony SVN. BTW, I'm still volunteering to convert beans. Great Thanks a lot. Regards, 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] -- 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]
[classlib]volunteer to supply patches for old JIRAs
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? -- Tony Wu China Software Development Lab, IBM
Re: [classlib]volunteer to supply patches for old JIRAs
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? 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. :-) Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]volunteer to supply patches for old JIRAs
On 9/13/06, Tony Wu [EMAIL PROTECTED] wrote: 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 :) Great! Is there anyone alse has interest and would like to work with me? Let me see whether I can contribute something. I'll take a look at those opened jiras which is related to nio/net/charset. -- Tony Wu China Software Development Lab, IBM -- Andrew Zhang China Software Development Lab, IBM
Re: [classlib]volunteer to supply patches for old JIRAs
Andrew Zhang 写道: On 9/13/06, Tony Wu [EMAIL PROTECTED] wrote: 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 :) Great! Is there anyone alse has interest and would like to work with me? Let me see whether I can contribute something. I'll take a look at those opened jiras which is related to nio/net/charset. -- Tony Wu China Software Development Lab, IBM Good! I want to contribute something too, and I think there are many volunteers. To avoid redundant work, I think one can simply add a comment to his/her interested JIRA to indicate that he/she is working on it. OK? :-) -- Robert Hu 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
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? 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. :-) I think we'd better choose JIRAs according to the modules, as you mentioned, which we're familiar with. 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] -- Andrew Zhang China Software Development Lab, IBM
Re: [classlib][security] problem processing SHA signatures in JBoss installer manifest
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
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
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
--
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: [classlib]volunteer to supply patches for old JIRAs
Andrew Zhang 写道: 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? 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. :-) I think we'd better choose JIRAs according to the modules, as you mentioned, which we're familiar with. OK, since so many people are interested in this proposal, the plan one start from the beginning and the other from the end may not be appropriate. Recently I am working on java.lang.Math and java.lang.StrictMath, I will deal with java.lang module. 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] -- 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: [build] anybody seeing MathTest failure?
For asserting NaN we should do something like this:
assertTrue(Double.isNaN((code to return NaN));
-Nathan
-Original Message-
From: Paulex Yang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 4:50 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] anybody seeing MathTest failure?
Mikhail Loenko wrote:
it works! thanks, Paulex
Welcome, thanks a lot for Spark's tips:).
However, I consider it as a JUnit's bug, because it's
assertEquals(String, double, double, double) method has special handling
code for INFINITE but not for NaN[1], but seems it is intended behavior
as the comment shows, hmm...
[1] snippet from junit.framework.Assert
static public void assertEquals(String message, double expected,
double actual, double delta) {
// handle infinity specially since subtracting to infinite
values gives NaN and the
// the following test fails
if (Double.isInfinite(expected)) {
if (!(expected == actual))
failNotEquals(message, new Double(expected), new
Double(actual));
} else if (!(Math.abs(expected-actual) = delta)) // Because
comparison with NaN always returns false(== Paulex: before this
line, seems should check the NaN at first)
failNotEquals(message, new Double(expected), new
Double(actual));
}
2006/9/12, Paulex Yang [EMAIL PROTECTED]:
Seems caused by r442438, I have recovered part of the update to make
the
test pass at revision r442527, please verify.
--
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
Hi, all: I am also ready to fix unresolved JIRAs. Currently, my work focuses on java.lang module. On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Andrew Zhang 写道: 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? 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. :-) I think we'd better choose JIRAs according to the modules, as you mentioned, which we're familiar with. OK, since so many people are interested in this proposal, the plan one start from the beginning and the other from the end may not be appropriate. Recently I am working on java.lang.Math and java.lang.StrictMath, I will deal with java.lang module. 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] -- 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] -- Leo Li China Software Development Lab, IBM
Re: [classlib]volunteer to supply patches for old JIRAs
Leo Li 写道: Hi, all: I am also ready to fix unresolved JIRAs. Currently, my work focuses on java.lang module. Hi Leo, I also work on java.lang module. May be you could list which JIRAs you are interested in, then we will not deal with the same JIRA at the same time. Best regards On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Andrew Zhang 写道: 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? 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. :-) I think we'd better choose JIRAs according to the modules, as you mentioned, which we're familiar with. OK, since so many people are interested in this proposal, the plan one start from the beginning and the other from the end may not be appropriate. Recently I am working on java.lang.Math and java.lang.StrictMath, I will deal with java.lang module. 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] -- 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] -- 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: [build] anybody seeing MathTest failure?
Nathan Beyer wrote:
For asserting NaN we should do something like this:
assertTrue(Double.isNaN((code to return NaN));
I agree, it's much clear and concise. But I think the assertEquals()
should be more defensive, for example, we may need to write test like this:
assertEquals(some code may return NaN, some_other_code may return NaN,
delta);
-Nathan
-Original Message-
From: Paulex Yang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 4:50 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] anybody seeing MathTest failure?
Mikhail Loenko wrote:
it works! thanks, Paulex
Welcome, thanks a lot for Spark's tips:).
However, I consider it as a JUnit's bug, because it's
assertEquals(String, double, double, double) method has special handling
code for INFINITE but not for NaN[1], but seems it is intended behavior
as the comment shows, hmm...
[1] snippet from junit.framework.Assert
static public void assertEquals(String message, double expected,
double actual, double delta) {
// handle infinity specially since subtracting to infinite
values gives NaN and the
// the following test fails
if (Double.isInfinite(expected)) {
if (!(expected == actual))
failNotEquals(message, new Double(expected), new
Double(actual));
} else if (!(Math.abs(expected-actual) = delta)) // Because
comparison with NaN always returns false(== Paulex: before this
line, seems should check the NaN at first)
failNotEquals(message, new Double(expected), new
Double(actual));
}
2006/9/12, Paulex Yang [EMAIL PROTECTED]:
Seems caused by r442438, I have recovered part of the update to make
the
test pass at revision r442527, please verify.
--
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]
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
RE: [build] anybody seeing MathTest failure?
-Original Message-
From: Paulex Yang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 10:11 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] anybody seeing MathTest failure?
Nathan Beyer wrote:
For asserting NaN we should do something like this:
assertTrue(Double.isNaN((code to return NaN));
I agree, it's much clear and concise. But I think the assertEquals()
should be more defensive, for example, we may need to write test like
this:
assertEquals(some code may return NaN, some_other_code may return NaN,
delta);
I'm not sure that I would agree with that; NaN is a special value that's
defined by its inequality with itself (d != d).
In any case, the JUnit methods have worked like this for years, so their
behavior couldn't change now.
-Nathan
-Original Message-
From: Paulex Yang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 4:50 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] anybody seeing MathTest failure?
Mikhail Loenko wrote:
it works! thanks, Paulex
Welcome, thanks a lot for Spark's tips:).
However, I consider it as a JUnit's bug, because it's
assertEquals(String, double, double, double) method has special
handling
code for INFINITE but not for NaN[1], but seems it is intended behavior
as the comment shows, hmm...
[1] snippet from junit.framework.Assert
static public void assertEquals(String message, double expected,
double actual, double delta) {
// handle infinity specially since subtracting to infinite
values gives NaN and the
// the following test fails
if (Double.isInfinite(expected)) {
if (!(expected == actual))
failNotEquals(message, new Double(expected), new
Double(actual));
} else if (!(Math.abs(expected-actual) = delta)) // Because
comparison with NaN always returns false(== Paulex: before this
line, seems should check the NaN at first)
failNotEquals(message, new Double(expected), new
Double(actual));
}
2006/9/12, Paulex Yang [EMAIL PROTECTED]:
Seems caused by r442438, I have recovered part of the update to make
the
test pass at revision r442527, please verify.
--
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [build] anybody seeing MathTest failure?
BTW - The original changes that I made were done because I did a mass fix of
all the inappropriate double and float test assertions. All of them were
using boxing, which meant that assertion was actually happening on
Double.equals(Object).
These were all rolled backed, but I'm going to check them back in and fix
the few NaN tests that I missed the first time to be as below.
-Nathan
-Original Message-
From: Nathan Beyer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 9:59 PM
To: harmony-dev@incubator.apache.org
Subject: RE: [build] anybody seeing MathTest failure?
For asserting NaN we should do something like this:
assertTrue(Double.isNaN((code to return NaN));
-Nathan
-Original Message-
From: Paulex Yang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 4:50 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] anybody seeing MathTest failure?
Mikhail Loenko wrote:
it works! thanks, Paulex
Welcome, thanks a lot for Spark's tips:).
However, I consider it as a JUnit's bug, because it's
assertEquals(String, double, double, double) method has special handling
code for INFINITE but not for NaN[1], but seems it is intended behavior
as the comment shows, hmm...
[1] snippet from junit.framework.Assert
static public void assertEquals(String message, double expected,
double actual, double delta) {
// handle infinity specially since subtracting to infinite
values gives NaN and the
// the following test fails
if (Double.isInfinite(expected)) {
if (!(expected == actual))
failNotEquals(message, new Double(expected), new
Double(actual));
} else if (!(Math.abs(expected-actual) = delta)) // Because
comparison with NaN always returns false(== Paulex: before this
line, seems should check the NaN at first)
failNotEquals(message, new Double(expected), new
Double(actual));
}
2006/9/12, Paulex Yang [EMAIL PROTECTED]:
Seems caused by r442438, I have recovered part of the update to make
the
test pass at revision r442527, please verify.
--
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]
-
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
No needs to use the jar option because drlvm analogously fails on Windows
for the following:
java -version
Thanks,
Vladimir.
On 9/12/06, Anton Luht [EMAIL PROTECTED] 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
Geir Magnusson Jr. wrote:
I was testing the DRLVM-in-Launcher setup and something is
seriously
broken.
On Ubuntu, both debug and release builds, it will run Tomcat
ok, but
when I try something like Eclipse 3.2 or ActiveMQ 4.0.2 the
program
runs and silently exits. No log output, no console output.
I've been trying to find a hint of what is making it unhappy,
but so
far, no luck.
I've been staring at the output with -Xlog and -Xtrace, and
there
doesn't seem to be any errors, but I don't know what to look
for. (
I've captured the stream and placed it here :
http://people.apache.org/~geirm/activemq-logstream-20060909.txt
http://people.apache.org/~geirm/activemq-tracestream-20060909.txt
If anyone has any hints, I'd be mighty obliged...
geir
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r442438 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang: MathTest.java StrictMathTest.java
[EMAIL PROTECTED] 写道:
Author: ndbeyer
Date: Mon Sep 11 20:49:06 2006
New Revision: 442438
URL: http://svn.apache.org/viewvc?view=revrev=442438
Log:
Adjust inappropriate JUnit assertions of double values for Math and StrictMath
tests.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/MathTest.java
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/StrictMathTest.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/MathTest.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/MathTest.java?view=diffrev=442438r1=442437r2=442438
==
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/MathTest.java
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/MathTest.java
Mon Sep 11 20:49:06 2006
@@ -116,34 +116,33 @@
/**
* @tests java.lang.Math#cbrt(double)
*/
-@SuppressWarnings(boxing)
public void test_cbrt_D() {
//Test for special situations
-assertEquals(Should return Double.NaN, Double.NaN, Math
-.cbrt(Double.NaN));
+assertTrue(Should return Double.NaN, Double.isNaN(Math
+.cbrt(Double.NaN)));
assertEquals(Should return Double.POSITIVE_INFINITY,
Double.POSITIVE_INFINITY, Math
-.cbrt(Double.POSITIVE_INFINITY));
+.cbrt(Double.POSITIVE_INFINITY), 0D);
assertEquals(Should return Double.NEGATIVE_INFINITY,
Double.NEGATIVE_INFINITY, Math
-.cbrt(Double.NEGATIVE_INFINITY));
-assertEquals(Should return 0.0, 0.0, Math.cbrt(0.0));
-assertEquals(Should return +0.0, +0.0, Math.cbrt(+0.0));
-assertEquals(Should return -0.0, -0.0, Math.cbrt(-0.0));
+.cbrt(Double.NEGATIVE_INFINITY), 0D);
+assertEquals(Should return 0.0, 0.0, Math.cbrt(0.0), 0D);
+assertEquals(Should return +0.0, +0.0, Math.cbrt(+0.0), 0D);
+assertEquals(Should return -0.0, -0.0, Math.cbrt(-0.0), 0D);
This assertion is not correct here. The spec of
java.lang.Math.cbrt(double) says:
'If the argument is zero, then the result is a zero with the same sign
as the argument.'
But, assert this way, the sign of the result will be omitted.
That is to say,
assertEquals(Should return -0.0, -0.0, Math.expm1(+0.0), 0D);
will also pass.
This occurs in many other places in the commit, I suggest to eliminate
all the inappropriate delta.
After looking into the source code JUnit:
static public void assertEquals(String message, double expected, double
actual, double delta) {
// handle infinity specially since subtracting to infinite
values gives NaN and the
// the following test fails
if (Double.isInfinite(expected)) {
if (!(expected == actual))
failNotEquals(message, new Double(expected), new
Double(actual));
} else if (!(Math.abs(expected-actual) = delta)) // Because
comparison with NaN always returns false (Spark comment: if condition
will make sign of zero meaningless)
failNotEquals(message, new Double(expected), new
Double(actual));
}
This may be a bug of JUnit. Since it does not differentiate +/-0.
-assertEquals(Should return 3.0, 3.0, Math.cbrt(27.0));
+assertEquals(Should return 3.0, 3.0, Math.cbrt(27.0), 0D);
assertEquals(Should return 23.111993172558684, 23.111993172558684,
-Math.cbrt(12345.6));
+Math.cbrt(12345.6), 0D);
assertEquals(Should return 5.643803094122362E102,
-5.643803094122362E102, Math.cbrt(Double.MAX_VALUE));
-assertEquals(Should return 0.01, 0.01, Math.cbrt(0.01));
+5.643803094122362E102, Math.cbrt(Double.MAX_VALUE), 0D);
+assertEquals(Should return 0.01, 0.01, Math.cbrt(0.01), 0D);
-assertEquals(Should return -3.0, -3.0, Math.cbrt(-27.0));
+assertEquals(Should return -3.0, -3.0, Math.cbrt(-27.0), 0D);
assertEquals(Should return -23.111993172558684, -23.111993172558684,
-Math.cbrt(-12345.6));
+Math.cbrt(-12345.6), 0D);
assertEquals(Should return 1.7031839360032603E-108,
-1.7031839360032603E-108, Math.cbrt(Double.MIN_VALUE));
-assertEquals(Should return -0.01, -0.01, Math.cbrt(-0.01));
+1.7031839360032603E-108, Math.cbrt(Double.MIN_VALUE), 0D);
+assertEquals(Should return -0.01, -0.01, Math.cbrt(-0.01), 0D);
try{
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
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? -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][security] problem processing SHA signatures in JBoss installer manifest
On 9/13/06, Richard Liang [EMAIL PROTECTED] 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] ;-)
Interesting!
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));
}
Interesting bug too!
I'm not clear about sha1 alogrithm, but guess whether following code causes
the bug:
for ( ; ( i = toByte ) ( byteIndex 4 ) ; i++ ) { // andrew comment :
The break condition is either 1. byteIndex == 4 or 2. i toByte
intArray[wordIndex] |= ( byteInput[i] 0xFF ) ((3 -
byteIndex)3) ;
byteIndex++;
}
if ( byteIndex == 4 ) { // andrew comment: break condition 1
wordIndex++;
if ( wordIndex == 16 ) { // intArray is full,
computing hash
computeHash(intArray);
wordIndex = 0;
}
}
if ( i = toByte ) { // all input bytes
appended
// andrew comment: is it break condition 2? or it should be (i toByte) ?
p.s: all tests could pass if using i toByte.
return ;
}
Of course, I could be totally wrong. Let security guys fix the problem. I
don't want to have panda eyes too as Richard. :-)
[1]http://www.panda.org.cn/zhuye/bbe.jpg
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
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
--
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]
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib][security] problem processing SHA signatures in JBoss installer manifest
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
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib]volunteer to supply patches for old JIRAs
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]
RE: svn commit: r442438 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang: MathTest.java StrictMathTest.java
-Original Message-
From: Spark Shen [mailto:[EMAIL PROTECTED]
+assertEquals(Should return -0.0, -0.0, Math.cbrt(-0.0), 0D);
This assertion is not correct here. The spec of
java.lang.Math.cbrt(double) says:
'If the argument is zero, then the result is a zero with the same sign
as the argument.'
But, assert this way, the sign of the result will be omitted.
That is to say,
assertEquals(Should return -0.0, -0.0, Math.expm1(+0.0), 0D);
will also pass.
This occurs in many other places in the commit, I suggest to eliminate
all the inappropriate delta.
The problem isn't the delta, the problem is that these tests were ALL using
boxing, which meant that assertion was based on Double.equals(Object). As
such, this makes the tests confusing and unclear, especially with all of the
assertions working this way. In this specific case, where you want to check
the sign, you want to use an assertion that's similar to how Double.equals
works - convert each double into bit representations and assert that all bit
values are the same. But in cases where you want to assert a specific double
value, say 3.0, you want to test the double, not the bit values.
My personal opinion is that in test cases around primitives, there should be
NO boxing/unboxing utilized. Make the tests explicit and clear. For example,
to completely test this case where -0.0 is returned, I would suggest the
following assertions:
double actual = Math.cbrt(-0.0);
// call assertEquals(long, long)
assertEquals(Double.doubleToLongBits(-0.0),Double.doubleToLongBits(actual));
Compare that to this (which only compiles with Java 5).
// call assertEquals(Object, Object)
assertEquals(-0.0, Math.cbrt(-0.0));
Isn't the former more obvious and straightforward?
After looking into the source code JUnit:
static public void assertEquals(String message, double expected, double
actual, double delta) {
// handle infinity specially since subtracting to infinite
values gives NaN and the
// the following test fails
if (Double.isInfinite(expected)) {
if (!(expected == actual))
failNotEquals(message, new Double(expected), new
Double(actual));
} else if (!(Math.abs(expected-actual) = delta)) // Because
comparison with NaN always returns false (Spark comment: if condition
will make sign of zero meaningless)
failNotEquals(message, new Double(expected), new
Double(actual));
}
This may be a bug of JUnit. Since it does not differentiate +/-0.
If this is a bug, it's too late now. JUnit has been this way for years.
-Nathan
-
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 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. -- 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]volunteer to supply patches for old JIRAs
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] -- Tony Wu China Software Development Lab, IBM
Re: [classlib]volunteer to supply patches for old JIRAs
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. IIRC, there is a discussion related to patch available status, if it is opened, it would be easier to express support:). 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] -- 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: [build] anybody seeing MathTest failure?
Nathan Beyer wrote:
-Original Message-
From: Paulex Yang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 10:11 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] anybody seeing MathTest failure?
Nathan Beyer wrote:
For asserting NaN we should do something like this:
assertTrue(Double.isNaN((code to return NaN));
I agree, it's much clear and concise. But I think the assertEquals()
should be more defensive, for example, we may need to write test like
this:
assertEquals(some code may return NaN, some_other_code may return NaN,
delta);
I'm not sure that I would agree with that; NaN is a special value that's
defined by its inequality with itself (d != d).
In any case, the JUnit methods have worked like this for years, so their
behavior couldn't change now.
Of course not:).
-Nathan
-Original Message-
From: Paulex Yang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 4:50 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] anybody seeing MathTest failure?
Mikhail Loenko wrote:
it works! thanks, Paulex
Welcome, thanks a lot for Spark's tips:).
However, I consider it as a JUnit's bug, because it's
assertEquals(String, double, double, double) method has special
handling
code for INFINITE but not for NaN[1], but seems it is intended behavior
as the comment shows, hmm...
[1] snippet from junit.framework.Assert
static public void assertEquals(String message, double expected,
double actual, double delta) {
// handle infinity specially since subtracting to infinite
values gives NaN and the
// the following test fails
if (Double.isInfinite(expected)) {
if (!(expected == actual))
failNotEquals(message, new Double(expected), new
Double(actual));
} else if (!(Math.abs(expected-actual) = delta)) // Because
comparison with NaN always returns false(== Paulex: before this
line, seems should check the NaN at first)
failNotEquals(message, new Double(expected), new
Double(actual));
}
2006/9/12, Paulex Yang [EMAIL PROTECTED]:
Seems caused by r442438, I have recovered part of the update to make
the
test pass at revision r442527, please verify.
--
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]
-
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][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, nul
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
Re: [classlib]volunteer to supply patches for old JIRAs
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. Wonderful plan :) IIRC, there's a open JIRA of management, it is because Harmony java.lang.management does not exist yet, please ignore. And please ignore HARMONY-1375, it is in discussion still. Waiting for your summary :) 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] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]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. 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. It's a good idea. I have already see many JIRAs linked -- 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
I'll take part in this too. As far as I remember not all of my fixes has patches for test... Seems it is a good time to fix this :) SY, Alexey 2006/9/13, Tony Wu [EMAIL PROTECTED]: 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] -- Tony Wu China Software Development Lab, IBM -- Alexey A. Petrenko Intel Middleware Products Division
Re: [general] Marking JIRA issues before creation of patches.
Rana Dasgupta wrote: Does this apply to bug fixes as well? For significant fixes that have an architectural impact, certainly we need to inform the dev list, specially if there has been some discussion already. But for more local fixes, is it enough to add a comment to the issue on JIRA, stating current ownership, and then fix notes with the submission? I think so. At some point we will have many bugs, and will need to turn them around pretty fast. Yes - not every bug needs to be discussed. But if there are bigger things, the more communication the better. geir Thanks, Rana On 9/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: but again, I'll emphasize that you want to bring this to the dev list. Adding to a wiki or a JIRA is very silent compared to an introduction and discussion :) - 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? :) 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]
Re: [classlib][corba] How are we doing?
+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
RE: [classlib]volunteer to supply patches for old JIRAs
-Original Message- From: Jimmy, Jing Lv [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 12:07 AM IIRC, there's a open JIRA of management, it is because Harmony java.lang.management does not exist yet, please ignore. There is a lang-management module that contains all of the java.lang.management APIs. Many are still stubs, but some of the more simple classes are complete. And please ignore HARMONY-1375, it is in discussion still. Waiting for your summary :) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r442438 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang: MathTest.java StrictMathTest.java
Nathan Beyer 写道:
-Original Message-
From: Spark Shen [mailto:[EMAIL PROTECTED]
+assertEquals(Should return -0.0, -0.0, Math.cbrt(-0.0), 0D);
This assertion is not correct here. The spec of
java.lang.Math.cbrt(double) says:
'If the argument is zero, then the result is a zero with the same sign
as the argument.'
But, assert this way, the sign of the result will be omitted.
That is to say,
assertEquals(Should return -0.0, -0.0, Math.expm1(+0.0), 0D);
will also pass.
This occurs in many other places in the commit, I suggest to eliminate
all the inappropriate delta.
The problem isn't the delta, the problem is that these tests were ALL using
boxing, which meant that assertion was based on Double.equals(Object). As
such, this makes the tests confusing and unclear, especially with all of the
assertions working this way. In this specific case, where you want to check
the sign, you want to use an assertion that's similar to how Double.equals
works - convert each double into bit representations and assert that all bit
values are the same. But in cases where you want to assert a specific double
value, say 3.0, you want to test the double, not the bit values.
My personal opinion is that in test cases around primitives, there should be
NO boxing/unboxing utilized. Make the tests explicit and clear. For example,
to completely test this case where -0.0 is returned, I would suggest the
following assertions:
double actual = Math.cbrt(-0.0);
// call assertEquals(long, long)
assertEquals(Double.doubleToLongBits(-0.0),Double.doubleToLongBits(actual));
Hi Nathan:
Agree. And I will refactor the test case and provide a patch soon.
Compare that to this (which only compiles with Java 5).
// call assertEquals(Object, Object)
assertEquals(-0.0, Math.cbrt(-0.0));
Isn't the former more obvious and straightforward?
After looking into the source code JUnit:
static public void assertEquals(String message, double expected, double
actual, double delta) {
// handle infinity specially since subtracting to infinite
values gives NaN and the
// the following test fails
if (Double.isInfinite(expected)) {
if (!(expected == actual))
failNotEquals(message, new Double(expected), new
Double(actual));
} else if (!(Math.abs(expected-actual) = delta)) // Because
comparison with NaN always returns false (Spark comment: if condition
will make sign of zero meaningless)
failNotEquals(message, new Double(expected), new
Double(actual));
}
This may be a bug of JUnit. Since it does not differentiate +/-0.
If this is a bug, it's too late now. JUnit has been this way for years.
-Nathan
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Spark Shen
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]volunteer to supply patches for old JIRAs
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]
Re: [classlib]volunteer to supply patches for old JIRAs
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]
Re: [classlib]volunteer to supply patches for old JIRAs
btw - nice plan all! Good to see this happen :) geir Geir Magnusson Jr. 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]volunteer to supply patches for old JIRAs
Right! 2006/9/13, Geir Magnusson Jr. [EMAIL PROTECTED]: Yes :) A guideline :) Alexey Petrenko wrote: Probably we should add this as policy to Harmony site. SY, Alexey 2006/9/13, Nathan Beyer [EMAIL PROTECTED]: 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] -- Alexey A. Petrenko Intel Middleware Products Division
Re: [drlvm] putting kernel.jar in jre/bin/default
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? -- Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Need help debugging
I was able to sucessfully run both applications (Eclipse ActiveMQ) for the
recent build.
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
Geir Magnusson Jr. wrote:
I was testing the DRLVM-in-Launcher setup and something is
seriously
broken.
On Ubuntu, both debug and release builds, it will run Tomcat
ok, but
when I try something like Eclipse 3.2 or ActiveMQ 4.0.2 the
program
runs and silently exits. No log output, no console output.
I've been trying to find a hint of what is making it unhappy,
but so
far, no luck.
I've been staring at the output with -Xlog and -Xtrace, and
there
doesn't seem to be any errors, but I don't know what to look
for. (
I've captured the stream and placed it here :
http://people.apache.org/~geirm/activemq-logstream-20060909.txt
http://people.apache.org/~geirm/activemq-tracestream-20060909.txt
If anyone has any hints, I'd be mighty obliged...
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL
Re: [classlib][security] problem processing SHA signatures in JBoss installer manifest
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] ;-)
Nice work!
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
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
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][security] problem processing SHA signatures in JBoss installer manifest
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
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Need help debugging
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
Geir Magnusson Jr. wrote:
I was testing the DRLVM-in-Launcher setup and something is
seriously
broken.
On Ubuntu, both debug and release builds, it will run Tomcat
ok, but
when I try something like Eclipse 3.2 or ActiveMQ 4.0.2 the
program
runs and silently exits. No log output, no console output.
I've been trying to find a hint of what is making it unhappy,
but so
far, no luck.
I've been staring at the output with -Xlog and -Xtrace, and
there
doesn't seem to be any errors, but I don't know what to look
for. (
I've captured the stream and placed it here :
http://people.apache.org/~geirm/activemq-logstream-20060909.txt
http://people.apache.org/~geirm/activemq-tracestream-20060909.txt
If anyone has any hints, I'd be mighty obliged...
geir
-
Terms of use :
