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.
