harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeroen Frijters" <jer...@sumatra.nl>
Subject RE: [general] compatibility packages
Date Sat, 12 Aug 2006 18:50:42 GMT
Dalibor Topic wrote:
> So if I can't run the sun.misc.Unsafe remote exploit on 
> Harmony it is a failure? ;)

You keep referring to this, but IMO this is a mischaracterization of the
exploit. The exploit used a bug in JavaScript that allowed access to the
sun.* package, that was the real problem not the sun.misc.Unsafe class.

You also keep hammering on CharToByteConverter as an example of bad code
that should trivially be fixed (and it obviously should, if possible,
but it's not always that easy), but there is also code out there that
uses sun.* classes to do things that are impossible to do with the
documented APIs. How would you fix those?

BTW, that was a retorical question, because I already know your answer:
that's rubbish software that won't work reliably on Sun's JRE anyway, so
why should we support it?

However, I've spoken with Mark Reinhold about this issue and he told me
that Sun sometimes reverts changes to sun.* classes because a customer
complains that it broke their code. I asked him if they would be
documenting these classes when they do this, but he said they wouldn't.
So they seem to live in a dream world where on the one hand they want to
discourage usage of sun.* and on the other hand continue to support it.

Like compatibility in general this is a hard problem and we need to take
a pragmatic approach and I really like the current plan of having an
optional suncompat module.


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message