Accessors in Python (getters and setters)

[Diez B. Roggisch]

Ed Jensen schrieb:
> Diez B. Roggisch <deets at nospam.web.de> 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