Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Geir Magnusson Jr wrote: Anton Avtamonov wrote: On 2/27/06, Mikhail Loenko [EMAIL PROTECTED] wrote: As I understood people in this and similar threads tend to be compatible with the Spec rather then with RI (unless we prove that being incompatible with RI breaks some existing implementation) I'm trying to oppose that, I'd to be compatible with RI when in doubt. Well, actually you are right. I disagree just to simply copy all the existing bugs... And as I rememeber I'm not along :-). The main idea is to follow the guidelines Paulex proposed, i.e. to be reasonable. Lemme remember Paulex's rules: 1. we should comply with spec 2. if RI is contradict with spec, and RI is not logical(sometimes it is very obvious, you know what I mean), we comply with RI; else, we discuss it case by case. 3. if spec is not so clear, we should comply with RI 4. if some application failing on that different behavior, we discuss it case by case 5. Log every difference from either the spec or the RI in JIRA. +1 from me. I believe this approach will give better results: keepping us compatible with the existing applications and provide more consistent implementation where possible. Note that according to the rules above we are not mandatory follow to the spec. Btw, releasing new JDK SUN updates some existing methods, sometimes changing not only internal implementation, but even some behavior. I suppose they don't run all existing applications to make sure nothing is broken :-). I don't know how this process is organized, however I would expect some kind of CCB (Change Control Board) which decide if it's safe change or not. I suppose our mailing list can act in a very similar manner. Actually, I think that Sun does have an internal group which does exactly that. I've heard some great stories about the raging fights that have erupted internally due to this process... We'll get to have our great fights here :) That's the way to harmony ;-) geir -- Anton Avtamonov, Intel Middleware Products Division -- Paulex Yang China Software Development Lab IBM
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Ah, I must say sorry at first, because I guess some confuse has been caused due to my typo on my proposal about the bug-compatible principles, O:-) , I copied it here: quote from posts before 1. we should comply with spec 2. if RI is contradict with spec, and RI is not logical(sometimes it is very obvious, you know what I mean), we comply with RI; else, we discuss it case by case. 3. if spec is not so clear, we should comply with RI 4. if some application failing on that different behavior, we discuss it case by case /quote The second line, I meant to be: 2. if RI is contradict with spec, and RI is not logical(sometimes it is very obvious, you know what I mean), we comply with _*SPEC*_; else, we discuss it case by case. The second principle is very important, and I made a typo on the most important word in this sentence, I'm really, really sorry about the confuse caused, I myself is almost faint when I found it just now :-[ . I think I'd better clarify my reasoning about this principle here again, we should comply with RI when spec is not clear, we can try to comply with RI when sometimes RI is different with spec and can justify itself. BUT sometimes, RI is not logical, and then we should comply with spec. As an example, I posted two test cases about RI's CharsetDecoder internal status, in which case, RI's behavior is contradict with spec at several places and it is not logical to be understood. Mikhail Loenko wrote: 2006/2/27, Geir Magnusson Jr [EMAIL PROTECTED]: Mikhail Loenko wrote: How will we verify Harmony with all existing apps in the world? Gump :) Why should we cross fingers and believe that most of the users do not have such apps rather then make it compatible with RI and be [almost] sure that all apps working on RI will work on Harmony? I'm confused. Isn't that one of our principles? On a case by case basis, examine our deviance from RI or spec, but lean towards making compatible with RI? As I understood people in this and similar threads tend to be compatible with the Spec rather then with RI (unless we prove that being incompatible with RI breaks some existing implementation) I'm trying to oppose that, I'd to be compatible with RI when in doubt. Thanks, Mikhail geir Thanks, Mikhail On 2/20/06, Tim Ellison [EMAIL PROTECTED] wrote: I agree Anton, these are the right guiding principles and the proof will be in running apps. Regards, Tim Anton Avtamonov wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Well seems like we all agree with the general approach. Yes. Agree. But... :) I do not agree with the specific case you describe: NPE vs. IAE. I can imagine a programmer who does not read the spec, who does not want to check for null, who just makes 'catch NPE' somewhere Mikhail, I definitely can imagine the same story. I only want to have such application first. Then we will be able to judge and decide what to do. Before that no need to deviate from spec (of cource, excepting the cases when spec itself contains bugs as in my example with GrayFilter when required exception is missed from spec). In your example, such 'professional' developer most likely catches just Exception rather then the particular one :-) And his app would work well on RI and fail with uncaught IAE on Harmony if we follow the spec. So, what is the reason in this very specific case to firmly follow the spec? Because NPE (IMHO) is not well-defined way to inform the developer something is wrong with his/her code. It just shows 'something inside implementation' fails (excluding cases when NPE contains proper message and is thrown intentively). In opposite, IAE always shows programmer called the method with wrong input values. All is about better notation only. In case existing program specified percentage outside the reasonable range, for instance, and worked anyway it may be even better to clearly inform the developer something is wrong with the program. Because in reality there were no garantee that such incorrect code worked properly on Sun's impl: just a play of chance. Of course we should not add more exceptions than exist in code/spec (at least for now), but try to use 'proper' exceptions with better notation clear for the developers. I propose to continue this discussion when we have real examples, i.e. real applications failed because of such differences or particular methods which can potentially fail applications... Otherwise the discussion is quite abstract... Just IMHO. -- Anton Avtamonov, Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Paulex Yang China Software Development Lab IBM
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/27/06, Paulex Yang [EMAIL PROTECTED] wrote: The second line, I meant to be: 2. if RI is contradict with spec, and RI is not logical(sometimes it is very obvious, you know what I mean), we comply with _*SPEC*_; else, we discuss it case by case. I also missed that! The idea was absolutely clear, particular words are not important :-) -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Anton Avtamonov wrote: On 2/27/06, Mikhail Loenko [EMAIL PROTECTED] wrote: As I understood people in this and similar threads tend to be compatible with the Spec rather then with RI (unless we prove that being incompatible with RI breaks some existing implementation) I'm trying to oppose that, I'd to be compatible with RI when in doubt. Well, actually you are right. I disagree just to simply copy all the existing bugs... And as I rememeber I'm not along :-). The main idea is to follow the guidelines Paulex proposed, i.e. to be reasonable. Lemme remember Paulex's rules: 1. we should comply with spec 2. if RI is contradict with spec, and RI is not logical(sometimes it is very obvious, you know what I mean), we comply with RI; else, we discuss it case by case. 3. if spec is not so clear, we should comply with RI 4. if some application failing on that different behavior, we discuss it case by case 5. Log every difference from either the spec or the RI in JIRA. I believe this approach will give better results: keepping us compatible with the existing applications and provide more consistent implementation where possible. Note that according to the rules above we are not mandatory follow to the spec. Btw, releasing new JDK SUN updates some existing methods, sometimes changing not only internal implementation, but even some behavior. I suppose they don't run all existing applications to make sure nothing is broken :-). I don't know how this process is organized, however I would expect some kind of CCB (Change Control Board) which decide if it's safe change or not. I suppose our mailing list can act in a very similar manner. Actually, I think that Sun does have an internal group which does exactly that. I've heard some great stories about the raging fights that have erupted internally due to this process... We'll get to have our great fights here :) geir -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/27/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Lemme remember Paulex's rules: 1. we should comply with spec 2. if RI is contradict with spec, and RI is not logical(sometimes it is very obvious, you know what I mean), we comply with RI; else, we discuss it case by case. 3. if spec is not so clear, we should comply with RI 4. if some application failing on that different behavior, we discuss it case by case 5. Log every difference from either the spec or the RI in JIRA. Absolutely agree. [snip] Actually, I think that Sun does have an internal group which does exactly that. I've heard some great stories about the raging fights that have erupted internally due to this process... We'll get to have our great fights here :) :-) -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Gerry Steele wrote: It might also be worth nothing that if you are licensed to use the tck, there is an appeal process, so it may be possible to make sun accept deviation from the spec or unreasonable claims in the spec, on their part, on a case by case basis. Sure, but that's a different issue. We've experienced that w/ J2EE, and it was generally a reasonable and decent process. However, in the end, it will be all about users running applications. But i suppose the real test is how well it runs existing applications. If a user finds it more difficult to run their app than with the Sun JVM, then they simply wont use it. Yes! Also, has much thought been given to the GUI components of the spec? Can harmony/classpath replicate a compatible system with regards to the current line of development? That's the goal. Of course, if Sun happened to donate an implementation , we'd be better off :) geir On 2/20/06, Anton Avtamonov [EMAIL PROTECTED] wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Anton still no answer to: What is the goal of that firm spec compatibility? Are you sure that if some usage scenario does not make sense for you and for all progressive people in the world then there no application working this way? Think of the following: we release Harmony, people will try their apps and find out that they do not work. What will the people do? Absolutely agree with the concern above. I mean that some of ther potential users just stop using Harmony and get something which 'properly' works. However I believe: 1. We will test Harmony on many applications and will be able to identify the major part of the potential problems 2. People will send us bug report in the same manner they do for Sun's implementation. I completely agree that we must be very careful decising what is bug and what is not (actually, it was my original post :-) ). I just added that we should try to be spec-compatible when possible. Particulary talking about exceptions: I hope that there should not be too many applications which are relevant to what kind of RuntimeException JRE produces (NPE or IllegalArgumentException) in those cases when Sun's impl doesn't satisfy its spec. Therefore to be spec-compatible here should not cause a problem. [snip] Sure, we do not have to copy obvious bugs like SIGSEGVs, but we still have to carefully work with all the cases when we can potentially break existing applications. +2 (with both hands :-) ) -- Anton Avtamonov, Intel Middleware Products Division -- Gerry Steele http://gerry-steele.blogspot.com/
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
2006/2/27, Geir Magnusson Jr [EMAIL PROTECTED]: Mikhail Loenko wrote: How will we verify Harmony with all existing apps in the world? Gump :) Why should we cross fingers and believe that most of the users do not have such apps rather then make it compatible with RI and be [almost] sure that all apps working on RI will work on Harmony? I'm confused. Isn't that one of our principles? On a case by case basis, examine our deviance from RI or spec, but lean towards making compatible with RI? As I understood people in this and similar threads tend to be compatible with the Spec rather then with RI (unless we prove that being incompatible with RI breaks some existing implementation) I'm trying to oppose that, I'd to be compatible with RI when in doubt. Thanks, Mikhail geir Thanks, Mikhail On 2/20/06, Tim Ellison [EMAIL PROTECTED] wrote: I agree Anton, these are the right guiding principles and the proof will be in running apps. Regards, Tim Anton Avtamonov wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Well seems like we all agree with the general approach. Yes. Agree. But... :) I do not agree with the specific case you describe: NPE vs. IAE. I can imagine a programmer who does not read the spec, who does not want to check for null, who just makes 'catch NPE' somewhere Mikhail, I definitely can imagine the same story. I only want to have such application first. Then we will be able to judge and decide what to do. Before that no need to deviate from spec (of cource, excepting the cases when spec itself contains bugs as in my example with GrayFilter when required exception is missed from spec). In your example, such 'professional' developer most likely catches just Exception rather then the particular one :-) And his app would work well on RI and fail with uncaught IAE on Harmony if we follow the spec. So, what is the reason in this very specific case to firmly follow the spec? Because NPE (IMHO) is not well-defined way to inform the developer something is wrong with his/her code. It just shows 'something inside implementation' fails (excluding cases when NPE contains proper message and is thrown intentively). In opposite, IAE always shows programmer called the method with wrong input values. All is about better notation only. In case existing program specified percentage outside the reasonable range, for instance, and worked anyway it may be even better to clearly inform the developer something is wrong with the program. Because in reality there were no garantee that such incorrect code worked properly on Sun's impl: just a play of chance. Of course we should not add more exceptions than exist in code/spec (at least for now), but try to use 'proper' exceptions with better notation clear for the developers. I propose to continue this discussion when we have real examples, i.e. real applications failed because of such differences or particular methods which can potentially fail applications... Otherwise the discussion is quite abstract... Just IMHO. -- Anton Avtamonov, Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/27/06, Mikhail Loenko [EMAIL PROTECTED] wrote: As I understood people in this and similar threads tend to be compatible with the Spec rather then with RI (unless we prove that being incompatible with RI breaks some existing implementation) I'm trying to oppose that, I'd to be compatible with RI when in doubt. Well, actually you are right. I disagree just to simply copy all the existing bugs... And as I rememeber I'm not along :-). The main idea is to follow the guidelines Paulex proposed, i.e. to be reasonable. Lemme remember Paulex's rules: 1. we should comply with spec 2. if RI is contradict with spec, and RI is not logical(sometimes it is very obvious, you know what I mean), we comply with RI; else, we discuss it case by case. 3. if spec is not so clear, we should comply with RI 4. if some application failing on that different behavior, we discuss it case by case I believe this approach will give better results: keepping us compatible with the existing applications and provide more consistent implementation where possible. Note that according to the rules above we are not mandatory follow to the spec. Btw, releasing new JDK SUN updates some existing methods, sometimes changing not only internal implementation, but even some behavior. I suppose they don't run all existing applications to make sure nothing is broken :-). I don't know how this process is organized, however I would expect some kind of CCB (Change Control Board) which decide if it's safe change or not. I suppose our mailing list can act in a very similar manner. -- Anton Avtamonov, Intel Middleware Products Division
Re: newbie to project-where to start from
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 [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
On 2/22/06, Tim Ellison [EMAIL PROTECTED] 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: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: What is the goal of spec-compatibility for exceptions? 1. Existing applications that work well on Sun's Java might fail on Harmony. Right - this is a problem. People will say that we're broken. It's not a easy conversation to have with users who don't care about license, just want a good JRE to work with, so then delete our implementation. Sounds reasonable. However I hope the expected deviations for Sun's impl (if we talk about exceptions) should not be so dramatic... I hope we will be basing on both spec, impl behavior and common sense. For instance, there is javax.swing.GrayFilter class which constructor takes 'percentage of gray' parameter (a value in a [0-100] range). Spec doesn't state there should be IllegalArgumentException if the value is out of range, but both Sun's impl and common sense tell us it should be. Another case is if spec states IllegalArgumentException, but impl produces NPE... I don't believe there are applications which are really care about the particular kind of RuntimeException :-). So in this case I would follow the spec. Really, IllegalArgumentException is always a guard statement for definitely wrong usage of API (like setting percentage out of [0-100] range). Not too many people should break such 'common sense' idea. Besides, I hope we will have not too many places when Sun's impl and spec differ. 2. Sun, once it discovers the bug, will most likely change the spec rather then impl, and we will have to return and fix our code Well, I don't really know if Sun would do that. There is an expert group that Sun has to deal with... I think we should try to be spec-compatible when possible. If the spec is changed - we will change the implementation. Actually, for the time being I don't know any applications which are broken because of using IllegalArgumentException instead of NPE or vise versa. Let's see if we have such and then decide. Before that, spec-compatibility looks more preferrable for me... -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/19/06, karan malhi [EMAIL PROTECTED] wrote: Geir Magnusson Jr wrote: Well, I don't really know if Sun would do that. There is an expert group that Sun has to deal with... But if it did happen, yes, we'd have to fix our code. I agree. Whatever experience I've had with java till now, I have found that Sun mainly deprecates a method and provides a replacement, instead of changing the spec for that method after the spec has been released. So, if Sun decides to deprecate a method, it will still not break harmony. I still feel our code should be spec compatible and not bug compatible with Sun's impl. As a developer, I would look at the API docs and then write the code. So, if our impl is compatible with the API docs, won't that make a case for using harmony instead of a buggy impl :) Yeah! Very optimistic! I agree :-) In practical terms developers hate when spec contradicts to the real behavior so for the developers of the new applications it would be fantastic to have such implementation. However we have to run all existing applications first, and, therefore, have to be as closer to Sun's impl as possible... If I got it right we decided to discuss all not-trivial cases and I believe that is right approach. -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Anton
still no answer to: What is the goal of that firm spec compatibility?
Are you sure that if some usage scenario does not make sense for you
and for all progressive people in the world then there no application working
this way?
Think of the following: we release Harmony, people will try their apps
and find out
that they do not work. What will the people do?
I cannot recall an example, but when we were developing classes we have found
that the spec was changed from 1.4 to 1.5 to reflect existing
('buggy') behavior.
Sure, we do not have to copy obvious bugs like SIGSEGVs, but we still have to
carefully work with all the cases when we can potentially break existing
applications.
Thanks,
Mikhail
On 2/20/06, Anton Avtamonov [EMAIL PROTECTED] wrote:
On 2/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mikhail Loenko wrote:
What is the goal of spec-compatibility for exceptions?
1. Existing applications that work well on Sun's Java might fail on
Harmony.
Right - this is a problem. People will say that we're broken. It's not
a easy conversation to have with users who don't care about license,
just want a good JRE to work with, so then delete our implementation.
Sounds reasonable.
However I hope the expected deviations for Sun's impl (if we talk
about exceptions) should not be so dramatic... I hope we will be
basing on both spec, impl behavior and common sense.
For instance, there is javax.swing.GrayFilter class which constructor
takes 'percentage of gray' parameter (a value in a [0-100] range).
Spec doesn't state there should be IllegalArgumentException if the
value is out of range, but both Sun's impl and common sense tell us it
should be.
Another case is if spec states IllegalArgumentException, but impl
produces NPE... I don't believe there are applications which are
really care about the particular kind of RuntimeException :-). So in
this case I would follow the spec.
Really, IllegalArgumentException is always a guard statement for
definitely wrong usage of API (like setting percentage out of [0-100]
range). Not too many people should break such 'common sense' idea.
Besides, I hope we will have not too many places when Sun's impl and
spec differ.
2. Sun, once it discovers the bug, will most likely change the spec
rather then impl,
and we will have to return and fix our code
Well, I don't really know if Sun would do that. There is an expert
group that Sun has to deal with...
I think we should try to be spec-compatible when possible. If the spec
is changed - we will change the implementation.
Actually, for the time being I don't know any applications which are
broken because of using IllegalArgumentException instead of NPE or
vise versa. Let's see if we have such and then decide. Before that,
spec-compatibility looks more preferrable for me...
--
Anton Avtamonov,
Intel Middleware Products Division
Re: newbie to project-where to start from
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 [EMAIL PROTECTED] 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: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Anton still no answer to: What is the goal of that firm spec compatibility? Are you sure that if some usage scenario does not make sense for you and for all progressive people in the world then there no application working this way? Think of the following: we release Harmony, people will try their apps and find out that they do not work. What will the people do? Absolutely agree with the concern above. I mean that some of ther potential users just stop using Harmony and get something which 'properly' works. However I believe: 1. We will test Harmony on many applications and will be able to identify the major part of the potential problems 2. People will send us bug report in the same manner they do for Sun's implementation. I completely agree that we must be very careful decising what is bug and what is not (actually, it was my original post :-) ). I just added that we should try to be spec-compatible when possible. Particulary talking about exceptions: I hope that there should not be too many applications which are relevant to what kind of RuntimeException JRE produces (NPE or IllegalArgumentException) in those cases when Sun's impl doesn't satisfy its spec. Therefore to be spec-compatible here should not cause a problem. [snip] Sure, we do not have to copy obvious bugs like SIGSEGVs, but we still have to carefully work with all the cases when we can potentially break existing applications. +2 (with both hands :-) ) -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Well seems like we all agree with the general approach. But... :) I do not agree with the specific case you describe: NPE vs. IAE. I can imagine a programmer who does not read the spec, who does not want to check for null, who just makes 'catch NPE' somewhere And his app would work well on RI and fail with uncaught IAE on Harmony if we follow the spec. So, what is the reason in this very specific case to firmly follow the spec? Thanks, Mikhail On 2/20/06, Anton Avtamonov [EMAIL PROTECTED] wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Anton still no answer to: What is the goal of that firm spec compatibility? Are you sure that if some usage scenario does not make sense for you and for all progressive people in the world then there no application working this way? Think of the following: we release Harmony, people will try their apps and find out that they do not work. What will the people do? Absolutely agree with the concern above. I mean that some of ther potential users just stop using Harmony and get something which 'properly' works. However I believe: 1. We will test Harmony on many applications and will be able to identify the major part of the potential problems 2. People will send us bug report in the same manner they do for Sun's implementation. I completely agree that we must be very careful decising what is bug and what is not (actually, it was my original post :-) ). I just added that we should try to be spec-compatible when possible. Particulary talking about exceptions: I hope that there should not be too many applications which are relevant to what kind of RuntimeException JRE produces (NPE or IllegalArgumentException) in those cases when Sun's impl doesn't satisfy its spec. Therefore to be spec-compatible here should not cause a problem. [snip] Sure, we do not have to copy obvious bugs like SIGSEGVs, but we still have to carefully work with all the cases when we can potentially break existing applications. +2 (with both hands :-) ) -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
It might also be worth nothing that if you are licensed to use the tck, there is an appeal process, so it may be possible to make sun accept deviation from the spec or unreasonable claims in the spec, on their part, on a case by case basis. But i suppose the real test is how well it runs existing applications. If a user finds it more difficult to run their app than with the Sun JVM, then they simply wont use it. Also, has much thought been given to the GUI components of the spec? Can harmony/classpath replicate a compatible system with regards to the current line of development? On 2/20/06, Anton Avtamonov [EMAIL PROTECTED] wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Anton still no answer to: What is the goal of that firm spec compatibility? Are you sure that if some usage scenario does not make sense for you and for all progressive people in the world then there no application working this way? Think of the following: we release Harmony, people will try their apps and find out that they do not work. What will the people do? Absolutely agree with the concern above. I mean that some of ther potential users just stop using Harmony and get something which 'properly' works. However I believe: 1. We will test Harmony on many applications and will be able to identify the major part of the potential problems 2. People will send us bug report in the same manner they do for Sun's implementation. I completely agree that we must be very careful decising what is bug and what is not (actually, it was my original post :-) ). I just added that we should try to be spec-compatible when possible. Particulary talking about exceptions: I hope that there should not be too many applications which are relevant to what kind of RuntimeException JRE produces (NPE or IllegalArgumentException) in those cases when Sun's impl doesn't satisfy its spec. Therefore to be spec-compatible here should not cause a problem. [snip] Sure, we do not have to copy obvious bugs like SIGSEGVs, but we still have to carefully work with all the cases when we can potentially break existing applications. +2 (with both hands :-) ) -- Anton Avtamonov, Intel Middleware Products Division -- Gerry Steele http://gerry-steele.blogspot.com/
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Well seems like we all agree with the general approach. Yes. Agree. But... :) I do not agree with the specific case you describe: NPE vs. IAE. I can imagine a programmer who does not read the spec, who does not want to check for null, who just makes 'catch NPE' somewhere Mikhail, I definitely can imagine the same story. I only want to have such application first. Then we will be able to judge and decide what to do. Before that no need to deviate from spec (of cource, excepting the cases when spec itself contains bugs as in my example with GrayFilter when required exception is missed from spec). In your example, such 'professional' developer most likely catches just Exception rather then the particular one :-) And his app would work well on RI and fail with uncaught IAE on Harmony if we follow the spec. So, what is the reason in this very specific case to firmly follow the spec? Because NPE (IMHO) is not well-defined way to inform the developer something is wrong with his/her code. It just shows 'something inside implementation' fails (excluding cases when NPE contains proper message and is thrown intentively). In opposite, IAE always shows programmer called the method with wrong input values. All is about better notation only. In case existing program specified percentage outside the reasonable range, for instance, and worked anyway it may be even better to clearly inform the developer something is wrong with the program. Because in reality there were no garantee that such incorrect code worked properly on Sun's impl: just a play of chance. Of course we should not add more exceptions than exist in code/spec (at least for now), but try to use 'proper' exceptions with better notation clear for the developers. I propose to continue this discussion when we have real examples, i.e. real applications failed because of such differences or particular methods which can potentially fail applications... Otherwise the discussion is quite abstract... Just IMHO. -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/20/06, Gerry Steele [EMAIL PROTECTED] wrote: It might also be worth nothing that if you are licensed to use the tck, there is an appeal process, so it may be possible to make sun accept deviation from the spec or unreasonable claims in the spec, on their part, on a case by case basis. But i suppose the real test is how well it runs existing applications. If a user finds it more difficult to run their app than with the Sun JVM, then they simply wont use it. In general, of course. If I ran my application and found all the buttons are in the mess on the wrong places, scrollers don't scroll, etc... Yeah, most likely I just stop trying. In the other hand, if I have one exception with adequate message which I recognize as a problem in my code... I just say 'great thanks' to those who helped me to find it :-) Again, it should not be hundreds of exceptions! It may be 1 exception per 100 applications... Something like that... Otherwise we will identify the problem when testing and decide what to do. Sorry if I very optimistic :-) Probably we can have some place where everyone will be able to record identified deviations? I'm not sure that is really makes sense 'cause I can't imagine how to handle such list for the practical value. Obviously all serious deviations have to be discussed here. -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
I agree Anton, these are the right guiding principles and the proof will be in running apps. Regards, Tim Anton Avtamonov wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Well seems like we all agree with the general approach. Yes. Agree. But... :) I do not agree with the specific case you describe: NPE vs. IAE. I can imagine a programmer who does not read the spec, who does not want to check for null, who just makes 'catch NPE' somewhere Mikhail, I definitely can imagine the same story. I only want to have such application first. Then we will be able to judge and decide what to do. Before that no need to deviate from spec (of cource, excepting the cases when spec itself contains bugs as in my example with GrayFilter when required exception is missed from spec). In your example, such 'professional' developer most likely catches just Exception rather then the particular one :-) And his app would work well on RI and fail with uncaught IAE on Harmony if we follow the spec. So, what is the reason in this very specific case to firmly follow the spec? Because NPE (IMHO) is not well-defined way to inform the developer something is wrong with his/her code. It just shows 'something inside implementation' fails (excluding cases when NPE contains proper message and is thrown intentively). In opposite, IAE always shows programmer called the method with wrong input values. All is about better notation only. In case existing program specified percentage outside the reasonable range, for instance, and worked anyway it may be even better to clearly inform the developer something is wrong with the program. Because in reality there were no garantee that such incorrect code worked properly on Sun's impl: just a play of chance. Of course we should not add more exceptions than exist in code/spec (at least for now), but try to use 'proper' exceptions with better notation clear for the developers. I propose to continue this discussion when we have real examples, i.e. real applications failed because of such differences or particular methods which can potentially fail applications... Otherwise the discussion is quite abstract... Just IMHO. -- Anton Avtamonov, Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/20/06, Anton Avtamonov [EMAIL PROTECTED] wrote: On 2/20/06, Gerry Steele [EMAIL PROTECTED] wrote: It might also be worth nothing that if you are licensed to use the tck, there is an appeal process, so it may be possible to make sun accept deviation from the spec or unreasonable claims in the spec, on their part, on a case by case basis. But i suppose the real test is how well it runs existing applications. If a user finds it more difficult to run their app than with the Sun JVM, then they simply wont use it. In general, of course. If I ran my application and found all the buttons are in the mess on the wrong places, scrollers don't scroll, etc... Yeah, most likely I just stop trying. In the other hand, if I have one exception with adequate message which I recognize as a If you are a user, not a developer that message would not help you. You will not care whether the bug is in the app or in the Harmony. The only thing that you'll see is it worked on RI and does not work on Harmony. Thanks, Mikhail problem in my code... I just say 'great thanks' to those who helped me to find it :-) Again, it should not be hundreds of exceptions! It may be 1 exception per 100 applications... Something like that... Otherwise we will identify the problem when testing and decide what to do. Sorry if I very optimistic :-) Probably we can have some place where everyone will be able to record identified deviations? I'm not sure that is really makes sense 'cause I can't imagine how to handle such list for the practical value. Obviously all serious deviations have to be discussed here. -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: How will we verify Harmony with all existing apps in the world? Certainly there is no way to verify Harmony with all existing apps ourselves. But, it looks like we do have a bug reporting system which would allow Harmony users to let us know about possible binary incompatibilities with RI (which might be critical for them for some reason). We could consider and fix (or not fix) such incompatibilities on a case-by-case basis, depending on the importance of a particular application. Gerry did an excellent note earlier in this thread that there is an appeal process which can help to fix the spec/RI inconsistencies. In particular, it would address the issue when RI doesn't conform to the spec for some reason while the variety of apps are already dependent on a wrongly thrown exception. Thank you, Andrey Chernyshev Intel Middleware Products Division Why should we cross fingers and believe that most of the users do not have such apps rather then make it compatible with RI and be [almost] sure that all apps working on RI will work on Harmony? Thanks, Mikhail On 2/20/06, Tim Ellison [EMAIL PROTECTED] wrote: I agree Anton, these are the right guiding principles and the proof will be in running apps. Regards, Tim Anton Avtamonov wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Well seems like we all agree with the general approach. Yes. Agree. But... :) I do not agree with the specific case you describe: NPE vs. IAE. I can imagine a programmer who does not read the spec, who does not want to check for null, who just makes 'catch NPE' somewhere Mikhail, I definitely can imagine the same story. I only want to have such application first. Then we will be able to judge and decide what to do. Before that no need to deviate from spec (of cource, excepting the cases when spec itself contains bugs as in my example with GrayFilter when required exception is missed from spec). In your example, such 'professional' developer most likely catches just Exception rather then the particular one :-) And his app would work well on RI and fail with uncaught IAE on Harmony if we follow the spec. So, what is the reason in this very specific case to firmly follow the spec? Because NPE (IMHO) is not well-defined way to inform the developer something is wrong with his/her code. It just shows 'something inside implementation' fails (excluding cases when NPE contains proper message and is thrown intentively). In opposite, IAE always shows programmer called the method with wrong input values. All is about better notation only. In case existing program specified percentage outside the reasonable range, for instance, and worked anyway it may be even better to clearly inform the developer something is wrong with the program. Because in reality there were no garantee that such incorrect code worked properly on Sun's impl: just a play of chance. Of course we should not add more exceptions than exist in code/spec (at least for now), but try to use 'proper' exceptions with better notation clear for the developers. I propose to continue this discussion when we have real examples, i.e. real applications failed because of such differences or particular methods which can potentially fail applications... Otherwise the discussion is quite abstract... Just IMHO. -- Anton Avtamonov, Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
I would support Mikhail. If we are aware of bug in RI there might be a few cases. First, we suppose we're really better than RI not having this bug. The second one is the case being discussed. When it basically does not matter that much but we're considering being either spec or bug compatible. In this case if we think it might be used in the applications why not to implement it and create regression tests for this specific feature? Following this rule: - We would support compatibility with RI. People should not think about which implementation their application would start. - We would be able to track changes in RI in order to continue being compatible. My thinking is we would not rely on the scenario when the customer would submit a bug to JIRA if he faced to the incompatibility. Most lilely he would not submit anything and just stop using Harmony. Thank you, Alex Orlov Intel Middleware Products Division On 2/20/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: How will we verify Harmony with all existing apps in the world? Certainly there is no way to verify Harmony with all existing apps ourselves. But, it looks like we do have a bug reporting system which would allow Harmony users to let us know about possible binary incompatibilities with RI (which might be critical for them for some reason). We could consider and fix (or not fix) such incompatibilities on a case-by-case basis, depending on the importance of a particular application. Gerry did an excellent note earlier in this thread that there is an appeal process which can help to fix the spec/RI inconsistencies. In particular, it would address the issue when RI doesn't conform to the spec for some reason while the variety of apps are already dependent on a wrongly thrown exception. Thank you, Andrey Chernyshev Intel Middleware Products Division Why should we cross fingers and believe that most of the users do not have such apps rather then make it compatible with RI and be [almost] sure that all apps working on RI will work on Harmony? Thanks, Mikhail On 2/20/06, Tim Ellison [EMAIL PROTECTED] wrote: I agree Anton, these are the right guiding principles and the proof will be in running apps. Regards, Tim Anton Avtamonov wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Well seems like we all agree with the general approach. Yes. Agree. But... :) I do not agree with the specific case you describe: NPE vs. IAE. I can imagine a programmer who does not read the spec, who does not want to check for null, who just makes 'catch NPE' somewhere Mikhail, I definitely can imagine the same story. I only want to have such application first. Then we will be able to judge and decide what to do. Before that no need to deviate from spec (of cource, excepting the cases when spec itself contains bugs as in my example with GrayFilter when required exception is missed from spec). In your example, such 'professional' developer most likely catches just Exception rather then the particular one :-) And his app would work well on RI and fail with uncaught IAE on Harmony if we follow the spec. So, what is the reason in this very specific case to firmly follow the spec? Because NPE (IMHO) is not well-defined way to inform the developer something is wrong with his/her code. It just shows 'something inside implementation' fails (excluding cases when NPE contains proper message and is thrown intentively). In opposite, IAE always shows programmer called the method with wrong input values. All is about better notation only. In case existing program specified percentage outside the reasonable range, for instance, and worked anyway it may be even better to clearly inform the developer something is wrong with the program. Because in reality there were no garantee that such incorrect code worked properly on Sun's impl: just a play of chance. Of course we should not add more exceptions than exist in code/spec (at least for now), but try to use 'proper' exceptions with better notation clear for the developers. I propose to continue this discussion when we have real examples, i.e. real applications failed because of such differences or particular methods which can potentially fail applications... Otherwise the discussion is quite abstract... Just IMHO. -- Anton Avtamonov, Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
In my opinion we should not wait when Harmony users let us know about our incompatibility. We need to hurry and to eliminate this as soon as possible. Otherwise we will not be successful. All existent (well-known) applications have been already tuned for RI. Therefore we also need to carry for the compatibility if we wish to run these applications. First thing would like to mention once more about is TCK. If we will have a license for it we can resolve a lot of our problem on early stage project. Is it reasonable to think about this? Is it possible to have this license for Harmony? Or is it unrealizable thing? *Thank you.* *--* *Vladimir Gorr* Intel Middleware Products Division. On 2/20/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: How will we verify Harmony with all existing apps in the world? Certainly there is no way to verify Harmony with all existing apps ourselves. But, it looks like we do have a bug reporting system which would allow Harmony users to let us know about possible binary incompatibilities with RI (which might be critical for them for some reason). We could consider and fix (or not fix) such incompatibilities on a case-by-case basis, depending on the importance of a particular application. Gerry did an excellent note earlier in this thread that there is an appeal process which can help to fix the spec/RI inconsistencies. In particular, it would address the issue when RI doesn't conform to the spec for some reason while the variety of apps are already dependent on a wrongly thrown exception. Thank you, Andrey Chernyshev Intel Middleware Products Division Why should we cross fingers and believe that most of the users do not have such apps rather then make it compatible with RI and be [almost] sure that all apps working on RI will work on Harmony? Thanks, Mikhail On 2/20/06, Tim Ellison [EMAIL PROTECTED] wrote: I agree Anton, these are the right guiding principles and the proof will be in running apps. Regards, Tim Anton Avtamonov wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Well seems like we all agree with the general approach. Yes. Agree. But... :) I do not agree with the specific case you describe: NPE vs. IAE. I can imagine a programmer who does not read the spec, who does not want to check for null, who just makes 'catch NPE' somewhere Mikhail, I definitely can imagine the same story. I only want to have such application first. Then we will be able to judge and decide what to do. Before that no need to deviate from spec (of cource, excepting the cases when spec itself contains bugs as in my example with GrayFilter when required exception is missed from spec). In your example, such 'professional' developer most likely catches just Exception rather then the particular one :-) And his app would work well on RI and fail with uncaught IAE on Harmony if we follow the spec. So, what is the reason in this very specific case to firmly follow the spec? Because NPE (IMHO) is not well-defined way to inform the developer something is wrong with his/her code. It just shows 'something inside implementation' fails (excluding cases when NPE contains proper message and is thrown intentively). In opposite, IAE always shows programmer called the method with wrong input values. All is about better notation only. In case existing program specified percentage outside the reasonable range, for instance, and worked anyway it may be even better to clearly inform the developer something is wrong with the program. Because in reality there were no garantee that such incorrect code worked properly on Sun's impl: just a play of chance. Of course we should not add more exceptions than exist in code/spec (at least for now), but try to use 'proper' exceptions with better notation clear for the developers. I propose to continue this discussion when we have real examples, i.e. real applications failed because of such differences or particular methods which can potentially fail applications... Otherwise the discussion is quite abstract... Just IMHO. -- Anton Avtamonov, Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
I need to read the whole thread (will do it on plane tomorrow) but just a couple of quick notes... Vladimir Gorr wrote: In my opinion we should not wait when Harmony users let us know about our incompatibility. We need to hurry and to eliminate this as soon as possible. Otherwise we will not be successful. All existent (well-known) applications have been already tuned for RI. Therefore we also need to carry for the compatibility if we wish to run these applications. First thing would like to mention once more about is TCK. If we will have a license We will have a license at some point. for it we can resolve a lot of our problem on early stage project. Is it reasonable to think about this? Is it possible to have this license for Harmony? Or is it unrealizable thing? Nope, that's very realistic. We're doing a compatible implementation, and we'll need the TCK. I foresee few problems getting a TCK :) geir *Thank you.* *--* *Vladimir Gorr* Intel Middleware Products Division. On 2/20/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: How will we verify Harmony with all existing apps in the world? Certainly there is no way to verify Harmony with all existing apps ourselves. But, it looks like we do have a bug reporting system which would allow Harmony users to let us know about possible binary incompatibilities with RI (which might be critical for them for some reason). We could consider and fix (or not fix) such incompatibilities on a case-by-case basis, depending on the importance of a particular application. Gerry did an excellent note earlier in this thread that there is an appeal process which can help to fix the spec/RI inconsistencies. In particular, it would address the issue when RI doesn't conform to the spec for some reason while the variety of apps are already dependent on a wrongly thrown exception. Thank you, Andrey Chernyshev Intel Middleware Products Division Why should we cross fingers and believe that most of the users do not have such apps rather then make it compatible with RI and be [almost] sure that all apps working on RI will work on Harmony? Thanks, Mikhail On 2/20/06, Tim Ellison [EMAIL PROTECTED] wrote: I agree Anton, these are the right guiding principles and the proof will be in running apps. Regards, Tim Anton Avtamonov wrote: On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Well seems like we all agree with the general approach. Yes. Agree. But... :) I do not agree with the specific case you describe: NPE vs. IAE. I can imagine a programmer who does not read the spec, who does not want to check for null, who just makes 'catch NPE' somewhere Mikhail, I definitely can imagine the same story. I only want to have such application first. Then we will be able to judge and decide what to do. Before that no need to deviate from spec (of cource, excepting the cases when spec itself contains bugs as in my example with GrayFilter when required exception is missed from spec). In your example, such 'professional' developer most likely catches just Exception rather then the particular one :-) And his app would work well on RI and fail with uncaught IAE on Harmony if we follow the spec. So, what is the reason in this very specific case to firmly follow the spec? Because NPE (IMHO) is not well-defined way to inform the developer something is wrong with his/her code. It just shows 'something inside implementation' fails (excluding cases when NPE contains proper message and is thrown intentively). In opposite, IAE always shows programmer called the method with wrong input values. All is about better notation only. In case existing program specified percentage outside the reasonable range, for instance, and worked anyway it may be even better to clearly inform the developer something is wrong with the program. Because in reality there were no garantee that such incorrect code worked properly on Sun's impl: just a play of chance. Of course we should not add more exceptions than exist in code/spec (at least for now), but try to use 'proper' exceptions with better notation clear for the developers. I propose to continue this discussion when we have real examples, i.e. real applications failed because of such differences or particular methods which can potentially fail applications... Otherwise the discussion is quite abstract... Just IMHO. -- Anton Avtamonov, Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
What is the goal of spec-compatibility for exceptions? 1. Existing applications that work well on Sun's Java might fail on Harmony. 2. Sun, once it discovers the bug, will most likely change the spec rather then impl, and we will have to return and fix our code Thanks, Mikhail On 2/17/06, karan malhi [EMAIL PROTECTED] wrote: Anton Avtamonov wrote: IMHO, when spec states some exception we should be spec-compatible. +1 On 2/17/06, Mikhail Loenko [EMAIL PROTECTED] 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: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Mikhail Loenko wrote: What is the goal of spec-compatibility for exceptions? 1. Existing applications that work well on Sun's Java might fail on Harmony. Right - this is a problem. People will say that we're broken. It's not a easy conversation to have with users who don't care about license, just want a good JRE to work with, so then delete our implementation. 2. Sun, once it discovers the bug, will most likely change the spec rather then impl, and we will have to return and fix our code Well, I don't really know if Sun would do that. There is an expert group that Sun has to deal with... But if it did happen, yes, we'd have to fix our code. geir Thanks, Mikhail On 2/17/06, karan malhi [EMAIL PROTECTED] wrote: Anton Avtamonov wrote: IMHO, when spec states some exception we should be spec-compatible. +1 On 2/17/06, Mikhail Loenko [EMAIL PROTECTED] 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: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Geir Magnusson Jr wrote: Well, I don't really know if Sun would do that. There is an expert group that Sun has to deal with... But if it did happen, yes, we'd have to fix our code. I agree. Whatever experience I've had with java till now, I have found that Sun mainly deprecates a method and provides a replacement, instead of changing the spec for that method after the spec has been released. So, if Sun decides to deprecate a method, it will still not break harmony. I still feel our code should be spec compatible and not bug compatible with Sun's impl. As a developer, I would look at the API docs and then write the code. So, if our impl is compatible with the API docs, won't that make a case for using harmony instead of a buggy impl :) Thanks, Mikhail On 2/17/06, karan malhi [EMAIL PROTECTED] wrote: Anton Avtamonov wrote: IMHO, when spec states some exception we should be spec-compatible. +1 On 2/17/06, Mikhail Loenko [EMAIL PROTECTED] 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 -- Karan Singh
Re: newbie to project-where to start from
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 [EMAIL PROTECTED] wrote: 2006/2/16, Tim Ellison [EMAIL PROTECTED]: 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: 2006/2/16, Tim Ellison [EMAIL PROTECTED]: 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: 2006/2/16, Tim Ellison [EMAIL PROTECTED]: 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
On 2/17/06, Mikhail Loenko [EMAIL PROTECTED] 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
Anton Avtamonov wrote: IMHO, when spec states some exception we should be spec-compatible. +1 On 2/17/06, Mikhail Loenko [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: 2006/2/16, Tim Ellison [EMAIL PROTECTED]: 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
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
--- James Pluck [EMAIL PROTECTED] 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
Matt Benson wrote: --- James Pluck [EMAIL PROTECTED] 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
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
old faithful (was: Re: newbie to project-where to start from)
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.typeTest.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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
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.typeTest.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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
2006/2/16, Tim Ellison [EMAIL PROTECTED]: 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
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
Alexey Petrenko wrote: 2006/2/16, Tim Ellison [EMAIL PROTECTED]: 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
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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
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
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
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.typeTest.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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
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
JCSC is a Java Coding Standard Checker - ie, just conformance, not coverage. There's a good list of code coverage tools at http://java-source.net/open-source/code-coverage. Matt -Original Message- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Thursday, 16 February 2006 4:00 PM To: harmony-dev@incubator.apache.org Subject: Re: newbie to project-where to start from 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 [EMAIL PROTECTED] 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.t ypeTest.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/InetAddressT est.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
I mixed with Emma - both of them of 4 chars :) http://emma.sourceforge.net Mikhail On 2/16/06, Matthew Johnson [EMAIL PROTECTED] wrote: JCSC is a Java Coding Standard Checker - ie, just conformance, not coverage. There's a good list of code coverage tools at http://java-source.net/open-source/code-coverage. Matt -Original Message- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Thursday, 16 February 2006 4:00 PM To: harmony-dev@incubator.apache.org Subject: Re: newbie to project-where to start from 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 [EMAIL PROTECTED] 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.t ypeTest.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/InetAddressT est.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
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.typeTest.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
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
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/
