harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dalibor Topic <robi...@kaffe.org>
Subject Re: [arch] VM/Classlibrary interface
Date Sun, 29 May 2005 11:49:11 GMT
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.

dalibor topic

View raw message