You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by karan malhi <ka...@gmail.com> on 2006/02/15 21:39:04 UTC
newbie to project-where to start from
I need to know how I can start on harmony. I would like to start by
writing some tests.
Here are my questions :
1. Are there any predefined assertions to test or do we simply write
test after looking at the api docs for each method
2. Are there any naming conventions for test cases
3. When one files a JIRA for a failed test, does one also attach the
test to the JIRA
--
Karan Singh
Re: newbie to project-where to start from
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Is mauve modular?
I mean, suppose people were writing test cases that could be bundled
together and plugged in.
So if people were writing tests here in Harmony and (for whatever
reason) didn't contribute to Mauve, we still could publish and
distribute a "Mauve Test Bundle" that people could pick up and use...
geir
Tim Ellison wrote:
> Stuart Ballard wrote:
>> Geir Magnusson Jr <geir <at> pobox.com> writes:
>>> I think we should certainly be using Muave for testing. However, that
>>> doesn't remove the need for our own unit tests to be testing
>>> implementation internals.
>> Completely agree. Tests of implementation internals don't belong in Mauve of
>> course.
>
> Agreed.
>
>> I guess the question is whether, when a Harmony contributor wants to write a
>> test for documented, public, specified API functionality, should that test go in
>> Mauve instead of Harmony's own test framework?
>
> If the person is a Harmony contributor the test would go into Harmony
> wouldn't it? If they were a Mauve contributor it would go into Mauve?
> Of course these are not exclusive options.
>
>> Obviously I'd argue that it should, as then it benefits all implementations, not
>> just Harmony.
>
> How so? what is stopping all implementations running Harmony's Java API
> tests?
>
>> Plus if Harmony contributors are running Mauve regularly, they're
>> getting the benefits of Mauve tests contributed by developers of other
>> implementations too.
>
> Agreed, and that is a good thing. Since Mauve is under GPLv2 the tests
> won't end up in our repository tho' and the consequences of combining
> the tests into a single work have already been discussed.
>
>> (I've watched people go down this road before: I was following several projects
>> with independent class library implementations years before there was any
>> prospect of them merging into Classpath as they've now done. Even when there was
>> no cooperation on the library code, everybody seemed to agree it was in their
>> best interests to collaborate on the test suite...)
>
> Cool, we accept contributions from everyone who is eligible under the
> ACQ rules ;-)
>
>> If it *is* recommended for Harmony contributors to put such tests into Mauve,
>> that recommendation probably ought to be mentioned in answer to questions like
>> the one that I replied to; the original poster didn't say whether their tests
>> were going to be of implementation internals or not...
>
> There are a number of places that people can contribute. If people want
> their work to be GPLv2 compatible then Mauve is a good choice, if people
> want their work to be ASL compatible then Harmony is a good choice. I'm
> not going to suggest where people should contribute their efforts -- in
> the end it all benefits the open software ecosystem.
>
>>> Would you like to help us get it working in our build/test framework?
>> I'm afraid you're asking the wrong person: I can't get Mauve working at all...
>
> (let's not get into a license discussion again)
>
> Regards,
> Tim
>
Re: newbie to project-where to start from
Posted by Tim Ellison <t....@gmail.com>.
Stuart Ballard wrote:
> Geir Magnusson Jr <geir <at> pobox.com> writes:
>> I think we should certainly be using Muave for testing. However, that
>> doesn't remove the need for our own unit tests to be testing
>> implementation internals.
>
> Completely agree. Tests of implementation internals don't belong in Mauve of
> course.
Agreed.
> I guess the question is whether, when a Harmony contributor wants to write a
> test for documented, public, specified API functionality, should that test go in
> Mauve instead of Harmony's own test framework?
If the person is a Harmony contributor the test would go into Harmony
wouldn't it? If they were a Mauve contributor it would go into Mauve?
Of course these are not exclusive options.
> Obviously I'd argue that it should, as then it benefits all implementations, not
> just Harmony.
How so? what is stopping all implementations running Harmony's Java API
tests?
> Plus if Harmony contributors are running Mauve regularly, they're
> getting the benefits of Mauve tests contributed by developers of other
> implementations too.
Agreed, and that is a good thing. Since Mauve is under GPLv2 the tests
won't end up in our repository tho' and the consequences of combining
the tests into a single work have already been discussed.
> (I've watched people go down this road before: I was following several projects
> with independent class library implementations years before there was any
> prospect of them merging into Classpath as they've now done. Even when there was
> no cooperation on the library code, everybody seemed to agree it was in their
> best interests to collaborate on the test suite...)
Cool, we accept contributions from everyone who is eligible under the
ACQ rules ;-)
> If it *is* recommended for Harmony contributors to put such tests into Mauve,
> that recommendation probably ought to be mentioned in answer to questions like
> the one that I replied to; the original poster didn't say whether their tests
> were going to be of implementation internals or not...
There are a number of places that people can contribute. If people want
their work to be GPLv2 compatible then Mauve is a good choice, if people
want their work to be ASL compatible then Harmony is a good choice. I'm
not going to suggest where people should contribute their efforts -- in
the end it all benefits the open software ecosystem.
>> Would you like to help us get it working in our build/test framework?
>
> I'm afraid you're asking the wrong person: I can't get Mauve working at all...
(let's not get into a license discussion again)
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: newbie to project-where to start from
Posted by Stuart Ballard <st...@gmail.com>.
Geir Magnusson Jr <geir <at> pobox.com> writes:
> I think we should certainly be using Muave for testing. However, that
> doesn't remove the need for our own unit tests to be testing
> implementation internals.
Completely agree. Tests of implementation internals don't belong in Mauve of
course.
I guess the question is whether, when a Harmony contributor wants to write a
test for documented, public, specified API functionality, should that test go in
Mauve instead of Harmony's own test framework?
Obviously I'd argue that it should, as then it benefits all implementations, not
just Harmony. Plus if Harmony contributors are running Mauve regularly, they're
getting the benefits of Mauve tests contributed by developers of other
implementations too.
(I've watched people go down this road before: I was following several projects
with independent class library implementations years before there was any
prospect of them merging into Classpath as they've now done. Even when there was
no cooperation on the library code, everybody seemed to agree it was in their
best interests to collaborate on the test suite...)
If it *is* recommended for Harmony contributors to put such tests into Mauve,
that recommendation probably ought to be mentioned in answer to questions like
the one that I replied to; the original poster didn't say whether their tests
were going to be of implementation internals or not...
> Would you like to help us get it working in our build/test framework?
I'm afraid you're asking the wrong person: I can't get Mauve working at all...
Stuart.
Re: newbie to project-where to start from
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I think we should certainly be using Muave for testing. However, that
doesn't remove the need for our own unit tests to be testing
implementation internals.
Would you like to help us get it working in our build/test framework?
geir
Stuart Ballard wrote:
> Tim Ellison <t.p.ellison <at> gmail.com> writes:
>> We are using JUnit, so your test class extends junit.framework.TestCase.
>> Each test method is "public void test_<methodID>()" where <methodID> is
>> the method under test including param types; e.g. [3].
>
> Apologies if I'm (re)opening a can of worms here, but is there some reason why
> Harmony isn't collaborating with the existing and extensive Mauve test suite?
>
> I understand the license issues that prevent closer ties between Harmony and
> Classpath, even if I find them frustrating. But I don't see that there can
> possibly be license issues on a test suite, because individual tests are
> independent of each other so there's no reason they all have to share the same
> license.
>
> I can't quickly find an explicit statement of Mauve's license on its homepage[1]
> sadly.
>
> Stuart.
>
> [1] http://sourceware.org/mauve/
>
>
Re: newbie to project-where to start from
Posted by Stuart Ballard <st...@gmail.com>.
Tim Ellison <t.p.ellison <at> gmail.com> writes:
> We are using JUnit, so your test class extends junit.framework.TestCase.
> Each test method is "public void test_<methodID>()" where <methodID> is
> the method under test including param types; e.g. [3].
Apologies if I'm (re)opening a can of worms here, but is there some reason why
Harmony isn't collaborating with the existing and extensive Mauve test suite?
I understand the license issues that prevent closer ties between Harmony and
Classpath, even if I find them frustrating. But I don't see that there can
possibly be license issues on a test suite, because individual tests are
independent of each other so there's no reason they all have to share the same
license.
I can't quickly find an explicit statement of Mauve's license on its homepage[1]
sadly.
Stuart.
[1] http://sourceware.org/mauve/
Re: newbie to project-where to start from
Posted by Geir Magnusson Jr <ge...@pobox.com>.
karan malhi wrote:
> Tim,
>
> Thanks for such a detailed reply. I have a couple of more questions:
> 1. Do I have to sign and fax back the questionnaire before I start
> working on harmony ?
It would be good to have that information, yes. We want to be able to
demonstrate the provenance of our code, and this is a major element in
the system.
> 2. I know this is dumb but I saw in some previous posts that the tests
> were being compiled with jrockit.
You can compile with whatever you want.
However, we're trying to always move closer to self-hosting, so we've
been specifying the eclipse compiler in the ant build scripts.
So what I would do is mimic what we already have going on there.
> I guess I can use any compiler (sun)
> without causing any licensing issues - right?
Absolutely. Use whatever compiler you choose.
And even if there was an issue w/ the binary, you would only be
contributing the source code anyway.
Sorry, but I am very poor
> with this licensing stuff. Just want to make sure I am playing within
> the rules of the game.
No one here is a lawyer - it's hard for all of us...
geir
Re: newbie to project-where to start from
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Alexey Petrenko wrote:
> 2006/2/16, Tim Ellison <t....@gmail.com>:
>> Tests should be written to the javadoc spec, rather than deducing
>> behavior from any particular implementation.
> By the way...
> Do we want to be bug compatible with reference implementation?
I actually think so for now :)
Re: newbie to project-where to start from
Posted by karan malhi <ka...@gmail.com>.
Anton Avtamonov wrote:
IMHO, when spec states some exception we should be spec-compatible.
+1
>On 2/17/06, Mikhail Loenko <ml...@gmail.com> wrote:
>
>
>>I agree with Tim that we should discuss on the dev list
>>
>>
>
>+1
>
>
>
>>Later we might want to have some roadmap once we find a number
>>of similar issues
>>
>>At this point I think we might be compatible when RI throws
>>wrong exceptions - for example it often mixes NPE and
>>IllegalArgumentException
>>
>>
>
>Sometimes spec states IllegalArgumentException should be thrown, but
>implementation produces NPE. I think that is because
>IllegalArgumentException is missed in impl and algorithm just failed
>somewhere...
>IMHO, when spec states some exception we should be spec-compatible.
>
>--
>Anton Avtamonov,
>Intel Middleware Products Division
>
>
>
--
Karan Singh
Re: newbie to project-where to start from
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/17/06, Mikhail Loenko <ml...@gmail.com> wrote:
> I agree with Tim that we should discuss on the dev list
+1
>
> Later we might want to have some roadmap once we find a number
> of similar issues
>
> At this point I think we might be compatible when RI throws
> wrong exceptions - for example it often mixes NPE and
> IllegalArgumentException
Sometimes spec states IllegalArgumentException should be thrown, but
implementation produces NPE. I think that is because
IllegalArgumentException is missed in impl and algorithm just failed
somewhere...
IMHO, when spec states some exception we should be spec-compatible.
--
Anton Avtamonov,
Intel Middleware Products Division
Re: newbie to project-where to start from
Posted by Mikhail Loenko <ml...@gmail.com>.
I agree with Tim that we should discuss on the dev list
Later we might want to have some roadmap once we find a number
of similar issues
At this point I think we might be compatible when RI throws
wrong exceptions - for example it often mixes NPE and
IllegalArgumentException
Thanks,
Mikhail
On 2/17/06, Anton Avtamonov <an...@gmail.com> wrote:
> Just minor comment:
> Many times I saw very strange behavior in jdk which I was absolutely
> sure about: definitely a bug. But then... I found applications which
> used those strange things!
>
> I hust want to say that it is important to be very careful when
> deciding what is bug: it is very probable to find an application
> basing on it (java world is very very huge :) ).
>
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
>
> On 2/17/06, Tim Ellison <t....@gmail.com> wrote:
> > Mikhail Loenko wrote:
> > > depending on the bug...
> >
> > actually, this is the answer I would give too (which I know is not very
> > helpful).
> >
> > Some apparent 'bugs' are ambiguities in the spec, or a different choice
> > of under-specified behavior that we likely want to match to ensure
> > compatibility; others may be deemed implementation bugs that we should
> > not recreate.
> >
> > Sometimes it's a tough call, we should seek consensus on the dev list.
> >
> > > I would not like to be compatible with SIGSEGVs :)
> >
> > We'll have our own versions ;-)
> >
> > Regards,
> > Tim
> >
> > > Thanks,
> > > Mikhail
> > >
> > > On 2/16/06, Alexey Petrenko <al...@gmail.com> wrote:
> > >> 2006/2/16, Tim Ellison <t....@gmail.com>:
> > >>> Tests should be written to the javadoc spec, rather than deducing
> > >>> behavior from any particular implementation.
> > >> By the way...
> > >> Do we want to be bug compatible with reference implementation?
> > >>
> > >> --
> > >> Alexey A. Petrenko
> > >> Intel Middleware Products Division
> > >>
> > >
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
> >
>
Re: newbie to project-where to start from
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I agree - that is why I would say that since we are new to the
"Implementation of Java Family", we'd want to mimic the bugs (yes, with
discussion as I'm sure there will be bugs we don't want to mimic...).
The reason is that even if we're right - it's a bug - we're going not be
successful with that argument to Sun, the EG, users, whatever for a while.
We'll need to build up user-base and momentum. Then the story changes...
geir
Anton Avtamonov wrote:
> Just minor comment:
> Many times I saw very strange behavior in jdk which I was absolutely
> sure about: definitely a bug. But then... I found applications which
> used those strange things!
>
> I hust want to say that it is important to be very careful when
> deciding what is bug: it is very probable to find an application
> basing on it (java world is very very huge :) ).
>
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
>
> On 2/17/06, Tim Ellison <t....@gmail.com> wrote:
>> Mikhail Loenko wrote:
>>> depending on the bug...
>> actually, this is the answer I would give too (which I know is not very
>> helpful).
>>
>> Some apparent 'bugs' are ambiguities in the spec, or a different choice
>> of under-specified behavior that we likely want to match to ensure
>> compatibility; others may be deemed implementation bugs that we should
>> not recreate.
>>
>> Sometimes it's a tough call, we should seek consensus on the dev list.
>>
>>> I would not like to be compatible with SIGSEGVs :)
>> We'll have our own versions ;-)
>>
>> Regards,
>> Tim
>>
>>> Thanks,
>>> Mikhail
>>>
>>> On 2/16/06, Alexey Petrenko <al...@gmail.com> wrote:
>>>> 2006/2/16, Tim Ellison <t....@gmail.com>:
>>>>> Tests should be written to the javadoc spec, rather than deducing
>>>>> behavior from any particular implementation.
>>>> By the way...
>>>> Do we want to be bug compatible with reference implementation?
>>>>
>>>> --
>>>> Alexey A. Petrenko
>>>> Intel Middleware Products Division
>>>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>>
>
>
Re: newbie to project-where to start from
Posted by Anton Avtamonov <an...@gmail.com>.
Just minor comment:
Many times I saw very strange behavior in jdk which I was absolutely
sure about: definitely a bug. But then... I found applications which
used those strange things!
I hust want to say that it is important to be very careful when
deciding what is bug: it is very probable to find an application
basing on it (java world is very very huge :) ).
--
Anton Avtamonov,
Intel Middleware Products Division
On 2/17/06, Tim Ellison <t....@gmail.com> wrote:
> Mikhail Loenko wrote:
> > depending on the bug...
>
> actually, this is the answer I would give too (which I know is not very
> helpful).
>
> Some apparent 'bugs' are ambiguities in the spec, or a different choice
> of under-specified behavior that we likely want to match to ensure
> compatibility; others may be deemed implementation bugs that we should
> not recreate.
>
> Sometimes it's a tough call, we should seek consensus on the dev list.
>
> > I would not like to be compatible with SIGSEGVs :)
>
> We'll have our own versions ;-)
>
> Regards,
> Tim
>
> > Thanks,
> > Mikhail
> >
> > On 2/16/06, Alexey Petrenko <al...@gmail.com> wrote:
> >> 2006/2/16, Tim Ellison <t....@gmail.com>:
> >>> Tests should be written to the javadoc spec, rather than deducing
> >>> behavior from any particular implementation.
> >> By the way...
> >> Do we want to be bug compatible with reference implementation?
> >>
> >> --
> >> Alexey A. Petrenko
> >> Intel Middleware Products Division
> >>
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
>
Re: newbie to project-where to start from
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> depending on the bug...
actually, this is the answer I would give too (which I know is not very
helpful).
Some apparent 'bugs' are ambiguities in the spec, or a different choice
of under-specified behavior that we likely want to match to ensure
compatibility; others may be deemed implementation bugs that we should
not recreate.
Sometimes it's a tough call, we should seek consensus on the dev list.
> I would not like to be compatible with SIGSEGVs :)
We'll have our own versions ;-)
Regards,
Tim
> Thanks,
> Mikhail
>
> On 2/16/06, Alexey Petrenko <al...@gmail.com> wrote:
>> 2006/2/16, Tim Ellison <t....@gmail.com>:
>>> Tests should be written to the javadoc spec, rather than deducing
>>> behavior from any particular implementation.
>> By the way...
>> Do we want to be bug compatible with reference implementation?
>>
>> --
>> Alexey A. Petrenko
>> Intel Middleware Products Division
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: newbie to project-where to start from
Posted by Alexey Petrenko <al...@gmail.com>.
2006/2/16, Mikhail Loenko <ml...@gmail.com>:
> depending on the bug...
>
> I would not like to be compatible with SIGSEGVs :)
:)
You know what I mean :)
--
Alexey A. Petrenko
Intel Middleware Products Division
Re: newbie to project-where to start from
Posted by Mikhail Loenko <ml...@gmail.com>.
depending on the bug...
I would not like to be compatible with SIGSEGVs :)
Thanks,
Mikhail
On 2/16/06, Alexey Petrenko <al...@gmail.com> wrote:
> 2006/2/16, Tim Ellison <t....@gmail.com>:
> > Tests should be written to the javadoc spec, rather than deducing
> > behavior from any particular implementation.
> By the way...
> Do we want to be bug compatible with reference implementation?
>
> --
> Alexey A. Petrenko
> Intel Middleware Products Division
>
Re: newbie to project-where to start from
Posted by Alexey Petrenko <al...@gmail.com>.
2006/2/16, Tim Ellison <t....@gmail.com>:
> Tests should be written to the javadoc spec, rather than deducing
> behavior from any particular implementation.
By the way...
Do we want to be bug compatible with reference implementation?
--
Alexey A. Petrenko
Intel Middleware Products Division
Re: newbie to project-where to start from
Posted by Tim Ellison <t....@gmail.com>.
karan malhi wrote:
> Tim,
>
> Thanks for such a detailed reply. I have a couple of more questions:
> 1. Do I have to sign and fax back the questionnaire before I start
> working on harmony ?
You can start working straight away! but before we can accept your
contributions into the project we'll need to have a completed
questionnaire. If you have not worked on a java implementation before
then it should only take a couple of minutes to complete.
See the contribution policy here:
http://incubator.apache.org/harmony/contribution_policy.html
and the questionnaire here:
http://incubator.apache.org/harmony/auth_cont_quest.html
> 2. I know this is dumb but I saw in some previous posts that the tests
> were being compiled with jrockit. I guess I can use any compiler (sun)
> without causing any licensing issues - right? Sorry, but I am very poor
> with this licensing stuff. Just want to make sure I am playing within
> the rules of the game.
You can use whichever compiler you want (ensuring it is 1.4 compliant
;-) ), and then can compare your results against any complaint java
implementation (e.g. Sun, BEA, IBM, ...). Tests should be written to
the javadoc spec, rather than deducing behavior from any particular
implementation.
Thanks,
Tim
> Tim Ellison wrote:
>
>> karan malhi wrote:
>>
>>
>>> I need to know how I can start on harmony. I would like to start by
>>> writing some tests.
>>>
>>
>> That would be great -- thanks Karan!
>>
>> If you have detailed knowledge of another implementation of Java then we
>> need to talk further, otherwise dive right in. Examples of 'detailed
>> knowledge' can be found in the Harmony Questionnaire [0]
>>
>> [0] http://incubator.apache.org/harmony/auth_cont_quest.html
>>
>>
>>
>>> Here are my questions :
>>> 1. Are there any predefined assertions to test or do we simply write
>>> test after looking at the api docs for each method
>>>
>>
>> Looking at the spec and writing tests is a pretty good start. There are
>> some tests in the repository already, and some more incoming, but we'll
>> worry about merging new code into the full test suite.
>>
>>
>>
>>> 2. Are there any naming conventions for test cases
>>>
>>
>> Yes.
>>
>> Pick a module [1] that interests you and from there the test code is in
>> <module_name>/src/test/java/org.apache.harmony.tests.<pkg>.<type>Test.java
>>
>> where <pkg> and <type> are the package and type under test; see here [2]
>> for an example.
>>
>> We are using JUnit, so your test class extends junit.framework.TestCase.
>> Each test method is "public void test_<methodID>()" where <methodID> is
>> the method under test including param types; e.g. [3].
>>
>> Don't worry too much about the names, we'll fix them on the way in if
>> necessary.
>>
>> [1]
>> http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/
>>
>> [2]
>> http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/net/
>>
>> [3]
>> http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/net/InetAddressTest.java?view=markup
>>
>>
>>
>>
>>> 3. When one files a JIRA for a failed test, does one also attach the
>>> test to the JIRA
>>>
>>
>> Yes please, a succinct description with a unit test is great, and if you
>> have a proposed patch that would be even better ;-)
>>
>> We have had lots of good examples of bug reports, here's one I picked at
>> random to show the type of thing we like to see:
>> https://issues.apache.org/jira/browse/HARMONY-53
>>
>> Thanks again for your offer of help.
>>
>> Regards,
>> Tim
>>
>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: newbie to project-where to start from
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi Karan
if there is some area that you are interesting in the most, you might
want to say it and people who developed classes in that area
could advise for which of them are untested.
All,
I think it makes sense to include into the build a target that calculates
coverage - that would advise people where to contribute the tests.
BTW, what do you think about JCSC coverage tool?
http://jcsc.sourceforge.net/
Thanks,
Mikhail
On 2/16/06, karan malhi <ka...@gmail.com> wrote:
> Tim,
>
> Thanks for such a detailed reply. I have a couple of more questions:
> 1. Do I have to sign and fax back the questionnaire before I start
> working on harmony ?
> 2. I know this is dumb but I saw in some previous posts that the tests
> were being compiled with jrockit. I guess I can use any compiler (sun)
> without causing any licensing issues - right? Sorry, but I am very poor
> with this licensing stuff. Just want to make sure I am playing within
> the rules of the game.
>
>
> Tim Ellison wrote:
>
> >karan malhi wrote:
> >
> >
> >>I need to know how I can start on harmony. I would like to start by
> >>writing some tests.
> >>
> >>
> >
> >That would be great -- thanks Karan!
> >
> >If you have detailed knowledge of another implementation of Java then we
> >need to talk further, otherwise dive right in. Examples of 'detailed
> >knowledge' can be found in the Harmony Questionnaire [0]
> >
> >[0] http://incubator.apache.org/harmony/auth_cont_quest.html
> >
> >
> >
> >>Here are my questions :
> >>1. Are there any predefined assertions to test or do we simply write
> >>test after looking at the api docs for each method
> >>
> >>
> >
> >Looking at the spec and writing tests is a pretty good start. There are
> >some tests in the repository already, and some more incoming, but we'll
> >worry about merging new code into the full test suite.
> >
> >
> >
> >>2. Are there any naming conventions for test cases
> >>
> >>
> >
> >Yes.
> >
> >Pick a module [1] that interests you and from there the test code is in
> ><module_name>/src/test/java/org.apache.harmony.tests.<pkg>.<type>Test.java
> >where <pkg> and <type> are the package and type under test; see here [2]
> >for an example.
> >
> >We are using JUnit, so your test class extends junit.framework.TestCase.
> > Each test method is "public void test_<methodID>()" where <methodID> is
> >the method under test including param types; e.g. [3].
> >
> >Don't worry too much about the names, we'll fix them on the way in if
> >necessary.
> >
> >[1]
> >http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/
> >[2]
> >http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/net/
> >[3]
> >http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/net/InetAddressTest.java?view=markup
> >
> >
> >
> >>3. When one files a JIRA for a failed test, does one also attach the
> >>test to the JIRA
> >>
> >>
> >
> >Yes please, a succinct description with a unit test is great, and if you
> >have a proposed patch that would be even better ;-)
> >
> >We have had lots of good examples of bug reports, here's one I picked at
> >random to show the type of thing we like to see:
> > https://issues.apache.org/jira/browse/HARMONY-53
> >
> >Thanks again for your offer of help.
> >
> >Regards,
> >Tim
> >
> >
> >
>
> --
> Karan Singh
>
>
Re: newbie to project-where to start from
Posted by karan malhi <ka...@gmail.com>.
Tim,
Thanks for such a detailed reply. I have a couple of more questions:
1. Do I have to sign and fax back the questionnaire before I start
working on harmony ?
2. I know this is dumb but I saw in some previous posts that the tests
were being compiled with jrockit. I guess I can use any compiler (sun)
without causing any licensing issues - right? Sorry, but I am very poor
with this licensing stuff. Just want to make sure I am playing within
the rules of the game.
Tim Ellison wrote:
>karan malhi wrote:
>
>
>>I need to know how I can start on harmony. I would like to start by
>>writing some tests.
>>
>>
>
>That would be great -- thanks Karan!
>
>If you have detailed knowledge of another implementation of Java then we
>need to talk further, otherwise dive right in. Examples of 'detailed
>knowledge' can be found in the Harmony Questionnaire [0]
>
>[0] http://incubator.apache.org/harmony/auth_cont_quest.html
>
>
>
>>Here are my questions :
>>1. Are there any predefined assertions to test or do we simply write
>>test after looking at the api docs for each method
>>
>>
>
>Looking at the spec and writing tests is a pretty good start. There are
>some tests in the repository already, and some more incoming, but we'll
>worry about merging new code into the full test suite.
>
>
>
>>2. Are there any naming conventions for test cases
>>
>>
>
>Yes.
>
>Pick a module [1] that interests you and from there the test code is in
><module_name>/src/test/java/org.apache.harmony.tests.<pkg>.<type>Test.java
>where <pkg> and <type> are the package and type under test; see here [2]
>for an example.
>
>We are using JUnit, so your test class extends junit.framework.TestCase.
> Each test method is "public void test_<methodID>()" where <methodID> is
>the method under test including param types; e.g. [3].
>
>Don't worry too much about the names, we'll fix them on the way in if
>necessary.
>
>[1]
>http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/
>[2]
>http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/net/
>[3]
>http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/net/InetAddressTest.java?view=markup
>
>
>
>>3. When one files a JIRA for a failed test, does one also attach the
>>test to the JIRA
>>
>>
>
>Yes please, a succinct description with a unit test is great, and if you
>have a proposed patch that would be even better ;-)
>
>We have had lots of good examples of bug reports, here's one I picked at
>random to show the type of thing we like to see:
> https://issues.apache.org/jira/browse/HARMONY-53
>
>Thanks again for your offer of help.
>
>Regards,
>Tim
>
>
>
--
Karan Singh
Re: old faithful
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> Tim Ellison wrote:
>>
>>> Pick a module [1] that interests you and from there the test code is in
>>> <module_name>/src/test/java/org.apache.harmony.tests.<pkg>.<type>Test.java
>>>
>>> where <pkg> and <type> are the package and type under test; see here [2]
>>> for an example.
>> I'm not convinced that we should only use this package convention for
>> tests.
>>
>> One should certainly be able to put a test in the same package as the
>> class being tested...
>
> ah that old favourite ;-)
We never resolved it.
>
> I'm sure that I don't need to repeat myself, but, 'oh go on then'
>
> - you cannot put code in java.* packages without running
> them on the bootclasspath.
>
> - I am *strongly* opposed to running tests on the bootclasspath
> - the code is subject to different rules c.f. app classpath
> - our target apps don't run there so the API tests are bogus
I support this argument for code that tests the API as a client would -
i.e. as app code uses the API.
As for testing internals of java.foo.....
>
> - I agree with putting helpers into the bootclasspath to expose
> implementation classes that are tested (by tests on the app
> class path)
> - I would like to see a separation of java API tests and impl
> tests, so we know which ones we expect to pass on any
> compliant impl.
Yes - I agree with the last bit.
So how do we move forward? Is it worth investigating some kind of test
harness that gives us the control we need for security and classloader
issues so we can split of tests that want to be java.foo and those that
are o.a.h.x.test....
geir
geir
Re: old faithful (was: Re: newbie to project-where to start from)
Posted by Mikhail Loenko <ml...@gmail.com>.
Tim,
On 2/16/06, Tim Ellison <t....@gmail.com> wrote:
> Geir Magnusson Jr wrote:
> > Tim Ellison wrote:
> >
> >> Pick a module [1] that interests you and from there the test code is in
> >> <module_name>/src/test/java/org.apache.harmony.tests.<pkg>.<type>Test.java
> >>
> >> where <pkg> and <type> are the package and type under test; see here [2]
> >> for an example.
> >
> > I'm not convinced that we should only use this package convention for
> > tests.
> >
> > One should certainly be able to put a test in the same package as the
> > class being tested...
>
> ah that old favourite ;-)
>
> I'm sure that I don't need to repeat myself, but, 'oh go on then'
>
> - you cannot put code in java.* packages without running
> them on the bootclasspath.
>
> - I am *strongly* opposed to running tests on the bootclasspath
> - the code is subject to different rules c.f. app classpath
> - our target apps don't run there so the API tests are bogus
It might make sense to stronly insist to running tests in
the application classpath. But to oppose running them
in bootclasspath it looks necessary to formally prove that this
run would not find any new bug
More testing is always better...
$0.02
Thanks,
Mikhail
> - I agree with putting helpers into the bootclasspath to expose
> implementation classes that are tested (by tests on the app
> class path)
> - I would like to see a separation of java API tests and impl
> tests, so we know which ones we expect to pass on any
> compliant impl.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
old faithful (was: Re: newbie to project-where to start from)
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>
>> Pick a module [1] that interests you and from there the test code is in
>> <module_name>/src/test/java/org.apache.harmony.tests.<pkg>.<type>Test.java
>>
>> where <pkg> and <type> are the package and type under test; see here [2]
>> for an example.
>
> I'm not convinced that we should only use this package convention for
> tests.
>
> One should certainly be able to put a test in the same package as the
> class being tested...
ah that old favourite ;-)
I'm sure that I don't need to repeat myself, but, 'oh go on then'
- you cannot put code in java.* packages without running
them on the bootclasspath.
- I am *strongly* opposed to running tests on the bootclasspath
- the code is subject to different rules c.f. app classpath
- our target apps don't run there so the API tests are bogus
- I agree with putting helpers into the bootclasspath to expose
implementation classes that are tested (by tests on the app
class path)
- I would like to see a separation of java API tests and impl
tests, so we know which ones we expect to pass on any
compliant impl.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: newbie to project-where to start from
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Pick a module [1] that interests you and from there the test code is in
> <module_name>/src/test/java/org.apache.harmony.tests.<pkg>.<type>Test.java
> where <pkg> and <type> are the package and type under test; see here [2]
> for an example.
I'm not convinced that we should only use this package convention for tests.
One should certainly be able to put a test in the same package as the
class being tested...
geir
Re: newbie to project-where to start from
Posted by James Pluck <pa...@gmail.com>.
On 2/22/06, Tim Ellison <t....@gmail.com> wrote:
> James,
>
> Feel free to take a look at all the math areas of JSE in Harmony -- try
> running some code (do you have any math apps that you use?) or try
> measuring some performance numbers. Performance enhancement patches
> will be most welcome.
Good idea Tim. I've just completed my Science degree in Maths and
CompSci so I have quite a few algorithms bouncing in my head that I
might be able to use.
Thanks for the suggestions. It's given me a better idea of where to
start anyway. This is a huge project and it was a little daunting to
know where I could best help out.
Cheers
James.
--
James Pluck
PalmOS Ergo Sum
Re: newbie to project-where to start from
Posted by Tim Ellison <t....@gmail.com>.
James,
Feel free to take a look at all the math areas of JSE in Harmony -- try
running some code (do you have any math apps that you use?) or try
measuring some performance numbers. Performance enhancement patches
will be most welcome.
Regards,
Tim
James Pluck wrote:
> On 2/20/06, Vladimir Gorr <vv...@gmail.com> wrote:
>> Hi James,
>>
>> in case if you are not aware yet I'd like to mention the HARMONY-39
>> contribution
>> contains the full implementation for java.math package (both BigInteger &
>> BigDecimal).
>>
>> Thanks,
>> Vladimir Gorr,
>> Intel Middleware Products Division.
>
> Thanks Vladimir! I'll have a look.
>
> --
> James Pluck
> PalmOS Ergo Sum
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: newbie to project-where to start from
Posted by James Pluck <pa...@gmail.com>.
On 2/20/06, Vladimir Gorr <vv...@gmail.com> wrote:
> Hi James,
>
> in case if you are not aware yet I'd like to mention the HARMONY-39
> contribution
> contains the full implementation for java.math package (both BigInteger &
> BigDecimal).
>
> Thanks,
> Vladimir Gorr,
> Intel Middleware Products Division.
Thanks Vladimir! I'll have a look.
--
James Pluck
PalmOS Ergo Sum
Re: newbie to project-where to start from
Posted by Vladimir Gorr <vv...@gmail.com>.
Hi James,
in case if you are not aware yet I'd like to mention the HARMONY-39
contribution
contains the full implementation for java.math package (both BigInteger &
BigDecimal).
Thanks,
Vladimir Gorr,
Intel Middleware Products Division.
On 2/18/06, James Pluck <pa...@gmail.com> wrote:
>
> Geir Magnusson Jr wrote:
> >
> >
> > James Pluck wrote:
> >> Just piggybacking on this. I've been on the mailing list for some
> >> months now and have downloaded the code and been brwosing through it.
> >> I'm a reasonably adept programmer but this is a very major project and
> >> it's a little daunting to know just where to begin. I'd appreciate
> >> any suggestions of where I might be best able to contribute my time.
> >> I'd prefer to work on the actual implementation rather than just
> >> testing if possible but I'm keen to help out anywhere that might be
> >> useful.
> >
> > What would you like to work on? We clearly need bunches of things,
> > including the standard included utilities, so start thinking about an
> > area that you would really enjoy to work on....
>
> Personally I'm a bit of a Math geek so perhaps the math or bigmath areas
> would be a good place for me to start. I would be keen to talk with
> anyone who is already working on this area so that we can minimise
> duplication of work.
>
> > (I'd love to see someone get our compiler-launcher done, so we would
> > have javac using the eclipse compiler.)
>
> Unfortunately I have very little knowledge and experience in writing
> compilers so I would be of limited use here - except perhaps as a beta
> tester.
>
> James Pluck
>
Re: newbie to project-where to start from
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Matt Benson wrote:
> --- James Pluck <pa...@gmail.com> wrote:
>> Geir Magnusson Jr wrote:
> [SNIP]
>>> (I'd love to see someone get our compiler-launcher
>> done, so we would
>>> have javac using the eclipse compiler.)
>> Unfortunately I have very little knowledge and
>> experience in writing
>> compilers so I would be of limited use here - except
>> perhaps as a beta
>> tester.
>
> Know that the current plan is to use Eclipse's JDT
> compiler, so a launcher for it, and any assisting
> massaging needed to make it behave identically to 1.5
> javac, is all that is needed, as I understand it.
Yep
>
> -Matt
>
>> James Pluck
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
Re: newbie to project-where to start from
Posted by Matt Benson <gu...@yahoo.com>.
--- James Pluck <pa...@gmail.com> wrote:
> Geir Magnusson Jr wrote:
[SNIP]
> > (I'd love to see someone get our compiler-launcher
> done, so we would
> > have javac using the eclipse compiler.)
>
> Unfortunately I have very little knowledge and
> experience in writing
> compilers so I would be of limited use here - except
> perhaps as a beta
> tester.
Know that the current plan is to use Eclipse's JDT
compiler, so a launcher for it, and any assisting
massaging needed to make it behave identically to 1.5
javac, is all that is needed, as I understand it.
-Matt
>
> James Pluck
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: newbie to project-where to start from
Posted by James Pluck <pa...@gmail.com>.
Geir Magnusson Jr wrote:
>
>
> James Pluck wrote:
>> Just piggybacking on this. I've been on the mailing list for some
>> months now and have downloaded the code and been brwosing through it.
>> I'm a reasonably adept programmer but this is a very major project and
>> it's a little daunting to know just where to begin. I'd appreciate
>> any suggestions of where I might be best able to contribute my time.
>> I'd prefer to work on the actual implementation rather than just
>> testing if possible but I'm keen to help out anywhere that might be
>> useful.
>
> What would you like to work on? We clearly need bunches of things,
> including the standard included utilities, so start thinking about an
> area that you would really enjoy to work on....
Personally I'm a bit of a Math geek so perhaps the math or bigmath areas
would be a good place for me to start. I would be keen to talk with
anyone who is already working on this area so that we can minimise
duplication of work.
> (I'd love to see someone get our compiler-launcher done, so we would
> have javac using the eclipse compiler.)
Unfortunately I have very little knowledge and experience in writing
compilers so I would be of limited use here - except perhaps as a beta
tester.
James Pluck
Re: newbie to project-where to start from
Posted by Geir Magnusson Jr <ge...@pobox.com>.
James Pluck wrote:
> Just piggybacking on this. I've been on the mailing list for some
> months now and have downloaded the code and been brwosing through it.
> I'm a reasonably adept programmer but this is a very major project and
> it's a little daunting to know just where to begin. I'd appreciate
> any suggestions of where I might be best able to contribute my time.
> I'd prefer to work on the actual implementation rather than just
> testing if possible but I'm keen to help out anywhere that might be
> useful.
What would you like to work on? We clearly need bunches of things,
including the standard included utilities, so start thinking about an
area that you would really enjoy to work on....
(I'd love to see someone get our compiler-launcher done, so we would
have javac using the eclipse compiler.)
geir
Re: newbie to project-where to start from
Posted by James Pluck <pa...@gmail.com>.
Just piggybacking on this. I've been on the mailing list for some
months now and have downloaded the code and been brwosing through it.
I'm a reasonably adept programmer but this is a very major project and
it's a little daunting to know just where to begin. I'd appreciate
any suggestions of where I might be best able to contribute my time.
I'd prefer to work on the actual implementation rather than just
testing if possible but I'm keen to help out anywhere that might be
useful.
Cheers
James.
--
James Pluck
PalmOS Ergo Sum
Re: newbie to project-where to start from
Posted by Tim Ellison <t....@gmail.com>.
karan malhi wrote:
> I need to know how I can start on harmony. I would like to start by
> writing some tests.
That would be great -- thanks Karan!
If you have detailed knowledge of another implementation of Java then we
need to talk further, otherwise dive right in. Examples of 'detailed
knowledge' can be found in the Harmony Questionnaire [0]
[0] http://incubator.apache.org/harmony/auth_cont_quest.html
> Here are my questions :
> 1. Are there any predefined assertions to test or do we simply write
> test after looking at the api docs for each method
Looking at the spec and writing tests is a pretty good start. There are
some tests in the repository already, and some more incoming, but we'll
worry about merging new code into the full test suite.
> 2. Are there any naming conventions for test cases
Yes.
Pick a module [1] that interests you and from there the test code is in
<module_name>/src/test/java/org.apache.harmony.tests.<pkg>.<type>Test.java
where <pkg> and <type> are the package and type under test; see here [2]
for an example.
We are using JUnit, so your test class extends junit.framework.TestCase.
Each test method is "public void test_<methodID>()" where <methodID> is
the method under test including param types; e.g. [3].
Don't worry too much about the names, we'll fix them on the way in if
necessary.
[1]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/
[2]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/net/
[3]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/net/InetAddressTest.java?view=markup
> 3. When one files a JIRA for a failed test, does one also attach the
> test to the JIRA
Yes please, a succinct description with a unit test is great, and if you
have a proposed patch that would be even better ;-)
We have had lots of good examples of bug reports, here's one I picked at
random to show the type of thing we like to see:
https://issues.apache.org/jira/browse/HARMONY-53
Thanks again for your offer of help.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.