Re: [Testing Convention] Keep tests small and fast
On 3/30/06, Richard Liang wrote:
>
> Dears,
>
> I notice that we put all the test code into one big test method (for
> example,
>
> org.apache.harmony.tests.java.util.jar.test_putLjava_lang_ObjectLjava_lang_Object
> ).
> This way we will lose some benefits of junit and even unit test:
> 1. Test code cannot share configuration code through setUp and tearDown
> 2. We have to add redundant code, such as, "Assert 1:", "Assert 2: "
> to make the test results more comprehensive
> 3. It makes the test code more complex
>
> Shall we just use small test cases?
>
> You may want to read the description at:
> http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit_p.html
>
> *Keep tests small and fast*
> Executing every test for the entire system shouldn't take hours. Indeed,
> developers will more consistently run tests that execute quickly.
> Without regularly running the full set of tests, it will be difficult to
> validate the entire system when changes are made. Errors will start to
> creep back in, and the benefits of unit testing will be lost. This means
> stress tests and load tests for single classes or small frameworks of
> classes shouldn't be run as part of the unit test suite; they should be
> executed separately.
Hi Richard,
IMHO, this relates to "stress tests and load tests" only. This means that we
shouldn't put such kind of tests in a 'regular test suite'. The 'regular
test suite' is used to verify regressions only. Returning back to a test's
size, I think it is up to developer - we can only recommend not to test all
functionality in one test case and split independent parts into a number of
test case. But IMHO we can not fully avoid creating 'redundant code', such
as, "Assert 1:", "Assert 2: ". For example, if there is a constructor
with several parameters and get-methods to return provided parameters then I
wouldn't create 3 tests instead of the next one:
public void test_Ctor() {
Ctor c = new Ctor(param1, param2, param3);
assertEquals("Assert 1", param1, c.getParam1());
assertEquals("Assert 2", param2, c.getParam3());
assertEquals("Assert 3", param3, c.getParam2());
}
Thanks,
Stepan.
Thanks a lot.
>
> Richard Liang wrote:
> > Dears,
> >
> > As I cannot find similar pages about testing convention, I just create
> > one with my rough ideas
> > http://wiki.apache.org/harmony/Testing_Convention, so that we can
> > document our decision timely & clearly.
> >
> > Geir Magnusson Jr wrote:
> >>
> >>
> >> Leo Simons wrote:
> >>> Gentlemen!
> >>>
> >>> On Mon, Mar 27, 2006 at 11:07:51AM +0200, mr A wrote:
> On Monday 27 March 2006 10:14, mr B wrote:
> > On 3/27/06, mr C wrote:
> > [SNIP]
> >> [SNIP]
> >>> [SNIP]
> On 1/1/2006, mr D wrote:
> >>> [SNIP]
> > Hmmm... Lemme support [SNIP]
> Now let me support [SNIP].
> >>>
> >>> The ASF front page says
> >>>
> >>> (...) "The Apache projects are characterized by a collaborative,
> >>> consensus
> >>> based development process, " (...)
> >>>
> >>> That's not just some boilerplate. Consensus is a useful thing.
> >>>
> >>> "How should we organize our tests?" has now been the subject of
> >>> debate for
> >>> *months* around here, and every now and then much of the same
> >>> discussion is
> >>> rehashed.
> >>
> >> And we're making progress. IMO, it really helped my thinking to
> >> distinguish formally between the implementation tests and the spec
> >> tests, because that *completely* helped me come to terms with the
> >> whole o.a.h.test.* issue.
> >>
> >> I now clearly see where o.a.h.test.*.HashMapTest fits, and where
> >> java.util.HashMapTest fits.
> >>
> >> I don't think our issues were that obvious before, at least to me.
> >> Now, I see clearly.
> >>
> >>>
> >>> I think it would be more productive to look for things to agree on
> >>> (such as,
> >>> "we don't know, but we can find out", or "we have different ideas on
> >>> that,
> >>> but there's room for both", or "this way of doing things is not the
> >>> best one
> >>> but the stuff is still useful so let's thank the guy for his work
> >>> anyway")
> >>> than to keep delving deeper and deeper into these kinds of
> >>> disagreements.
> >>>
> >>> Of course, the ASF front page doesn't say that "apache projects are
> >>> characterized by a *productive* development process". Its just my
> >>> feeling that
> >>> for a system as big as harmony we need to be *very* productive.
> >>
> >> You don't think we're making progress through these discussions?
> >>
> >>>
> >>> Think about it. Is your time better spent convincing lots of other
> >>> people to do
> >>> their testing differently, or is it better spent writing better tests?
> >>
> >> The issue isn't about convincing someone to do it differently, but
> >> understanding the full scope of problems, that we need to embrace
> >> both approaches, because they are apples and oranges, and we need
> >> both apples and oranges. They aren't exclusionary.
> >>
> >> geir
> >
Re: [Fwd: [announce-crypto] Bouncy Castle Crypto Provider Package version 1.32 now available]
I've run security tests with new version and all tests pass. So I'm OK with it. Thanks, Stepan. On 3/29/06, Tim Ellison wrote: > > Should we move up to this new version? > > Regards, > Tim > > Original Message > Subject: [announce-crypto] Bouncy Castle Crypto Provider Package version > 1.32 now available > Date: Wed, 29 Mar 2006 12:56:18 +1100 > From: Jon Eaves <[EMAIL PROTECTED]> > To: dev-crypto <[EMAIL PROTECTED]>, > [EMAIL PROTECTED], [EMAIL PROTECTED], KVM > Interest <[EMAIL PROTECTED]> > > Hi all, > > The latest relase of BC is now ready after a couple of false starts in > the beta process. > Thanks always to our tireless reporters of issues, one day maybe all > vendors will create > certificates in the same way. > > New features in this release include support for elliptic curves over > F2m, suport for > ECDSA with CMS and S/MIME, and support for a wider range of PSS > signature types in CRL and > certificate verification. In addition further work has been done on > improving path > validation compliance with RFC 3280, OpenPGP text signatures now work > correctly in > environments with '\r' as a line separator, a typo in the header for > OpenPGP clear text > SHA256 signatures has been fixed, several encoding compatability issue > with the streaming > CMS and S/MIME APIs have been fixed and it should now be possible to > stop the S/MIME > parsers from leaving temporary files around in all operating system > environments. > > As usual, the latest releases can be found at : > > http://www.bouncycastle.org/ > > And for those who like living on the bleeding edge, the betas can be > downloaded from: > > http://www.bouncycastle.org/betas/ > > Please note, make sure that beta feedback is sent to the > [EMAIL PROTECTED] > address, and not the general mailing list (dev-crypto) > > -- > Jon Eaves <[EMAIL PROTECTED]> > http://www.eaves.org/blog/ > Co-Author of "Apache Tomcat Bible", "Professional Tomcat 5", "Beginning > JavaServer Pages" > > > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > -- Thanks, Stepan Mishura Intel Middleware Products Division
[Testing Convention] Keep tests small and fast
Dears, I notice that we put all the test code into one big test method (for example, org.apache.harmony.tests.java.util.jar.test_putLjava_lang_ObjectLjava_lang_Object). This way we will lose some benefits of junit and even unit test: 1. Test code cannot share configuration code through setUp and tearDown 2. We have to add redundant code, such as, "Assert 1:", "Assert 2: " to make the test results more comprehensive 3. It makes the test code more complex Shall we just use small test cases? You may want to read the description at: http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit_p.html *Keep tests small and fast* Executing every test for the entire system shouldn't take hours. Indeed, developers will more consistently run tests that execute quickly. Without regularly running the full set of tests, it will be difficult to validate the entire system when changes are made. Errors will start to creep back in, and the benefits of unit testing will be lost. This means stress tests and load tests for single classes or small frameworks of classes shouldn't be run as part of the unit test suite; they should be executed separately. Thanks a lot. Richard Liang wrote: Dears, As I cannot find similar pages about testing convention, I just create one with my rough ideas http://wiki.apache.org/harmony/Testing_Convention, so that we can document our decision timely & clearly. Geir Magnusson Jr wrote: Leo Simons wrote: Gentlemen! On Mon, Mar 27, 2006 at 11:07:51AM +0200, mr A wrote: On Monday 27 March 2006 10:14, mr B wrote: On 3/27/06, mr C wrote: [SNIP] [SNIP] [SNIP] On 1/1/2006, mr D wrote: [SNIP] Hmmm... Lemme support [SNIP] Now let me support [SNIP]. The ASF front page says (...) "The Apache projects are characterized by a collaborative, consensus based development process, " (...) That's not just some boilerplate. Consensus is a useful thing. "How should we organize our tests?" has now been the subject of debate for *months* around here, and every now and then much of the same discussion is rehashed. And we're making progress. IMO, it really helped my thinking to distinguish formally between the implementation tests and the spec tests, because that *completely* helped me come to terms with the whole o.a.h.test.* issue. I now clearly see where o.a.h.test.*.HashMapTest fits, and where java.util.HashMapTest fits. I don't think our issues were that obvious before, at least to me. Now, I see clearly. I think it would be more productive to look for things to agree on (such as, "we don't know, but we can find out", or "we have different ideas on that, but there's room for both", or "this way of doing things is not the best one but the stuff is still useful so let's thank the guy for his work anyway") than to keep delving deeper and deeper into these kinds of disagreements. Of course, the ASF front page doesn't say that "apache projects are characterized by a *productive* development process". Its just my feeling that for a system as big as harmony we need to be *very* productive. You don't think we're making progress through these discussions? Think about it. Is your time better spent convincing lots of other people to do their testing differently, or is it better spent writing better tests? The issue isn't about convincing someone to do it differently, but understanding the full scope of problems, that we need to embrace both approaches, because they are apples and oranges, and we need both apples and oranges. They aren't exclusionary. geir -- Richard Liang China Software Development Lab, IBM
bug-to-bug compatiblity case: Proxy handling
Hi,
About the Internet proxy properties, the Java 5 document says '*' can be
used as wild card character for matching, as below
"http.nonProxyHosts indicates the hosts which should be connected too
directly and not through the proxy server. The value can be a list of
hosts, each seperated by a |, and in addition a wild card character (*)
can be used for matching. For example:
-Dhttp.nonProxyHosts="*.foo.com|localhost". "
But RI's behavior looks strange. The wildcard character works only if
it's the first or last character in "host" String. Test case below shows
the details. Shall we make Harmony be compatible with RI?
public void testNonProxyHosts() throws URISyntaxException {
ProxySelector selector = ProxySelector.getDefault();
List proxyList;
Proxy proxy;
// set http proxy
System.setProperty("http.proxyHost", "192.168.0.1");
// RI works as expected if '*' is the last character
System.setProperty("http.nonProxyHosts", "10.10.*");
proxyList = selector.select(new URI("http://10.10.1.2";));
proxy = (Proxy) proxyList.get(0);
assertEquals(Proxy.NO_PROXY, proxy);
// If '*' is neither the first character nor the last character, '*'
// RI consider '*' as a common character instead of wild card
System.setProperty("http.nonProxyHosts", "10.10.*.2");
proxyList = selector.select(new URI("http://10.10.*.2";));
proxy = (Proxy) proxyList.get(0);
assertEquals(Proxy.NO_PROXY, proxy);
// the test below confirms that the '*' is not considered as
wild card
System.setProperty("http.nonProxyHosts", "10.10.*.2");
proxyList = selector.select(new URI("http://10.10.1.2";));
proxy = (Proxy) proxyList.get(0);
assertEquals(Proxy.Type.HTTP, proxy.type());
assertEquals("192.168.0.1:80", proxy.address().toString());
}
--
Paulex Yang
China Software Development Lab
IBM
Re: [classlib] ant platform property definitions
Dan,
Thanks for the helpful comments.
On 3/30/06, bootjvm <[EMAIL PROTECTED]> wrote:
>
> Concerning the ideas for platform names, I think lower case names
> like 'linux' and 'windows' and 'solaris' and 'aix' is by far the simplest
> method. It avoids UPPER case errors with the shift key for these
> _very_ common key sequences, reducing "Inaccurate kEy SEquences"
> quite a bit. I have seen this work well for both platform names
> and for project names (such as "newproj1" instead of "NewProj1")
> with favorable long-term response from those who type the key
> sequences most.
Very good point. You are absolutely correct. Sticking with Ant case
may reduce complexity in the ant files but it makes things more
confusing/complex for users. This would be a bad idea. The case
mapping can be managed in a single ant file, for classlib anyway,
which should make it manageable.
> Bottom line:Mixed case just adds one more level of complexity
> to the whole situation. Other comments below
>
> Dan Lydick
>
>
> > [Original Message]
> > From: Mark Hindess <[EMAIL PROTECTED]>
> > To: Harmony Dev
> > Date: 3/29/06 10:28:41 AM
> > Subject: [classlib] ant platform property definitions
> >
> > Currently a number of the classlib ant files "normalize" operating
> > system and architecture names. Unfortunately they don't
> > really normalize them in the same way. ;-)
> >
> > For instance, native-src/build.xml sets target.platform to
> > "linux.IA32" and modules/security/make/build.xml sets "platform.name"
> > to "lnx".
> >
>
> PLEASE, no abbreviations! Nobody abbreviates the same way, and
> even one individual may use more than one abbreviation for a word!
Agreed.
> > I think we should decide on a common normalized form and have a single
> > common ant file to import that defines them. I'd already started to
> > create one (as I was about to add platform defines in yet another ant
> > file) but then I realised there wasn't any consensus about what the
> > normalized form should be.
> >
> > I think having a mapping (from os.arch to hy.arch and os.name and
> > hy.os) is useful because it reduces the coupling between Harmony and
> > ant, and because it enables use to perform sensible normalizations.
> > But, I don't think we should make the mapping unnecessarily
> > complicated. I think we should keep the normal form as close as
> > possible to the standard ant defines of os.name and os.arch.
> >
> > So, ${hy.os} would be ${os.name} - with values like 'Linux',
> > 'Solaris', etc. - except for Windows where we would normalize to
> > "Windows". Similarly, ${hy.arch} would be ${os.arch} - with values
> > like 'x86', 'x86_64', 'ia64', etc. I see no clear reasons for
> > exceptions to the ${hy.arch} at the moment, but we should create it
> > and use it consistently.
> >
> > This would lead to "hy.platform" being defined as:
> >
> > Linux.x86
> > Windows.x86
> >
> > We could add exceptions - for instance, to make 'Linux' lower case -
> > but then we'd only need to add exceptions later for 'Solaris', 'Aix',
> > etc. I think we'd be better to avoid this and only have exceptions
> > where:
> >
> > * the name contains characters that can't be used in file names, or
> > * there is a clear reason to normalize - e.g. "Windows XP", etc.
> >
> > So, what do people think? Is there a compelling reason to maintain
> > the differences we have today - e.g. Linux in lowercase, 'ipf' rather
> > than 'ia64' - or can we just stick with the ant defines?
> >
>
> I would like to have us all start thinking in this early stage about
> abbreviations across the _whole_ of the Harmony component
> roster. In particular, I would like to get my BootJVM code
> using the same tokens as elsewhere. Right now, I am using,
>
> OS names:
> linux
> cygwin
> windows
> solaris
>
> CPU names:
> intel
> sparc
> ppc
Do you distinguish between ia64 and x86_64?
> Word widths:
> 64
> 32
Yes. We might as well create ${hy.bits} and ${is.64bit} and
${is.32bit} definitions in the same file while doing this
consolidation.
Thanks again for the constructive comments. Much appreciated.
Regards,
-Mark.
> These are put together in different combinations in the
> configuration-- ALL LOWER CASE ;-) -- and show
> up in the file names for deliverables, etc., in this way.
> For code defines, they are all in upper case per C coding
> conventions.
>
> When using mixed case in other situations (namely, version
> control tags and branches), I have seen consistent confusion
> with users, so I have always specified only one case for use
> in some tokens. (For example, upper in tags, lower in
> branches.)
>
> >
> > We also have many definitions of properties like "is.win",
> > "is.windows", and "if.win". I'd prefer to stick to forms starting
> > with 'is.' since I think they read better when used, e.g.
> >
> >
> > ...
> >
> >
> > and the item following the 'is.' prefix should be the all lowercase
> > (in line with
Re: SableVM and Harmony Class library
Enrico Personally I think only step 1 and 2 is enough to make SableVM run Harmony classlib, then the sample launcher in SVN should can launch the SableVM. The step 3 is "better have" so that the VM can be more easily ported to other platform by leveraging the portlib's interface. Enrico Migliore wrote: Hi, The main document on porting is at: http://tinyurl.com/jfljq The VM Interface is described at: http://tinyurl.com/gtd64 and the required kernel classes are described at: http://tinyurl.com/hawkl Regards, Mark. Hi all, I'm reading the documentation above and, at first glance, it seems to me that interfacing the SableVM to the Harmony Class Library is a task that involves the following steps: step 1 -- The SableVM /has to/ implement the VM interface, in order for the Harmony Class Library to "find" the entry points of a certain number of native functions. The entry points are documented here: http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__VMInterface.html step 2 -- The SableVM has to implement a Java interface, which means that is /has to/ implement in C a small set of Java classes, documented in the following link: http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html#KernelJavaClasses step 3 -- The SableVM, in terms of native functions, /should/ call only the native functions of the port layer, used by the Harmony Class Library: http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html#CreatePortLib Comments are welcome :-) Enrico -- Paulex Yang China Software Development Lab IBM
RE: [jira] Created: (HARMONY-239) [classlib][luni] Java 5 enhancements for java.lang.Float
There was a problem in the simple caching I put in the class for the valueOf method. It wasn't discerning between - and + 0.0. I've removed the caching piece altogether and attached a new diff. Caching of Float and Double instances probably isn't necessary anyway, but it can always be added later. This same problem will afflict my post for the Double class enhancements. Let me know if you want me to post another diff for that as well. -Nathan -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 29, 2006 5:25 AM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Created: (HARMONY-239) [classlib][luni] Java 5 enhancements for java.lang.Float Nathan, I have failing tests after applying this patch, notably in LUNI tests AssertionFailedError: Floattest0 at tests.api.java.lang.FloatTest.test_valueOfLjava_lang_String(FloatTest.java:5 79) and MATH tests BigDecimalConvertTest#testFloatValuePlusZero() Please take a look if you have time, otherwise I'll look at it later. Regards, Tim Nathan Beyer (JIRA) wrote: > [classlib][luni] Java 5 enhancements for java.lang.Float > > > Key: HARMONY-239 > URL: http://issues.apache.org/jira/browse/HARMONY-239 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Nathan Beyer > > > Patch for Java 5 enhancements to java.lang.Float. > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
RE: [classlib] ant platform property definitions
Concerning the ideas for platform names, I think lower case names
like 'linux' and 'windows' and 'solaris' and 'aix' is by far the simplest
method. It avoids UPPER case errors with the shift key for these
_very_ common key sequences, reducing "Inaccurate kEy SEquences"
quite a bit. I have seen this work well for both platform names
and for project names (such as "newproj1" instead of "NewProj1")
with favorable long-term response from those who type the key
sequences most.
Bottom line:Mixed case just adds one more level of complexity
to the whole situation. Other comments below
Dan Lydick
> [Original Message]
> From: Mark Hindess <[EMAIL PROTECTED]>
> To: Harmony Dev
> Date: 3/29/06 10:28:41 AM
> Subject: [classlib] ant platform property definitions
>
> Currently a number of the classlib ant files "normalize" operating
> system and architecture names. Unfortunately they don't
> really normalize them in the same way. ;-)
>
> For instance, native-src/build.xml sets target.platform to
> "linux.IA32" and modules/security/make/build.xml sets "platform.name"
> to "lnx".
>
PLEASE, no abbreviations! Nobody abbreviates the same way, and
even one individual may use more than one abbreviation for a word!
> I think we should decide on a common normalized form and have a single
> common ant file to import that defines them. I'd already started to
> create one (as I was about to add platform defines in yet another ant
> file) but then I realised there wasn't any consensus about what the
> normalized form should be.
>
> I think having a mapping (from os.arch to hy.arch and os.name and
> hy.os) is useful because it reduces the coupling between Harmony and
> ant, and because it enables use to perform sensible normalizations.
> But, I don't think we should make the mapping unnecessarily
> complicated. I think we should keep the normal form as close as
> possible to the standard ant defines of os.name and os.arch.
>
> So, ${hy.os} would be ${os.name} - with values like 'Linux',
> 'Solaris', etc. - except for Windows where we would normalize to
> "Windows". Similarly, ${hy.arch} would be ${os.arch} - with values
> like 'x86', 'x86_64', 'ia64', etc. I see no clear reasons for
> exceptions to the ${hy.arch} at the moment, but we should create it
> and use it consistently.
>
> This would lead to "hy.platform" being defined as:
>
> Linux.x86
> Windows.x86
>
> We could add exceptions - for instance, to make 'Linux' lower case -
> but then we'd only need to add exceptions later for 'Solaris', 'Aix',
> etc. I think we'd be better to avoid this and only have exceptions
> where:
>
> * the name contains characters that can't be used in file names, or
> * there is a clear reason to normalize - e.g. "Windows XP", etc.
>
> So, what do people think? Is there a compelling reason to maintain
> the differences we have today - e.g. Linux in lowercase, 'ipf' rather
> than 'ia64' - or can we just stick with the ant defines?
>
I would like to have us all start thinking in this early stage about
abbreviations across the _whole_ of the Harmony component
roster. In particular, I would like to get my BootJVM code
using the same tokens as elsewhere. Right now, I am using,
OS names:
linux
cygwin
windows
solaris
CPU names:
intel
sparc
ppc
Word widths:
64
32
These are put together in different combinations in the
configuration-- ALL LOWER CASE ;-) -- and show
up in the file names for deliverables, etc., in this way.
For code defines, they are all in upper case per C coding
conventions.
When using mixed case in other situations (namely, version
control tags and branches), I have seen consistent confusion
with users, so I have always specified only one case for use
in some tokens. (For example, upper in tags, lower in
branches.)
>
> We also have many definitions of properties like "is.win",
> "is.windows", and "if.win". I'd prefer to stick to forms starting
> with 'is.' since I think they read better when used, e.g.
>
>
> ...
>
>
> and the item following the 'is.' prefix should be the all lowercase
> (in line with typical conventions for ant properties) but otherwise
> match the ${hy.os} and ${hy.arch} defines above.
>
> Assuming we reach a consensus, I think directories should be renamed
> to match the agreed definitions. We might as well change 'win.IA32'
> to 'Windows/x86' - or whatever we decide on - while we are doing this.
>
> I'll be happy to do the work to create the common ant file and to
> submit a JIRA with any layout changes (I think there will be some
> regardless of what decision is reach because of current differences).
>
> Regards,
> Mark.
>
> --
> Mark Hindess <[EMAIL PROTECTED]>
> IBM Java Technology Centre, UK.
EOL differences in svn diffs
Nikolay Kuznetsov (JIRA) wrote: > Nikolay Kuznetsov commented on HARMONY-271: > --- > > Tim, > > tank you very much for so such a quick response and integration. All the > changes are in place as was expected. > But there is one minor issue, affected files was somehow(svn commit, I > believe) converted into dos format(line terminators was changed for entire > files). > It's not a problem itself, but svn diff shows that entire file was changed > during this commit. Yes, I saw that too, and I agree that it makes it virtually impossible to see exactly what was changed. I used a windows machine to apply your patch and commit the code, so I can only assume that's why the file was converted to DOS EOL. I'll poke around to see if I can make it preserve the incoming EOL convention. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: SableVM and Harmony Class library
Sounds right (modulo step #2 comment made elsewhere). In case you missed it: the portlib, VM local storage(VMLS), and ZipCachePool (that are returned by functions in the VMI function table[1]) are provided as part of Harmony code base. The portlib function table is created by the java launcher and (a pointer) passed through to the VM as a vm_args during JNI_CreateJavaVM as: #define PORT_LIB_OPTION "_org.apache.harmony.vmi.portlib" The VMLS functions are designed for VM-global vars. The class library natives use VMLS rather than process-global statics so we can have multiple VM instances co-existing in the same process. I'll check in an example of a VMLS implementation you can use. The ZipCachePool is used to share open zip/jar files between the VM and classlibrary, you can create it using the functions in the include/zipsup.h, and stash it like this: myJavaVM->zipCachePool = zipCachePool_new(portLibrary); Regards, Tim [1] http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/structVMInterfaceFunctions__.html#_details Enrico Migliore wrote: > Hi, > >> The main document on porting is at: >> >> http://tinyurl.com/jfljq >> >> The VM Interface is described at: >> >> http://tinyurl.com/gtd64 >> >> and the required kernel classes are described at: >> >> http://tinyurl.com/hawkl >> >> Regards, >> Mark. >> >> > > Hi all, > > I'm reading the documentation above and, at first glance, it seems to me > that interfacing the SableVM to the Harmony Class Library is a task that > involves the following steps: > > step 1 > -- > The SableVM /has to/ implement the VM interface, in order for the > Harmony Class Library to "find" the entry points of a certain number of > native functions. The entry points are documented here: > > http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__VMInterface.html > > > > step 2 > -- > The SableVM has to implement a Java interface, which means that is /has > to/ implement in C a small set of Java classes, documented in the > following link: > > http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html#KernelJavaClasses > > > > step 3 > -- > The SableVM, in terms of native functions, /should/ call only the native > functions of the port layer, used by the Harmony Class Library: > > http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html#CreatePortLib > > > > Comments are welcome :-) > > Enrico > > > > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: SableVM and Harmony Class library
On 3/29/06, Enrico Migliore <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm reading the documentation above and, at first glance, it seems to me > that interfacing the SableVM to the Harmony Class Library is a task that > involves the following steps: > > step 1 > -- > The SableVM /has to/ implement the VM interface, in order for the > Harmony Class Library to "find" the entry points of a certain number of > native functions. The entry points are documented here: > > http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__VMInterface.html > > > step 2 > -- > The SableVM has to implement a Java interface, which means that is /has > to/ implement in C a small set of Java classes, documented in the > following link: > > http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html#KernelJavaClasses > Perhaps you have already found the empty java stubs at: modules/kernel/src/main/java/java/lang. To get an idea how much of the kernel class code need to be written in C vs. Java, take a look at the filled in kernel classes I did for "hello world" on JCMEVM. You can find it on JIRA at HARMONY-192. Note that I wrote almost zero C code. Most of the mods were in Java. > > step 3 > -- > The SableVM, in terms of native functions, /should/ call only the native > functions of the port layer, used by the Harmony Class Library: > > http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html#CreatePortLib > > > Comments are welcome :-) > > Enrico > > > > > > -- Weldon Washburn Intel Middleware Products Division
Re: SableVM and Harmony Class library
That's right, there is no hard requirement that these classes be written in any particular language. Of course they have to provide Java method interfaces to the rest of the class library so... In the IBM VM they are written as Java classes with some native methods. Harmony has compile-against stubs for these types in the 'kernel' module so we can build the remainder of the class library. Some of those stubs have parts of implementations that may be useful if people don't have a start of these types already. Weldon has been writing code to bridge the harmony kernel classes to the Classpath VM interface. Regards, Tim Etienne Gagnon wrote: > Up to now, SableVM has managed not to implement any class in C. Of > course, one could question the "efficiency" of doing so, but hardly > question the "maintainability" of it. :-) > > So, I do not think that step 2 is a hard requirement. (Methods, of > course, can be native). > > Etienne > > Enrico Migliore wrote: >> step 2 >> The SableVM has to implement a Java interface, which means that is /has >> to/ implement in C a small set of Java classes, documented in the >> following link: > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: SableVM and Harmony Class library
Up to now, SableVM has managed not to implement any class in C. Of course, one could question the "efficiency" of doing so, but hardly question the "maintainability" of it. :-) So, I do not think that step 2 is a hard requirement. (Methods, of course, can be native). Etienne Enrico Migliore wrote: > step 2 > The SableVM has to implement a Java interface, which means that is /has > to/ implement in C a small set of Java classes, documented in the > following link: -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
SableVM and Harmony Class library
Hi, The main document on porting is at: http://tinyurl.com/jfljq The VM Interface is described at: http://tinyurl.com/gtd64 and the required kernel classes are described at: http://tinyurl.com/hawkl Regards, Mark. Hi all, I'm reading the documentation above and, at first glance, it seems to me that interfacing the SableVM to the Harmony Class Library is a task that involves the following steps: step 1 -- The SableVM /has to/ implement the VM interface, in order for the Harmony Class Library to "find" the entry points of a certain number of native functions. The entry points are documented here: http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__VMInterface.html step 2 -- The SableVM has to implement a Java interface, which means that is /has to/ implement in C a small set of Java classes, documented in the following link: http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html#KernelJavaClasses step 3 -- The SableVM, in terms of native functions, /should/ call only the native functions of the port layer, used by the Harmony Class Library: http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html#CreatePortLib Comments are welcome :-) Enrico
[classlib] ant platform property definitions
Currently a number of the classlib ant files "normalize" operating
system and architecture names. Unfortunately they don't
really normalize them in the same way. ;-)
For instance, native-src/build.xml sets target.platform to
"linux.IA32" and modules/security/make/build.xml sets "platform.name"
to "lnx".
I think we should decide on a common normalized form and have a single
common ant file to import that defines them. I'd already started to
create one (as I was about to add platform defines in yet another ant
file) but then I realised there wasn't any consensus about what the
normalized form should be.
I think having a mapping (from os.arch to hy.arch and os.name and
hy.os) is useful because it reduces the coupling between Harmony and
ant, and because it enables use to perform sensible normalizations.
But, I don't think we should make the mapping unnecessarily
complicated. I think we should keep the normal form as close as
possible to the standard ant defines of os.name and os.arch.
So, ${hy.os} would be ${os.name} - with values like 'Linux',
'Solaris', etc. - except for Windows where we would normalize to
"Windows". Similarly, ${hy.arch} would be ${os.arch} - with values
like 'x86', 'x86_64', 'ia64', etc. I see no clear reasons for
exceptions to the ${hy.arch} at the moment, but we should create it
and use it consistently.
This would lead to "hy.platform" being defined as:
Linux.x86
Windows.x86
We could add exceptions - for instance, to make 'Linux' lower case -
but then we'd only need to add exceptions later for 'Solaris', 'Aix',
etc. I think we'd be better to avoid this and only have exceptions
where:
* the name contains characters that can't be used in file names, or
* there is a clear reason to normalize - e.g. "Windows XP", etc.
So, what do people think? Is there a compelling reason to maintain
the differences we have today - e.g. Linux in lowercase, 'ipf' rather
than 'ia64' - or can we just stick with the ant defines?
We also have many definitions of properties like "is.win",
"is.windows", and "if.win". I'd prefer to stick to forms starting
with 'is.' since I think they read better when used, e.g.
...
and the item following the 'is.' prefix should be the all lowercase
(in line with typical conventions for ant properties) but otherwise
match the ${hy.os} and ${hy.arch} defines above.
Assuming we reach a consensus, I think directories should be renamed
to match the agreed definitions. We might as well change 'win.IA32'
to 'Windows/x86' - or whatever we decide on - while we are doing this.
I'll be happy to do the work to create the common ant file and to
submit a JIRA with any layout changes (I think there will be some
regardless of what decision is reach because of current differences).
Regards,
Mark.
--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.
Re: [jira] Created: (HARMONY-239) [classlib][luni] Java 5 enhancements for java.lang.Float
Nathan, I have failing tests after applying this patch, notably in LUNI tests AssertionFailedError: Floattest0 at tests.api.java.lang.FloatTest.test_valueOfLjava_lang_String(FloatTest.java:579) and MATH tests BigDecimalConvertTest#testFloatValuePlusZero() Please take a look if you have time, otherwise I'll look at it later. Regards, Tim Nathan Beyer (JIRA) wrote: > [classlib][luni] Java 5 enhancements for java.lang.Float > > > Key: HARMONY-239 > URL: http://issues.apache.org/jira/browse/HARMONY-239 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Nathan Beyer > > > Patch for Java 5 enhancements to java.lang.Float. > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [jira] Created: (HARMONY-263) Enable more LUNI tests to run using XML exclusion list
I do. I don't like the idea that we need to use the suites like this. I'm going to write a little ant task on the plane today (if I make it) to deal with this, so please delay so we can compare the two solutions. geir Tim Ellison wrote: Does anyone object to this going in? It is the XML exclusion list that was described a while ago. My recollection is that people thought that it was a good idea -- but just rechecking before I go ahead. This will only be applied to LUNI at the moment, but the technique is generally applicable. Regards, Tim George Harley (JIRA) wrote: Enable more LUNI tests to run using XML exclusion list -- Key: HARMONY-263 URL: http://issues.apache.org/jira/browse/HARMONY-263 Project: Harmony Type: Improvement Components: Classlib Environment: All Reporter: George Harley This issue suggests running the LUNI test suite with a JUnit decorator that can exclude known test failures previously documented in an XML file. The exclusion list is already in the tree along with its XML schema (see jcltest-excludes.xml and excludes.xsd under support/src/test/resources) although it may be more helpful to move these to under the top level make directory. Similarly, the JUnit decorator class tests.util.SomeTests is already in the tree under support/src/test/java. The forthcoming patches propose updating the "run.tests" in modules/luni/make/common/build.xml to run a decorated version of the LUNI AllTests suite. Perhaps rather than being an outright replacement of the existing "run.tests" target this could be a peer target called something like "run.tests.with.exclusions" ? Hopefully the exclusions list and the JUnit decorator class approach suggested in this issue will be adopted in other modules besides LUNI. Note that because this issue enables more LUNI tests to run, the suite will take longer to complete and will run the java.net.* tests that rely on network servers (HTTP, FTP, SOCKS) being available as documented in the README included in HARMONY-57. If the servers are not available then failures will result which, I suppose, forces us to think about how we might bundle test servers into the tree and have them auto-started as the tests are run. Patches to follow... Best regards, George
Re: [Fwd: [announce-crypto] Bouncy Castle Crypto Provider Package version 1.32 now available]
sure - why not? Tim Ellison wrote: Should we move up to this new version? Regards, Tim Original Message Subject: [announce-crypto] Bouncy Castle Crypto Provider Package version 1.32 now available Date: Wed, 29 Mar 2006 12:56:18 +1100 From: Jon Eaves <[EMAIL PROTECTED]> To: dev-crypto <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], KVM Interest <[EMAIL PROTECTED]> Hi all, The latest relase of BC is now ready after a couple of false starts in the beta process. Thanks always to our tireless reporters of issues, one day maybe all vendors will create certificates in the same way. New features in this release include support for elliptic curves over F2m, suport for ECDSA with CMS and S/MIME, and support for a wider range of PSS signature types in CRL and certificate verification. In addition further work has been done on improving path validation compliance with RFC 3280, OpenPGP text signatures now work correctly in environments with '\r' as a line separator, a typo in the header for OpenPGP clear text SHA256 signatures has been fixed, several encoding compatability issue with the streaming CMS and S/MIME APIs have been fixed and it should now be possible to stop the S/MIME parsers from leaving temporary files around in all operating system environments. As usual, the latest releases can be found at : http://www.bouncycastle.org/ And for those who like living on the bleeding edge, the betas can be downloaded from: http://www.bouncycastle.org/betas/ Please note, make sure that beta feedback is sent to the [EMAIL PROTECTED] address, and not the general mailing list (dev-crypto)
Re: [jira] Created: (HARMONY-263) Enable more LUNI tests to run using XML exclusion list
Does anyone object to this going in? It is the XML exclusion list that was described a while ago. My recollection is that people thought that it was a good idea -- but just rechecking before I go ahead. This will only be applied to LUNI at the moment, but the technique is generally applicable. Regards, Tim George Harley (JIRA) wrote: > Enable more LUNI tests to run using XML exclusion list > -- > > Key: HARMONY-263 > URL: http://issues.apache.org/jira/browse/HARMONY-263 > Project: Harmony > Type: Improvement > Components: Classlib > Environment: All > Reporter: George Harley > > > This issue suggests running the LUNI test suite with a JUnit decorator that > can exclude known test failures previously documented in an XML file. > > The exclusion list is already in the tree along with its XML schema (see > jcltest-excludes.xml and excludes.xsd under support/src/test/resources) > although it may be more helpful to move these to under the top level make > directory. Similarly, the JUnit decorator class tests.util.SomeTests is > already in the tree under support/src/test/java. > > The forthcoming patches propose updating the "run.tests" in > modules/luni/make/common/build.xml to run a decorated version of the LUNI > AllTests suite. Perhaps rather than being an outright replacement of the > existing "run.tests" target this could be a peer target called something like > "run.tests.with.exclusions" ? > > Hopefully the exclusions list and the JUnit decorator class approach > suggested in this issue will be adopted in other modules besides LUNI. > > Note that because this issue enables more LUNI tests to run, the suite will > take longer to complete and will run the java.net.* tests that rely on > network servers (HTTP, FTP, SOCKS) being available as documented in the > README included in HARMONY-57. If the servers are not available then failures > will result which, I suppose, forces us to think about how we might bundle > test servers into the tree and have them auto-started as the tests are run. > > Patches to follow... > > Best regards, > George > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[Fwd: [announce-crypto] Bouncy Castle Crypto Provider Package version 1.32 now available]
Should we move up to this new version? Regards, Tim Original Message Subject: [announce-crypto] Bouncy Castle Crypto Provider Package version 1.32 now available Date: Wed, 29 Mar 2006 12:56:18 +1100 From: Jon Eaves <[EMAIL PROTECTED]> To: dev-crypto <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], KVM Interest <[EMAIL PROTECTED]> Hi all, The latest relase of BC is now ready after a couple of false starts in the beta process. Thanks always to our tireless reporters of issues, one day maybe all vendors will create certificates in the same way. New features in this release include support for elliptic curves over F2m, suport for ECDSA with CMS and S/MIME, and support for a wider range of PSS signature types in CRL and certificate verification. In addition further work has been done on improving path validation compliance with RFC 3280, OpenPGP text signatures now work correctly in environments with '\r' as a line separator, a typo in the header for OpenPGP clear text SHA256 signatures has been fixed, several encoding compatability issue with the streaming CMS and S/MIME APIs have been fixed and it should now be possible to stop the S/MIME parsers from leaving temporary files around in all operating system environments. As usual, the latest releases can be found at : http://www.bouncycastle.org/ And for those who like living on the bleeding edge, the betas can be downloaded from: http://www.bouncycastle.org/betas/ Please note, make sure that beta feedback is sent to the [EMAIL PROTECTED] address, and not the general mailing list (dev-crypto) -- Jon Eaves <[EMAIL PROTECTED]> http://www.eaves.org/blog/ Co-Author of "Apache Tomcat Bible", "Professional Tomcat 5", "Beginning JavaServer Pages" -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: VMI Questions
also available via : http://incubator.apache.org/harmony/subcomponents/classlibrary Regards, Tim Mark Hindess wrote: > The main document on porting is at: > > http://tinyurl.com/jfljq > > The VM Interface is described at: > > http://tinyurl.com/gtd64 > > and the required kernel classes are described at: > > http://tinyurl.com/hawkl > > Regards, > Mark. > > On 3/29/06, Enrico Migliore <[EMAIL PROTECTED]> wrote: >> Etienne Gagnon wrote: >> >>> Hi Weldon, >>> >>> I've started reading about the VMI. While my initial goal would be to >>> get SableVM to work with Harmony as a drop-in replacement for IBM's VM, >>> I have some questions about some assumptions of the VMI. >>> >>> >> Hi Etienne, >> >> could you tell me where I can find the documentation of the VMI? >> >> thanks a bunch, >> Enrico > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
