You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/01/12 13:46:52 UTC
Re: Test suite layout
Tim Ellison wrote:
> What we've tended to do, internally, is to name the testcases after the
> type they are testing, so all unit tests for java.io.File are put into a
> tests package ending with java.io in a type called FileTest that extends
> the junit.framework.TestCase.
Yes - that's the canonical way. Put it the the same package as what you
are testing, and then use a common name pattern to make it easy to
configure ant or maven with a wildcard.
*/*/*Test
>
> We would have written it as java.io.tests, but the java.<whatever>
> namespace is reserved, so the formula is simply
>
> <package>.<type> -> org.apache.harmony.tests.<package>.<type>Test
Ug - then you have the problem of not being in the namespace as what you
are testing.
THat's why people use parallel trees - so your test code is physically
separate but you have freedom of package access.
>
> This makes it clear what is being tested, and where to add new tests etc.
So would
test/org/apache/harmony/io/TestFoo.java
(to test something in org.apache.harmony.io, and arguable to test the
Foo.java class in there. (or TestFoo.java - it's early - no coffee yet)
Simiarly
test/java/util/TestMap.java
>
> Then within the test class itself the methods are named after the method
> under test, with a familar JNI-style encoding, so we have things like:
>
> org.apache.harmony.tests.java.io.FileTest contains
> public void test_ConstructorLjava_io_FileLjava_lang_String() {
> ...
> }
>
> and
>
> org.apache.harmony.tests.java.lang.FloatTest contains
> public void test_compareToLjava_lang_Float() {
> ...
> }
...or whatever the convention is for JUnit. I think that's one of the
nice things about TestNG, is that it's annotated, so you have the
freedom there.
>
>
> If the test is added due to a regression, then it is put into the right
> place in the test suite, and flagged with a comment (i.e. a reference to
> the Harmony JIRA number).
Yes - and I'd even advocate a parallel directory there too so that it's
clear that the regressions are different, but whatever. The only snag
there is name collision with the classes.
I think that a simple comment is enough. If we want to get cute, maybe
a javadoc tag so we can manage mechanically in the future.
geir
>
> Regards,
> Tim
>
>
> George Harley1 wrote:
>
>>Hi,
>>
>>
>>
>>>I think that regression tests should be marked in some way.
>>
>>
>>Agreed. But can we please *resist* the temptation to do this by
>>incorporating JIRA issue numbers into test case names (e.g. calling unit
>>test methods test_26() or test_JIRA_26()). I've seen this kind of approach
>>adopted in a couple of projects and, in my experience, it often leads to
>>the scattering of duplicated test code around the test harness.
>>
>>Better, methinks, to either create a new test method with a meaningful
>>name or else augment an existing method - whatever makes more sense for
>>the particular issue. Then marking certain code as being for regression
>>test purposes could be done in comments that include the URL of the JIRA
>>issue. Perhaps an agreed tag like "JIRA" or "BUG" etc could be used as an
>>eye-catcher as well ?
>>e.g.
>>
>>// BUG http://issues.apache.org/jira/browse/HARMONY-26
>>
>>
>>My 2 Euro Cents.
>>
>>Best regards,
>>George
>>________________________________________
>>George C. Harley
>>
>>
>>
>>
>>"Mishura, Stepan M" <st...@intel.com>
>>12/01/2006 04:56
>>Please respond to
>>harmony-dev@incubator.apache.org
>>
>>
>>To
>><ha...@incubator.apache.org>
>>cc
>>
>>Subject
>>RE: regression test suite
>>
>>
>>
>>
>>
>>
>>Hello,
>>
>>Tim Ellison wrote:
>>
>>[snip]
>>
>>
>>>What is the useful distinction for regression tests being kept
>>
>>separate?
>>
>>
>>>I can see that you may distinguish unit and 'system-level' tests just
>>>because of the difference in frameworks etc. required, but why do I
>>
>>care
>>
>>
>>>if the test was written due to a JIRA issue or test-based development
>>
>>or
>>
>>
>>>someone who get's kicks out of writing tests to break the code?
>>>
>>
>>
>>I agree that separating regression tests doesn't make sense.
>>However I think that regression tests should be marked in some way.
>>This will signal a developer that a test was created to track already
>>known issue. IMHO, a regression test should point out to a bug report
>>and a bug report (after resolving a bug) should contain a reference to
>>corresponding regression test in repository.
>>
>>Thanks,
>>Stepan Mishura
>>Intel Middleware Products Division
>>
>>
>>
>
>
Re: Test suite layout
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Paulex Yang wrote:
> Geir Magnusson Jr wrote:
>
>>
>>
>> Tim Ellison wrote:
>>
>>> What we've tended to do, internally, is to name the testcases after the
>>> type they are testing, so all unit tests for java.io.File are put into a
>>> tests package ending with java.io in a type called FileTest that extends
>>> the junit.framework.TestCase.
>>
>>
>>
>> Yes - that's the canonical way. Put it the the same package as what
>> you are testing, and then use a common name pattern to make it easy to
>> configure ant or maven with a wildcard.
>>
>> */*/*Test
>>
>>
>>>
>>> We would have written it as java.io.tests, but the java.<whatever>
>>> namespace is reserved, so the formula is simply
>>>
>>> <package>.<type> -> org.apache.harmony.tests.<package>.<type>Test
>>
>>
>>
>> Ug - then you have the problem of not being in the namespace as what
>> you are testing.
>>
>> THat's why people use parallel trees - so your test code is physically
>> separate but you have freedom of package access.
>>
>>>
>>> This makes it clear what is being tested, and where to add new tests
>>> etc.
>>
>>
>>
>> So would
>>
>> test/org/apache/harmony/io/TestFoo.java
>>
>> (to test something in org.apache.harmony.io, and arguable to test the
>> Foo.java class in there. (or TestFoo.java - it's early - no coffee yet)
>>
>> Simiarly
>>
>> test/java/util/TestMap.java
>>
>>>
>>> Then within the test class itself the methods are named after the method
>>> under test, with a familar JNI-style encoding, so we have things like:
>>>
>>> org.apache.harmony.tests.java.io.FileTest contains
>>> public void test_ConstructorLjava_io_FileLjava_lang_String() {
>>> ...
>>> }
>>>
>>> and
>>>
>>> org.apache.harmony.tests.java.lang.FloatTest contains
>>> public void test_compareToLjava_lang_Float() {
>>> ...
>>> }
>>
>>
>>
>> ...or whatever the convention is for JUnit. I think that's one of the
>> nice things about TestNG, is that it's annotated, so you have the
>> freedom there.
>
>
> Agree with you that annotation is great, and I just wish JUnit 4 can be
> released soon
> (check out an intro here
> http://www-128.ibm.com/developerworks/java/library/j-junit4.html)
>
> But even if we have more freedom, I think some convention is still
> *precious*, this name contract between test and method is one example.
> At least in Eclipse, I can easily find the test case for some certain
> method simply by ctrl+o and key in "test_"+method name, that's natural
> and easy, and if tests failed, I can see which method is wrong in just
> one glance, so personally I'm willing to pay the price to convention 8-)
Agreed, although I prefer TestGet, TestFoo, etc...
Re: Test suite layout
Posted by Paulex Yang <pa...@gmail.com>.
Geir Magnusson Jr wrote:
>
>
> Tim Ellison wrote:
>
>> What we've tended to do, internally, is to name the testcases after the
>> type they are testing, so all unit tests for java.io.File are put into a
>> tests package ending with java.io in a type called FileTest that extends
>> the junit.framework.TestCase.
>
>
> Yes - that's the canonical way. Put it the the same package as what
> you are testing, and then use a common name pattern to make it easy to
> configure ant or maven with a wildcard.
>
> */*/*Test
>
>
>>
>> We would have written it as java.io.tests, but the java.<whatever>
>> namespace is reserved, so the formula is simply
>>
>> <package>.<type> -> org.apache.harmony.tests.<package>.<type>Test
>
>
> Ug - then you have the problem of not being in the namespace as what
> you are testing.
>
> THat's why people use parallel trees - so your test code is physically
> separate but you have freedom of package access.
>
>>
>> This makes it clear what is being tested, and where to add new tests
>> etc.
>
>
> So would
>
> test/org/apache/harmony/io/TestFoo.java
>
> (to test something in org.apache.harmony.io, and arguable to test the
> Foo.java class in there. (or TestFoo.java - it's early - no coffee yet)
>
> Simiarly
>
> test/java/util/TestMap.java
>
>>
>> Then within the test class itself the methods are named after the method
>> under test, with a familar JNI-style encoding, so we have things like:
>>
>> org.apache.harmony.tests.java.io.FileTest contains
>> public void test_ConstructorLjava_io_FileLjava_lang_String() {
>> ...
>> }
>>
>> and
>>
>> org.apache.harmony.tests.java.lang.FloatTest contains
>> public void test_compareToLjava_lang_Float() {
>> ...
>> }
>
>
> ...or whatever the convention is for JUnit. I think that's one of the
> nice things about TestNG, is that it's annotated, so you have the
> freedom there.
Agree with you that annotation is great, and I just wish JUnit 4 can be
released soon
(check out an intro here
http://www-128.ibm.com/developerworks/java/library/j-junit4.html)
But even if we have more freedom, I think some convention is still
*precious*, this name contract between test and method is one example. At
least in Eclipse, I can easily find the test case for some certain
method simply by ctrl+o and key in "test_"+method name, that's natural
and easy, and if tests failed, I can see which method is wrong in just
one glance, so personally I'm willing to pay the price to convention 8-)
>>
>>
>> If the test is added due to a regression, then it is put into the right
>> place in the test suite, and flagged with a comment (i.e. a reference to
>> the Harmony JIRA number).
>
>
> Yes - and I'd even advocate a parallel directory there too so that
> it's clear that the regressions are different, but whatever. The only
> snag there is name collision with the classes.
>
> I think that a simple comment is enough. If we want to get cute,
> maybe a javadoc tag so we can manage mechanically in the future.
>
> geir
>
>>
>> Regards,
>> Tim
>>
>>
>> George Harley1 wrote:
>>
>>> Hi,
>>>
>>>
>>>> I think that regression tests should be marked in some way.
>>>
>>>
>>>
>>> Agreed. But can we please *resist* the temptation to do this by
>>> incorporating JIRA issue numbers into test case names (e.g. calling
>>> unit test methods test_26() or test_JIRA_26()). I've seen this kind
>>> of approach adopted in a couple of projects and, in my experience,
>>> it often leads to the scattering of duplicated test code around the
>>> test harness.
>>>
>>> Better, methinks, to either create a new test method with a
>>> meaningful name or else augment an existing method - whatever makes
>>> more sense for the particular issue. Then marking certain code as
>>> being for regression test purposes could be done in comments that
>>> include the URL of the JIRA issue. Perhaps an agreed tag like "JIRA"
>>> or "BUG" etc could be used as an eye-catcher as well ?
>>> e.g.
>>> // BUG http://issues.apache.org/jira/browse/HARMONY-26
>>>
>>>
>>> My 2 Euro Cents.
>>> Best regards, George
>>> ________________________________________
>>> George C. Harley
>>>
>>>
>>>
>>>
>>> "Mishura, Stepan M" <st...@intel.com> 12/01/2006 04:56
>>> Please respond to
>>> harmony-dev@incubator.apache.org
>>>
>>>
>>> To
>>> <ha...@incubator.apache.org>
>>> cc
>>>
>>> Subject
>>> RE: regression test suite
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hello,
>>> Tim Ellison wrote:
>>> [snip]
>>>
>>>
>>>> What is the useful distinction for regression tests being kept
>>>
>>>
>>> separate?
>>>
>>>
>>>> I can see that you may distinguish unit and 'system-level' tests just
>>>> because of the difference in frameworks etc. required, but why do I
>>>
>>>
>>> care
>>>
>>>
>>>> if the test was written due to a JIRA issue or test-based development
>>>
>>>
>>> or
>>>
>>>
>>>> someone who get's kicks out of writing tests to break the code?
>>>>
>>>
>>>
>>> I agree that separating regression tests doesn't make sense.
>>> However I think that regression tests should be marked in some way.
>>> This will signal a developer that a test was created to track already
>>> known issue. IMHO, a regression test should point out to a bug report
>>> and a bug report (after resolving a bug) should contain a reference to
>>> corresponding regression test in repository.
>>>
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>>
>>
>>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: Test suite layout
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>
>>Tim Ellison wrote:
>
> <snip>
>
>>>We would have written it as java.io.tests, but the java.<whatever>
>>>namespace is reserved, so the formula is simply
>>>
>>><package>.<type> -> org.apache.harmony.tests.<package>.<type>Test
>>
>>
>>Ug - then you have the problem of not being in the namespace as what you
>>are testing.
>>
>>THat's why people use parallel trees - so your test code is physically
>>separate but you have freedom of package access.
>
>
> For 'normal' application code then you can do this, but since we are
> writing the java packages themselves then you come unstuck because the
> java packages have to run on the bootclasspath, and the tests on the
> application classpath.
>
I thought we figured this out chatting at ApacheCon, but I don't
remember what it was.
Is the tail wagging the dog here? IOW, is this code unit-testable in a
framework outside of being on the boot classpath in the running host VM?
IOW, can we mock an environemnt to help here?
> You don't want to run all your tests on the bootclasspath (because then
> it would not be subject to the same security sandboxing as applications
> using the APIs you are testing); and you cannot put java.<whatever> on
> the application classpath because the VM will catch you out (you'd get a
> linkage error IIRC).
Right - but for unit tests, I would imagine there's a large class that
test functionality independent of this. Further, I think we'd want to
mock this so we can control the security sandboxing for more thorough
testing.
>
>
>>>This makes it clear what is being tested, and where to add new tests etc.
>>
>>
>>So would
>>
>> test/org/apache/harmony/io/TestFoo.java
>>
>>(to test something in org.apache.harmony.io, and arguable to test the
>>Foo.java class in there. (or TestFoo.java - it's early - no coffee yet)
>
>
> Not sure what you are saying here... For java.<whatever> packages we
> need a prefix on the test packages to keep the VM happy, but for
> org.apache.harmony packages we can have either pre- or post-.
>
> I'd actually prefer a postfix of .tests for non-API packages, though I
> can understand if people object to the inconsistency; so
>
> org.apache.harmony.tests.java.io.FileTest.java <- test API
> org.apache.harmony.io.tests.FileImpltest.java <- test public methods
> in our IO impl'
>
>
I'll wait until you respond to above.
>>Simiarly
>>
>> test/java/util/TestMap.java
>>
>>
>>>Then within the test class itself the methods are named after the method
>>>under test, with a familar JNI-style encoding, so we have things like:
>>>
>>>org.apache.harmony.tests.java.io.FileTest contains
>>> public void test_ConstructorLjava_io_FileLjava_lang_String() {
>>> ...
>>> }
>>>
>>>and
>>>
>>>org.apache.harmony.tests.java.lang.FloatTest contains
>>> public void test_compareToLjava_lang_Float() {
>>> ...
>>> }
>>
>>
>>...or whatever the convention is for JUnit. I think that's one of the
>>nice things about TestNG, is that it's annotated, so you have the
>>freedom there.
>>
>>
>>>
>>>If the test is added due to a regression, then it is put into the right
>>>place in the test suite, and flagged with a comment (i.e. a reference to
>>>the Harmony JIRA number).
>>
>>
>>Yes - and I'd even advocate a parallel directory there too so that it's
>>clear that the regressions are different, but whatever. The only snag
>>there is name collision with the classes.
>
>
> I thought we'd agreed that 'regression' was not a useful classification
> within the test suite layout ...
>
I don't remember - because I still believe that our regression tests are
going to be of broad scope, so having bucketing into kinds of tests will
make it easier for day to day development (i.e. devs can focus on
iterating w/ unit tests that require minimal infrastructure, while CI
infrastructure can do the broader, slower or more complicated testing...)
Either way, I suspect we'll be figuring it out as we go along.
>
>>I think that a simple comment is enough. If we want to get cute, maybe
>>a javadoc tag so we can manage mechanically in the future.
>
>
> ok -- do you have a usecase in mind?
For the tag? Sure - if you wanted to run through the code to see which
JIRAs had corresponding tests, for example...
>
> Regards,
> Tim
>
>
>
>>>George Harley1 wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>
>>>>
>>>>>I think that regression tests should be marked in some way.
>>>>
>>>>
>>>>
>>>>Agreed. But can we please *resist* the temptation to do this by
>>>>incorporating JIRA issue numbers into test case names (e.g. calling
>>>>unit test methods test_26() or test_JIRA_26()). I've seen this kind
>>>>of approach adopted in a couple of projects and, in my experience, it
>>>>often leads to the scattering of duplicated test code around the test
>>>>harness.
>>>>
>>>>Better, methinks, to either create a new test method with a
>>>>meaningful name or else augment an existing method - whatever makes
>>>>more sense for the particular issue. Then marking certain code as
>>>>being for regression test purposes could be done in comments that
>>>>include the URL of the JIRA issue. Perhaps an agreed tag like "JIRA"
>>>>or "BUG" etc could be used as an eye-catcher as well ?
>>>>e.g.
>>>>// BUG http://issues.apache.org/jira/browse/HARMONY-26
>>>>
>>>>
>>>>My 2 Euro Cents.
>>>>Best regards, George
>>>>________________________________________
>>>>George C. Harley
>>>>
>>>>
>>>>
>>>>
>>>>"Mishura, Stepan M" <st...@intel.com> 12/01/2006 04:56
>>>>Please respond to
>>>>harmony-dev@incubator.apache.org
>>>>
>>>>
>>>>To
>>>><ha...@incubator.apache.org>
>>>>cc
>>>>
>>>>Subject
>>>>RE: regression test suite
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>Hello,
>>>>Tim Ellison wrote:
>>>>[snip]
>>>>
>>>>
>>>>
>>>>>What is the useful distinction for regression tests being kept
>>>>
>>>>
>>>>separate?
>>>>
>>>>
>>>>
>>>>>I can see that you may distinguish unit and 'system-level' tests just
>>>>>because of the difference in frameworks etc. required, but why do I
>>>>
>>>>
>>>>care
>>>>
>>>>
>>>>
>>>>>if the test was written due to a JIRA issue or test-based development
>>>>
>>>>
>>>>or
>>>>
>>>>
>>>>
>>>>>someone who get's kicks out of writing tests to break the code?
>>>>>
>>>>
>>>>
>>>>I agree that separating regression tests doesn't make sense.
>>>>However I think that regression tests should be marked in some way.
>>>>This will signal a developer that a test was created to track already
>>>>known issue. IMHO, a regression test should point out to a bug report
>>>>and a bug report (after resolving a bug) should contain a reference to
>>>>corresponding regression test in repository.
>>>>
>>>>Thanks,
>>>>Stepan Mishura
>>>>Intel Middleware Products Division
>>>>
>>>>
>>>>
>>>
>>>
>
Re: Test suite layout
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> Tim Ellison wrote:
<snip>
>> We would have written it as java.io.tests, but the java.<whatever>
>> namespace is reserved, so the formula is simply
>>
>> <package>.<type> -> org.apache.harmony.tests.<package>.<type>Test
>
>
> Ug - then you have the problem of not being in the namespace as what you
> are testing.
>
> THat's why people use parallel trees - so your test code is physically
> separate but you have freedom of package access.
For 'normal' application code then you can do this, but since we are
writing the java packages themselves then you come unstuck because the
java packages have to run on the bootclasspath, and the tests on the
application classpath.
You don't want to run all your tests on the bootclasspath (because then
it would not be subject to the same security sandboxing as applications
using the APIs you are testing); and you cannot put java.<whatever> on
the application classpath because the VM will catch you out (you'd get a
linkage error IIRC).
>> This makes it clear what is being tested, and where to add new tests etc.
>
>
> So would
>
> test/org/apache/harmony/io/TestFoo.java
>
> (to test something in org.apache.harmony.io, and arguable to test the
> Foo.java class in there. (or TestFoo.java - it's early - no coffee yet)
Not sure what you are saying here... For java.<whatever> packages we
need a prefix on the test packages to keep the VM happy, but for
org.apache.harmony packages we can have either pre- or post-.
I'd actually prefer a postfix of .tests for non-API packages, though I
can understand if people object to the inconsistency; so
org.apache.harmony.tests.java.io.FileTest.java <- test API
org.apache.harmony.io.tests.FileImpltest.java <- test public methods
in our IO impl'
> Simiarly
>
> test/java/util/TestMap.java
>
>>
>> Then within the test class itself the methods are named after the method
>> under test, with a familar JNI-style encoding, so we have things like:
>>
>> org.apache.harmony.tests.java.io.FileTest contains
>> public void test_ConstructorLjava_io_FileLjava_lang_String() {
>> ...
>> }
>>
>> and
>>
>> org.apache.harmony.tests.java.lang.FloatTest contains
>> public void test_compareToLjava_lang_Float() {
>> ...
>> }
>
>
> ...or whatever the convention is for JUnit. I think that's one of the
> nice things about TestNG, is that it's annotated, so you have the
> freedom there.
>
>>
>>
>> If the test is added due to a regression, then it is put into the right
>> place in the test suite, and flagged with a comment (i.e. a reference to
>> the Harmony JIRA number).
>
>
> Yes - and I'd even advocate a parallel directory there too so that it's
> clear that the regressions are different, but whatever. The only snag
> there is name collision with the classes.
I thought we'd agreed that 'regression' was not a useful classification
within the test suite layout ...
> I think that a simple comment is enough. If we want to get cute, maybe
> a javadoc tag so we can manage mechanically in the future.
ok -- do you have a usecase in mind?
Regards,
Tim
>> George Harley1 wrote:
>>
>>> Hi,
>>>
>>>
>>>> I think that regression tests should be marked in some way.
>>>
>>>
>>>
>>> Agreed. But can we please *resist* the temptation to do this by
>>> incorporating JIRA issue numbers into test case names (e.g. calling
>>> unit test methods test_26() or test_JIRA_26()). I've seen this kind
>>> of approach adopted in a couple of projects and, in my experience, it
>>> often leads to the scattering of duplicated test code around the test
>>> harness.
>>>
>>> Better, methinks, to either create a new test method with a
>>> meaningful name or else augment an existing method - whatever makes
>>> more sense for the particular issue. Then marking certain code as
>>> being for regression test purposes could be done in comments that
>>> include the URL of the JIRA issue. Perhaps an agreed tag like "JIRA"
>>> or "BUG" etc could be used as an eye-catcher as well ?
>>> e.g.
>>> // BUG http://issues.apache.org/jira/browse/HARMONY-26
>>>
>>>
>>> My 2 Euro Cents.
>>> Best regards, George
>>> ________________________________________
>>> George C. Harley
>>>
>>>
>>>
>>>
>>> "Mishura, Stepan M" <st...@intel.com> 12/01/2006 04:56
>>> Please respond to
>>> harmony-dev@incubator.apache.org
>>>
>>>
>>> To
>>> <ha...@incubator.apache.org>
>>> cc
>>>
>>> Subject
>>> RE: regression test suite
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hello,
>>> Tim Ellison wrote:
>>> [snip]
>>>
>>>
>>>> What is the useful distinction for regression tests being kept
>>>
>>>
>>> separate?
>>>
>>>
>>>> I can see that you may distinguish unit and 'system-level' tests just
>>>> because of the difference in frameworks etc. required, but why do I
>>>
>>>
>>> care
>>>
>>>
>>>> if the test was written due to a JIRA issue or test-based development
>>>
>>>
>>> or
>>>
>>>
>>>> someone who get's kicks out of writing tests to break the code?
>>>>
>>>
>>>
>>> I agree that separating regression tests doesn't make sense.
>>> However I think that regression tests should be marked in some way.
>>> This will signal a developer that a test was created to track already
>>> known issue. IMHO, a regression test should point out to a bug report
>>> and a bug report (after resolving a bug) should contain a reference to
>>> corresponding regression test in repository.
>>>
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>>
>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.