This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
i read, that default security settings allow invoking private methods through reflection. couldn't that be a big security hole?
for instance: -you guarantee through public/protected/default access modifiers, that your fields are in a valid state. -your private methods if single-called break class valid state, even worse if you can change private fields directly.
so with reflection you call/change private methods/fields and can break this way an application, you break especially encapsulation from security view .
so my questions are: -i think this can be a severe security flaw, so why does default security allow this (there must be a reason)? -or maybe i read things wrong and default security does not allow private access?
thank you. [ March 23, 2006: Message edited by: manuel aldana ]
By 'default' I assume that you mean running without a SecurityManager. Yes, without a SecurityManager you can write a program that relies on its accessors being used, and then you can include code that circumvents them, thus proving that you can shoot yourself in the foot if you want to.
But in circumstances where someone elses code might be involved (e.g. applets, web applications, applications using 3rd party plugins), there is sure to be a SecurityManager active which will prohibit this kind of access.
So I think the default is reasonable, especially since it's easy to run in a more secure way if you need to.