On Wed, 18 Dec 2002, Paul Libbrecht wrote: <snip/>
> I think the issue is simply related to the fact that much (too much?) > of the jakarta development is interested to the server things and too > few to the user-interfaces... I think, however, that such small utility > classes like the commons should really think twice before going happily > into security-breaking and should document their inability to run as an > applet. For what it's worth, I think it's more often the case that the developers generally don't try to run the code in a "secured" or "sandboxed" environment like an applet, and hence unintentionally "go happily into security breaking". Clearly, documenting that applets aren't supported isn't the best solution, supporting applets is. In most cases if someone points out "don't do that, it's not applet friendly" the developer will gladly implement an alternative solution or at least provide some sort of workaround. It's just that in general the devloper is unaware of the issue. Pressure from applet-oriented clients (like you) is one good way to address this. Perhaps adding a some sort of unit testing framework for running regular Junit tests in a "secured" mode would be another. I'd be willing to experiment with the latter if anyone else would like to collaborate. - Rod > Thanks. > > Paul > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
