--- Comment #8 from mckinlay at redhat dot com 2006-05-17 15:18 ---
Fixed
--
mckinlay at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from bryce at gcc dot gnu dot org 2006-05-17 15:10 ---
Subject: Bug 27352
Author: bryce
Date: Wed May 17 15:09:57 2006
New Revision: 113863
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113863
Log:
PR libgcj/27352
* java/lang/Class.java (getClassL
--- Comment #6 from mckinlay at redhat dot com 2006-05-16 01:03 ---
I've posted a suggested fix here:
http://gcc.gnu.org/ml/java-patches/2006-q2/msg00168.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27352
--- Comment #5 from aph at gcc dot gnu dot org 2006-05-04 18:45 ---
Subject: Bug 27352
Author: aph
Date: Thu May 4 18:44:53 2006
New Revision: 113532
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113532
Log:
2006-05-04 Andrew Haley <[EMAIL PROTECTED]>
* class.c (mak
--- Comment #4 from aph at gcc dot gnu dot org 2006-05-02 10:08 ---
The real reason is that we want the actual caller of
SecurityManager.checkPermission(), but we're walking up the stack to the user
code that called Class.newInstance() Class.getMethod(). This problem is as far
as I'm aw
--- Comment #3 from csm at gnu dot org 2006-05-01 06:41 ---
It looks like methods internal to Class need to bypass the security manager
when getting the class loader, or should be doing that lookup in a
`doPriviliged' block, right?
Does Classpath itself suffer from this?
--
http://
--- Comment #2 from aph at gcc dot gnu dot org 2006-04-28 15:18 ---
The output of this test should be something like:
java.lang.Throwable
at MySecurityManager.checkPermission(t.java:33)
at java.lang.Class.getClassLoader(Class.java:580)
at trial.x(trial.java:5)
--- Comment #1 from aph at gcc dot gnu dot org 2006-04-28 15:16 ---
Created an attachment (id=11344)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11344&action=view)
Test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27352
