[kaffe] Bug in FileInputStream

Jukka Santala jsantala@tml.hut.fi
Fri, 14 Jun 2002 12:38:31 +0300 (EEST)


On Mon, 10 Jun 2002, Dalibor Topic wrote:
> Unless of course you are using reflection to lookup
> the constructor that throws IOException. But
> reflection is not part of JDK 1.1, so no self
> respecting JDK 1.1 app should be using it ;)

It is not? Certainly it's part of the JDK 1.1 API spec
http://java.sun.com/products/jdk/1.1/docs/api/java.lang.reflect.Constructor.html#getExceptionTypes() 
, and no JDK1.1 implementation I've seen seems to have trouble with it.
But again, this is a rather far-fetched case, and one which programs
should probably take into account themselves.

I can't think of any practical situations where this particular change
would make a difference, but I was basically just nit-picking that an API
spec change doesn't autoamtically make all implementations of the older
API "buggy". In other cases, such as JDK 1.4's AppletContext or assert()
changes these API modifications clearly break compatibility, and it'd be a
shame for all embedded environment interests to see such changes passed
through as "bugfixes" without any checks.

On the other hand there doesn't really exist a mechanism to do anything
about these kinds of things right now; is the effort to support
alternative JDK version/classlib/profile setups collectively considered
too much effort to be worth it? I think this, again, would be a shame
because Kaffe is missing so much from Java2 that using it on Java2
applications is not generally possible. So for most applications J2ME or
full-blown J2RE would then ebcome the only alternatives.

Not that I'm suggesting a general block on API upgrades etc.; usually
these are a good thing, and it's obivious eventually Kaffe needs to move
further and further towards Java2 if it wishes to survive. That's why the
different profiles were suggested. But implementations conforming to "old
standards" aren't "bugs".

> I don't think bug tracking systems work that well for
> small projects like this (<10 active developers) which
> are getting a low number of bug reports (< 10 per
> week). They are great when you are getting a lot of

I agree in general, that's alogn the lines that I suggested a rigid patch
check-in policy isn't neccessary. But once 1.0.7 is out, _hopefully_ the
developer (Or at least user/tester) base is going to grow significantly.
Keeping up with te influx may be hard then; but perhaps we can just wait
and see for now.

 -Jukka Santala