[Bug classpath/28070] Exception instatiating LogManager

[csm at gnu dot org]

------- Comment #2 from csm at gnu dot org  2006-06-17 08:29 -------
Subject: Re:   New: Exception instatiating LogManager

On Jun 17, 2006, at 12:00 AM, green at redhat dot com wrote:

> LogManager static initialization throws an exception if you have a  
> security
> manager installed.  I'll attach a test case to this issue.
>
> When I run it with gij I get:
>
> java.lang.ExceptionInInitializerError
>    at java.lang.Class.initializeClass(libgcj.so.7)
>    at java.util.logging.LogManager.<init>(libgcj.so.7)
>    at java.util.logging.LogManager.makeLogManager(libgcj.so.7)
>    at java.util.logging.LogManager.<clinit>(libgcj.so.7)
>    at java.lang.Class.initializeClass(libgcj.so.7)
>    at LogManagerSecurityDeath.main(LogManagerSecurityDeath.java:24)
> Caused by: java.lang.NullPointerException
>    at
> LogManagerSecurityDeath$1.checkPermission 
> (LogManagerSecurityDeath.java:20)
>    at java.util.logging.LogManager.checkAccess(libgcj.so.7)
>    at java.util.logging.LogManager.addLogger(libgcj.so.7)
>    at java.util.logging.Logger.getLogger(libgcj.so.7)
>    at java.util.logging.Logger.getLogger(libgcj.so.7)
>    at java.util.logging.Logger.<clinit>(libgcj.so.7)
>    at java.lang.Class.initializeClass(libgcj.so.7)
>    ...5 more
>
> I believe this is a Classpath bug, and not a gcj/libgcj error.
> LogManager.controlPermission needs to be initialized before it is  
> used.
>

I think you're right, and I seem to recall this being discussed before.

I don't see the point of that permission object being a class  
constant; does creating a new LoggingPermission on each call really  
create such a memory burden? It still looks to me like a really  
premature micro-optimization, and it has bad consequences.

Otherwise, using package-private methods that circumvent permission  
checks should be used internally, I think.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28070