From crazyboblee on March 14, 2007 17:53:48

Hmmmmm, why wouldn't setAccessible() work?

From crazyboblee on March 14, 2007 19:34:33

Assuming you have permissions (Kevin does).

From dhanji on March 14, 2007 21:14:38

other than a SecurityManager? nothing should... is there a specific message?
conceivably something viral like a class being loaded as a result of the call might?
Im really reaching tho...

From kevinb9n on March 14, 2007 21:22:45

oops, said my last comment in email only.

Guice ended up trying to construct an instance of the class java.lang.Class.  It was
an accident, and no way is java gonna let you just setAccessible() on that thing, and
let's be glad for that. :)

Anyway, apart from the java.lang.Class example, we ought to make sure that guice
always reports problems helpfully, no matter what the security manager.

From limpbizkit on June 04, 2008 23:17:02

(No comment was entered for this change.)

Labels: -Priority-Medium Priority-Low Milestone-Release2.0

From limpbizkit on July 12, 2008 10:18:51

Only Class.class and Constructor.class disallow setAccessible. These cases were indirectly fixed when we
disallowed private no-arg constructors that weren't annotated with @Inject.

For the general SecurityManager case, this is probably not worth the effort. I tried to write a test that uses a
SecurityManager, but it seems that almost anything we do has the potential of throwing a SecurityException. For
example, looking up the annotations on a type indirectly requires the reflect permission.

Status: Fixed