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/
