Re: [classlib] debug compilation as default
On the 0x1A1 day of Apache Harmony Mark Hindess wrote: On 8 July 2006 at 1:35, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 21:29, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. I do think we should agree on something, to make federation easier. geir Linux version of the makefiles update is already in http://issues.apache.org/jira/browse/HARMONY-803 The DEFINES and INCLUDES is exactly the kind of thing I was thinking about. However: 1) I think we've somehow lost the default '-O1' option Yes. I'll fix it. 2) I think the $(shell uname -m) is overkill, we'll handle this a better way when the time comes in the meantime forking/execing sh and uname for each call to make is just overhead. I know that fork/exec operation is quite efficient on linux, more over the compilation of sources uses much more time. But it always returns the same result, for any valid architecture that we can build on, so why not just leave it out for now? As a general rule, we add complexity when we need it not before we need it without any discussion/justification. I didn't touch ant build system. It allows to pass environment to makefiles. That's enough. Makefiles will do the rest. Sorry, but I don't like this for reasons I discussed yesterday. It was late and I guess I wasn't clear enough. It should be done via ant because ant is the interface that developers should be using to execute the build - either using the top-level ant file or the module ant file (or via some federation calling ant). Even if they are only building native code in a module developers should still use the ant file. Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) (I don't think it helps clarify the issue, but for the record, I'm a C programmer and Perl hacker. I don't particularly like make or ant. I like using the right tool for the job.) For the more record, I am a C programmer too :) And not scared of 'ant' :) Except one thing: let's do the *parallel build feature*. It is a real pleasure to use it with 'make'! Harmony Classlib is primarily a Java project that includes a little C code[1]. The build is kicked off with ant so ant is the primary *interface* for developers, are you suggesting we change the top-level interface to make? It still uses make for the C underneath so as not to scare off C developers when they work at that level but they are always encouraged to kick off the build via ant for consistency. If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. No. As you say C programmers prefer tools like make (and configure) so we decided a while ago to stick to tools that matched expectations (for the implementation but not the interface). I'm not arguing that we should use *ant* for the *implementation* of the C code building just that ant is the *interface*. We may change[0] the way native code is built if handle things like this configuration issue via ant then the interface for developers can remain the same even when we change what happens under the covers. Regards, Mark. [0] Probably sooner rather than later if we start ports to other platforms. Regards, Mark [1] Arguably as little as we can get away with because we believe that in the long term the JIT will do better than a compiler when it comes to optimisation. Mark, do you mean that the JIT should be better than what it is? :) -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strategy for Harmony to work with Visual Studio 2005?
I think that creating such wrappers and implementing non standard MS
extensions for another platforms is not a good idea. What will we do
if this extension will not be accepted? Rewrite everything again?
I agree that such extension is probably good. But we should wait until
community will accept them and widely used compilers will implement
them.
SY, Alexey
2006/7/7, Xiao-Feng Li [EMAIL PROTECTED]:
I would suggest another approach.
Since the safe CRT APIs are mostly similar to the original counterpart
but enforcing safety checks and validations, we can take them as
coding conventions, so as to achieve both the safety and portability.
For example, with strcpy, we do this way:
step 1. write a safe version strcpy_s on platforms that have no safe
CRT support, see below.
step 2. replace all strcpy(dst, src) invocations with strcpy_s(dst, count, src);
This version of strcpy_s is only for illustration purpose and follow
the standard safety checkings.
#define MAX_STR_LEN (130)
#ifndef SAFE_CRT
int strcpy_s(dst, count, src)
{
if( dst != null count 0 count = MAX_STR_LEN )
dst[0] = '\0';
if( dst == NULL || src == NULL ) return -1;
if( count == 0 || count MAX_STR_LEN ) return -1;
if( count = strlen(src) ) return -1; //strlen should use safer version
if( mem_overlap (dst, src) ) return -1;
strcpy(dst, src);
return 0;
}
#endif
Thanks,
xiaofeng
On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Thursday 06 July 2006 14:35 Xiao-Feng Li wrote:
Ok, then I will get back to VC7 at the moment. :-) Let's wait till
its acceptance by the community.
Actually I don't see them as new APIs; instead, I view them as
enforced good coding conventions that help to achieve better security,
e.g., always check the buffer size in debug mode. (Personally I like
the changes immediately when I met them. My only question was why we
didn't do that earlier. :-)
If they were just drop in replacements of the old functions this could be done
quickly. But they are not compatible for the most part and so may complicate
the code significantly to support both old (e.g. VC7 and older, cyginw/mingw
targets) and new version.
You can use includes from Platform SDK which has headers compatible with old
API [1] unless MS has changed new versions of Platform SDK to have this
secure stuff and no alternative since I wrote that email.
On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I think the key reason is that this is non-standard stuff from
microsoft's for-fee toolchain, and people in OSS try to avoid having a
dependency on that.
I wouldn't mind supporting this at some point a) once it becomes a
standard and b) has broad acceptance, but I'm guessing that's going to
take years.
People who have used the free version of MSFT tools seem to just set the
flag as you note.
There are two flags. I've found the second in [2]. But I didn't try to use the
because I used Platform SDK includes workaround. Maybe defining them is still
not enough.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/208da7a50606011434i405b7d5ao4be8a9fefc52e183%40mail.gmail.com
[2]
http://www.wxwidgets.org/wiki/index.php/MSVC_.NET_Setup_Guide#Version_Specific_Comments_.26_Instructions
--
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]
-
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: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
Nathan Beyer wrote: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] That is the default name, but you can change it with a command line option -vm: and put it in a directory specified by -vmdir:, e.g. java -vmdir:drlvm -vm:foo Does this work for DRLVM now? No, which is why I said This is something I think we should do sooner rather than later :) I tried this method two weeks ago and couldn't get it to work. Is there anyway to configure the VM by an INI file or something? I'd prefer to use the DRLVM, but until I can just drop the binaries in place like the IBM VME it just seems like a pain. Yep. We should get this done sooner rather than later :) geir -Nathan look in jre/bin/drlvm for a library called foo.[so|dll] that exports the JNI_CreateJavaVM etc. The idea is that you can have multiple VMs in deploy and choose which you use at runtime. Regards, Tim - 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][math]compatibility: different values for BigDecimal(null, mc).toBigInteger() for Harmony and RI
The reference implementation doesn't make sense in this example, and it
is highly unlikely that any application will be dependent upon this
behavior, so I propose that we do not apply this patch.
If anyone objects to this decision I will happily reopen it.
Regards,
Tim
Vladimir Ivanov (JIRA) wrote:
[classlib][math]compatibility: different values for BigDecimal(null,
mc).toBigInteger() for Harmony and RI
--
Key: HARMONY-786
URL: http://issues.apache.org/jira/browse/HARMONY-786
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
The Harmony method java.math.BigDecimal(BigInteger, mc).toBigInteger()
returns 'null' while RI returns -9223372036854775808.
=== test.java =
import java.math.*;
public class test {
public static void main(String args[] ) {
System.out.println( + new BigDecimal((BigInteger) null,
MathContext.UNLIMITED).toBigInteger()) ;
}
}
===
Output:
C:\tmp\tmp17C:\jdk1.5.0_06\bin\java.exe -showversion test
java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
-9223372036854775808
C:\tmp\tmp17C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -showversion test
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32, R25.0.0-75,
GC: System optimized over throughput (initial strategy singleparpar))
null
C:\tmp\tmp17C:\harmony\trunk_0427\deploy\jdk\jre\bin\java.exe -showversion
test
java version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as
applicable.
null
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
Sorry. :( Sometimes these discussions get so deep my brain can't parse all of the characters. -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Nathan Beyer wrote: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] That is the default name, but you can change it with a command line option -vm: and put it in a directory specified by -vmdir:, e.g. java -vmdir:drlvm -vm:foo Does this work for DRLVM now? No, which is why I said This is something I think we should do sooner rather than later :) I tried this method two weeks ago and couldn't get it to work. Is there anyway to configure the VM by an INI file or something? I'd prefer to use the DRLVM, but until I can just drop the binaries in place like the IBM VME it just seems like a pain. Yep. We should get this done sooner rather than later :) geir -Nathan look in jre/bin/drlvm for a library called foo.[so|dll] that exports the JNI_CreateJavaVM etc. The idea is that you can have multiple VMs in deploy and choose which you use at runtime. Regards, Tim - 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][math]compatibility: different values for BigDecimal(null, mc).toBigInteger() for Harmony and RI
Yes.
For the record, the point of that category is not only for JIRAs that
have been entered noting deviation and we make decisions on, but also a
place to record any deviation from either spec or RI (yes, it needs to
be renamed...)
geir
Nathan Beyer wrote:
I don't disagree with the resolution, but I would suggest moving this to the
non-bug differences with RI component?
-Nathan
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 09, 2006 3:29 PM
To: harmony-dev@incubator.apache.org
Subject: [classlib][math]compatibility: different values for
BigDecimal(null, mc).toBigInteger() for Harmony and RI
The reference implementation doesn't make sense in this example, and it
is highly unlikely that any application will be dependent upon this
behavior, so I propose that we do not apply this patch.
If anyone objects to this decision I will happily reopen it.
Regards,
Tim
Vladimir Ivanov (JIRA) wrote:
[classlib][math]compatibility: different values for BigDecimal(null,
mc).toBigInteger() for Harmony and RI
--
Key: HARMONY-786
URL: http://issues.apache.org/jira/browse/HARMONY-786
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
The Harmony method java.math.BigDecimal(BigInteger, mc).toBigInteger()
returns 'null' while RI returns -9223372036854775808.
=== test.java =
import java.math.*;
public class test {
public static void main(String args[] ) {
System.out.println( + new BigDecimal((BigInteger) null,
MathContext.UNLIMITED).toBigInteger()) ;
}
}
===
Output:
C:\tmp\tmp17C:\jdk1.5.0_06\bin\java.exe -showversion test
java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
-9223372036854775808
C:\tmp\tmp17C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -showversion
test
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32,
R25.0.0-75, GC: System optimized over throughput (initial strategy
singleparpar))
null
C:\tmp\tmp17C:\harmony\trunk_0427\deploy\jdk\jre\bin\java.exe -
showversion test
java version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its
licensors, as applicable.
null
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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-kernel][testing] Where to put VM-agnostic tests for kernel classes?
:) Nathan Beyer wrote: Sorry. :( Sometimes these discussions get so deep my brain can't parse all of the characters. -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Nathan Beyer wrote: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] That is the default name, but you can change it with a command line option -vm: and put it in a directory specified by -vmdir:, e.g. java -vmdir:drlvm -vm:foo Does this work for DRLVM now? No, which is why I said This is something I think we should do sooner rather than later :) I tried this method two weeks ago and couldn't get it to work. Is there anyway to configure the VM by an INI file or something? I'd prefer to use the DRLVM, but until I can just drop the binaries in place like the IBM VME it just seems like a pain. Yep. We should get this done sooner rather than later :) geir -Nathan look in jre/bin/drlvm for a library called foo.[so|dll] that exports the JNI_CreateJavaVM etc. The idea is that you can have multiple VMs in deploy and choose which you use at runtime. Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][math]compatibility: different values for BigDecimal(null, mc).toBigInteger() for Harmony and RI
Tim Ellison wrote:
The reference implementation doesn't make sense in this example, and it
is highly unlikely that any application will be dependent upon this
behavior, so I propose that we do not apply this patch.
+1
(I pondered suggesting returning BigDecimal.valueOf(0), but that's not
right either... Hard to imagine why the behavior of BigDecimal(null) is
unspecified...)
geir
If anyone objects to this decision I will happily reopen it.
Regards,
Tim
Vladimir Ivanov (JIRA) wrote:
[classlib][math]compatibility: different values for BigDecimal(null,
mc).toBigInteger() for Harmony and RI
--
Key: HARMONY-786
URL: http://issues.apache.org/jira/browse/HARMONY-786
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
The Harmony method java.math.BigDecimal(BigInteger, mc).toBigInteger()
returns 'null' while RI returns -9223372036854775808.
=== test.java =
import java.math.*;
public class test {
public static void main(String args[] ) {
System.out.println( + new BigDecimal((BigInteger) null,
MathContext.UNLIMITED).toBigInteger()) ;
}
}
===
Output:
C:\tmp\tmp17C:\jdk1.5.0_06\bin\java.exe -showversion test
java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
-9223372036854775808
C:\tmp\tmp17C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -showversion test
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32, R25.0.0-75,
GC: System optimized over throughput (initial strategy singleparpar))
null
C:\tmp\tmp17C:\harmony\trunk_0427\deploy\jdk\jre\bin\java.exe -showversion
test
java version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as
applicable.
null
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
let me subscribe this mailig list
thx - 雅虎免费邮箱-3.5G容量，20M附件
Re: portlib functionality
Marina Goldburt wrote: Tim, Paulex, Will look at the file locking later...And I'm sure there are other things worthing evaluation to be portlib extension. And what is the way to extend the portlib functionality? If we add all the missing functions to the HyPortLibrary structure, the structure will grow awfully. And, as I understand, every change in the structure leads to vm recompilation. I can prepare a patch that moves platform-dependent file I/O operations from luni/luni to luni/port submodule. Is it will be useful? Marina A great idea! :) But as I know, some of the methods are a bit complex and require well-design on api, e.g., selectImpl() in luni, which was written into one method in Harmony native code, but IMHO if removes into portlib, it must be separated into two or three methods, and should be design carefully. So I suggest more discussion on this. :) -- 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: Strategy for Harmony to work with Visual Studio 2005?
My idea is NOT to write wrappers for Microsoft extentions. First, they
are to enhance our own C code safety with more checkings; second, they
are not MS extensions. The only thing is, they are enlighted by and
have similar APIs as MS's safe CRT.
Thanks,
xiaofeng
On 7/9/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
I think that creating such wrappers and implementing non standard MS
extensions for another platforms is not a good idea. What will we do
if this extension will not be accepted? Rewrite everything again?
I agree that such extension is probably good. But we should wait until
community will accept them and widely used compilers will implement
them.
SY, Alexey
2006/7/7, Xiao-Feng Li [EMAIL PROTECTED]:
I would suggest another approach.
Since the safe CRT APIs are mostly similar to the original counterpart
but enforcing safety checks and validations, we can take them as
coding conventions, so as to achieve both the safety and portability.
For example, with strcpy, we do this way:
step 1. write a safe version strcpy_s on platforms that have no safe
CRT support, see below.
step 2. replace all strcpy(dst, src) invocations with strcpy_s(dst, count,
src);
This version of strcpy_s is only for illustration purpose and follow
the standard safety checkings.
#define MAX_STR_LEN (130)
#ifndef SAFE_CRT
int strcpy_s(dst, count, src)
{
if( dst != null count 0 count = MAX_STR_LEN )
dst[0] = '\0';
if( dst == NULL || src == NULL ) return -1;
if( count == 0 || count MAX_STR_LEN ) return -1;
if( count = strlen(src) ) return -1; //strlen should use safer version
if( mem_overlap (dst, src) ) return -1;
strcpy(dst, src);
return 0;
}
#endif
Thanks,
xiaofeng
On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Thursday 06 July 2006 14:35 Xiao-Feng Li wrote:
Ok, then I will get back to VC7 at the moment. :-) Let's wait till
its acceptance by the community.
Actually I don't see them as new APIs; instead, I view them as
enforced good coding conventions that help to achieve better security,
e.g., always check the buffer size in debug mode. (Personally I like
the changes immediately when I met them. My only question was why we
didn't do that earlier. :-)
If they were just drop in replacements of the old functions this could be
done
quickly. But they are not compatible for the most part and so may complicate
the code significantly to support both old (e.g. VC7 and older, cyginw/mingw
targets) and new version.
You can use includes from Platform SDK which has headers compatible with old
API [1] unless MS has changed new versions of Platform SDK to have this
secure stuff and no alternative since I wrote that email.
On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I think the key reason is that this is non-standard stuff from
microsoft's for-fee toolchain, and people in OSS try to avoid having a
dependency on that.
I wouldn't mind supporting this at some point a) once it becomes a
standard and b) has broad acceptance, but I'm guessing that's going to
take years.
People who have used the free version of MSFT tools seem to just set the
flag as you note.
There are two flags. I've found the second in [2]. But I didn't try to use
the
because I used Platform SDK includes workaround. Maybe defining them is
still
not enough.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/208da7a50606011434i405b7d5ao4be8a9fefc52e183%40mail.gmail.com
[2]
http://www.wxwidgets.org/wiki/index.php/MSVC_.NET_Setup_Guide#Version_Specific_Comments_.26_Instructions
--
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]
-
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] Testing conventions - a proposal
Richard Liang wrote:
Paulex Yang wrote:
Richard Liang wrote:
Hello All,
After read through the document recommended by Alex, I think TestNG
can really meet our requirement. It provides much flexibility for
test configuration. ;-)
If we decide to transfer to TestNG, we shall:
1. Identify Harmony testing strategy. (It's not easy)
2. Define TestNG suite/groups to reflect Harmony testing strategy
3. Decide to use Java 5 Annotations or Java 1.4 JavaDoc annotations
Any difference between using 1.4 doclet or 5.0 annotation? If we use
Java 1.4 so far, can we migrate to annotation easily?
Both 1.4 doclet and 5.0 annotation can provide same support for
testing configuration. The retention policy of TestNG's 5.0 annotation
is RUNTIME, that's the TestNG tests should be compiled into 5.0
classes [1]. I don't think it's easy to migrate from doclet to
annotation, at least, TestNG does not this support. Correct me if I'm
wrong. ;-)
1. http://testng.org/doc/documentation-main.html#jdk-14
4. Convert all JUnit tests to TestNG tests (TestNG provides a tool
org.testng.JUnitConverter for migrating from JUnit, but it seems
that the tool has a bug :-P )
I'm sorry, but...what the bug looks like? I think it is important
because we have so many JUnit tests already, it will be a big concern
of the TestNG solution if we have not tool to migrate.
I can show an example :-)
For a junit tests:
import junit.framework.TestCase;
public class SampleTest extends TestCase{
public void testMethod1() {
assertTrue(true);
}
}
We suppose the corresponding TestNG test is:
import org.testng.annotations.Test;
import static org.testng.AssertJUnit.*;
public class SampleTest{
@Test
public void testMethod1() {
assertTrue(true);
}
}
But the tool will only add TestNG annotation to junit test methods:
import org.testng.annotations.*;
import junit.framework.TestCase;
public class SampleTest extends TestCase{
@Test
public void testMethod1() {
assertTrue(true);
}
}
Sorry Paulex, It sounds not a bug if we decide to use TestNG while still
keeping the flexibility to use JUnit. Any comments? Thanks a lot.
Richard
TestNG Eclipse plugin also provide a way to convert junit test to
TestNG test[2], unfortunately, it also has bugs. :-( It should be
static import all the assert methods of org.testng.AssertJUnit, but
the converter only uses common import.
2. http://testng.org/doc/eclipse.html
5. Choose a module to run a pilot
...
Please correct me if I'm wrong. Thanks a lot.
Best regards,
Richard.
George Harley wrote:
Alex Blewitt wrote:
On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote:
It seems that you're very familiar with TestNG. ;-) So would you
please
identify what we shall do to transfer from junit to TestNG?
Thanks a lot.
Me? I'm just highly opinionated :-)
Hi Alex,
I think we are all pretty much in the TestNG novice category :-)
There's guidelines for migrating from JUnit to TestNG at the home
page:
http://testng.org/doc/migrating.html
Here is a sample use that will convert all the JUnit tests in the
src/ directory to TestNG:
java org.testng.JUnitConverter -overwrite -annotation -srcdir src
:-)
I have done some private experimentation with this command line
utility and it seems to work well. In the first instance it would
be good to preserve the JUnit nature of the tests - i.e. still
have the test classes extend from JUnit TestCase etc - so that
there is always a backwards migration path. That's me being
paranoid. Note that the equivalent migration functionality in the
latest TestNG plug-in for Eclipse did not allow that but, in
addition to adding in the annotations, insisted on removing the
inheritance from TestCase.
There's also instructions about how to set it up with an Ant-based
build:
http://testng.org/doc/ant.html
I'll see if I can migrate the tests I've got in the Pack200 dir to
use
TestNG, so that you can see what it looks like. Unfortunately, I
doubt
that I'm going to be able to get to that much before 2 weeks time due
to other outstanding commitments ...
Alex.
Although we haven't gotten round to discussing specifics yet, it is
probably timely to mention here that using the TestNG annotations
approach (as opposed to the pre-1.5 Javadoc comments approach) will
not work so long as we are compiling Harmony code with the jsr14
target. It looked like the annotation metadata did not make it into
the generated class files (at least this is what I saw in my own
experiments). If we want to use the annotations approach we will
have to wait until we move up to compiling for a 1.5 target.
Hopefully that will not be too long now..
In the meantime you could try out using the Javadoc comments
approach, just to get a feel for how things run. The downside to
that is that your test source needs to be available at runtime so
that the comments are available for the framework to examine.
Best regards,
George
Re: [classlib] Exception throwing compatibility: java.util.Scanner
Geir Magnusson Jr wrote: Richard Liang wrote: Geir Magnusson Jr wrote: Richard Liang wrote: For this case, I decide to follow useRadix(int radix). Please correct me if I'm wrong. Thanks a lot. Do you mean that you're going to follow the spec? If so, we should note that we're making a conscious decision to differ from the RI. Yes, Geir. For this case I think we have to differ from RI. I agree. I just had no clue what your post meant. And we'll document? :) Thanks a lot, Geir. I will raise a Non-bug differences from RI issue on Harmony JIRA. Richard 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
