Rodrigo Kumpera wrote:
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.
Developers are not supposed to depend on that exception for correctness of their code. It's just a tool to diagnose deeper problems. See API specification for details.
That being said, of course there are differences in behaviour between different VMs. That is understandable as they use different ways to do things internally, and perfectly fine as long as such behaviour is within the scope of the specifications. If their behaviour is outside the scope of the specifications, than it's a bug in the VM and needs to be fixed.
There may be cases where the specifications are not that great. In such cases, the proper way to fix the problem is to fix the specifications. Or to use third-party software with equivalent features, which can be relied upon at deployment, rather than hoping that some unspecified behaviour is present on all versions of runtimes one wishes to deploy on.
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.
Then it will be fixed when someone realizes that it is broken. That happens all the time when any environment is upgraded, be it free or non-free: buggy software breaks eventually, developers find out about the bugs, it gets fixed, and life goes on.
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.
In that case the specifications need to be fixed. Could you please file a bug at the spec bug tracker?
I am sure that an independant effort like this one can help spot and prevent such mistakes to happen in the future, and that can only be good for the quality of the platform.
cheers, dalibor topic
