Skip to main content

Classloader / security manager

5 replies [Last post]
chris_e_brown
Offline
Joined: 2004-09-14
Points: 0

I use the Foxtrot API for handling long-running tasks without blocking the Swing Event-Dispatching Thread. In Mustang b68 (not b67 or earlier), it fails. I've already starting discussing this on the API's mailing list and on another thread on another forum:
http://www.javadesktop.org/forums/thread.jspa?threadID=22907&tstart=0

I'm raising the subject HERE for a different reason: the stacktrace suggests that there have been some changes to the security manager / classloader with regards to proxy classes. I'm launching a Swing app without a security manager, and the error doesn't occur under Java 5 or earlier builds of Mustang. I've appended the stacktrace to the end of my posting below, but again, I'm enquiring here about any general changes that might affect me or others, not about this specific issue with Foxtrot...

Thanks,
Chris

[SunJDK14ConditionalEventPump] PANIC: uncaught exception in Foxtrot code
java.lang.SecurityException: Prohibited package name: java.awt
at java.lang.reflect.Proxy.defineClass0(Native Method)
at java.lang.reflect.Proxy.getProxyClass(Proxy.java:504)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
at foxtrot.pumps.SunJDK14ConditionalEventPump.pumpEvents(SunJDK14ConditionalEventPump.java:162)
at foxtrot.Worker.post(Worker.java:104)
at foxtrot.Worker.post(Worker.java:131)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kamg
Offline
Joined: 2005-06-16
Points: 0

Some early versions of Foxtrot look to be doing some slightly questionable things (defining an interface in java.awt). I wonder if that's the problem. Does your copy have a java.awt class in the jar?

I'd try an updated version of foxtrot if so.

kamg
Offline
Joined: 2005-06-16
Points: 0

Ok - the problem seems to be with a recent bug fix to the VM that caused stricter checking of package names which was overbroad and broke some java.lang.reflect.Proxy code.

The fix has been improved and should be available in build 72. Please try it again then and let me know if it doesn't solve the problem.

kamg
Offline
Joined: 2005-06-16
Points: 0

Hi Chris -

I know what part of the problem is. The variations of ClassLoader.defineClass() which take a string to indicate the name of the class to be defined prevents defining classes whose package starts with "java." for security reasons. Up until b68, there was a hole where one could use the deprecated name-less varient of ClassLoader.defineClass() to define a class in one of these packages. Those hole has been plugged in the VM, which is why you're seeing this.

Now the question is, who is calling this deprecated method, and can it be fixed not to (or to call with a different package name). I'm not sure if it's java.lang.reflect or foxtrot, but from the stack trace it looks like java.lang.reflect. I'll try to look into it.

chris_e_brown
Offline
Joined: 2004-09-14
Points: 0

OK. I'm a user of Foxtrot, not a developer. You should be able to get more details from the author, see either:

http://foxtrot.sourceforge.net/
http://sourceforge.net/mailarchive/forum.php?forum_id=8428

I'll post there to encourage the author to get in contact with you.

Thanks for the feedback,
Chris

kamg
Offline
Joined: 2005-06-16
Points: 0

Hi Chris -

Thanks, we may have to work with foxtrot to figure out what's going on. Until then, though, do you happen to know what type of interface foxtrot is attempting to make a proxy for in stack trace you sent? According to the proxy code in java.lang.reflect, it looks like it it doesn't attempt to define a class in the java.awt package unless the interface is non-public. There are a couple of interface in java.awt that are non-public, but I don't know if that's what's tripping us up here. I don't see how foxtrot would even see a non-public interface in a different package. Hmm....