Ed Jensen schrieb: > Diez B. Roggisch <[EMAIL PROTECTED]> wrote: >>> Java is not an acronym. That is: it's "Java", not "JAVA". >> Now THAT was an important information RIGHT on topic. > > It was not meant offensively.
Ok. >>> Java does not allow access to private members via reflection. >> For somebody nitpicking on natural language usage to a non-native >> speaker, you show an impressive lack of knowledge in the actual subject >> discussed. > > Again: It was not meant offensively. > > Maybe you can try turning the flames down a bit. I'll try. >> http://www.onjava.com/pub/a/onjava/2003/11/12/reflection.html > > Does that approach work on sealed jars as well? I would imagine any > jars that need any kind of "real" security would be sealed... Well, lets put it like this: I work for a Java (see, I'm capable of learning... :)) shop. We deploy pretty large clustered J2EE thingies. In the last five years working there, I never once produced a sealed jar. And actually the use-case for a sealed jar is to allow _more_ in an otherwise restricted environment. Which puts us to the next question: the sealing itself doesn't do anything to restrict the code, the SecurityManager does. Which AFAIK is something hooked into the VM. Now, I'm not on sure grounds here on how to altere its behaviour, but I'd say if we're talking me working on a secure application that introduces its own SecurityManager, I'm still the one in control. I could use your lib, turn off privacy, and fiddle around. If things were the other way round, and I'd have to work in a restricted context, it actually might be that someone restricted private access (because he owns the VM!). But then - he'd also be able to forbid threading or file access or all kinds of things that I'd otherwise be used to work with which will suddenly make my code burst in flames. And if we are honest: the most problematic cases of abused code arenÄT the ones of strangers exploiting your code, but instead your fellow coders at the other department. Which most probably means that they aren't restrained by security management anyway. To summarize: it might be possible to jump through a few hoops to increase the security. But in 99.9% of cases this doesn't happen, as it would increase complexity by orders of magnitude - for a comparatively small gain (talking about private declarations. The sandbox-restrictions of Java for running applets certainly are worth it). Diez -- http://mail.python.org/mailman/listinfo/python-list