On 5/28/05, Dalibor Topic <[EMAIL PROTECTED]> wrote: > Rodrigo Kumpera wrote: > > >>b) an accidental mistake, then you fix the small bug in your code, feel > >>better about the quality of your code, and move on. > > > > > > > > I agree with you about the first one, but the second is where the fine line > > between pragmatic and retoric solutions line. It's easy to say 'just fix it > > then', but I hope that Harmony gets more users that a few hackers. > > I hope so, too. ;) > > Seriously, though, no VM can automatically fix bugs in other people's > code. It would be unreasonable to expect that a VM could be able to > figure out which specific unspecified behaviour from which particular > release of which particular platform to emulate in order to fullfil the > expectations of the buggy code. No VM can read the mind of the developer > of the buggy code, and figure out whether going outside the scope of the > specifications was a deliberate choice or a mistake. On the other hand, > the developer of the broken code probably knows what he wanted to > achieve and can act accordingly. > > There is nothing rhetoric about that: bad code breaks sooner or later. > Then it needs to be fixed. > > Of course, one could throw one's arms up in the air, and shed tears > about the cruelness of a world where bad code can exist. But just fixing > the bad code seems to do work at least equally well in practice. ;) > > > My point is, testing against just the TCK is just not enouth. Testing > > against real applications is where the real value of Harmony can be > > asserted. Most free JVMs already do that and nobody seens to be complaining. > > Nobody is complaining because developers simply fix their bugs and move > on, be they bugs in Kaffe, GNU Classpath, or some application that > doesn't run on them due to some mistake a developer made. > > If you don't think the TCK is good enough for compatiblity, then I am > sure that the respective JSRs would welcome your contributions to > improve what your believe to be a problem. > > cheers, > dalibor topic
There is a long track of incompatibilities between JVMs and most of then are subtle, poor specified behavior. A good example is java.util.ConcurrentModificationException, this exception is thrown in a best-effort way by the Collection classes. This means that JVMs will throw this exception as they see fit. I've seen software that did not depent on this behavior fail because of such problems. Other good example is the bugtracker for Sun's JVM, there are many bugs that differ from specified behavior and there might be software out there that depends on these bugs but never quite realized that. Broken software is a reality and sometimes the cause is the blur line between the spec and the RI. You can even find some public methods somewhere on AWT that takes sun.* classes.
