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. > > > > > >
