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. Regards, Jeroen --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
