Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Custom class loader and java.awt.*

5 views
Skip to first unread message

Davor Cubranic

unread,
Apr 21, 1999, 3:00:00 AM4/21/99
to
I'm trying to write a very simple class loader which will eventually
incorporate additional functionality. For now, all I really do is load
the classfile from a jar or .class file, define it, and return the
defined Class object to the caller -- nothing fancy, probably the same
stuff that's done by the default loader. My application then loads the
application I want to run through my class loader and then invokes the
loaded class's main method, so that all the classes used by that
application will be loaded through my class loader.

In my loader's loadClass() method, I do the usual findLoadedClass()
first and a findSystemClass() if the name starts with "java." before
going on to load the classfile into an array of bytes and calling
defineClass() on it. However, I recently tried to load java.awt.*
classes myself instead of calling findSystemClass() on them, and
obviously hit a hornet's nest. Whichever awt application I use (e.g.,
those in the demo/jfc/swing subdirectory of JDK1.2b4), everything
starts up fine, churns for a little while, and then breaks down with
the following stack trace:

java.lang.reflect.InvocationTargetException: java.lang.Error: can't load com.sun.java.swing.plaf.metal.MetalLookAndFeel
at com.sun.java.swing.UIManager.initializeDefaultLAF(Compiled Code)
at com.sun.java.swing.UIManager.initialize(Compiled Code)
at com.sun.java.swing.UIManager.maybeInitialize(Compiled Code)
at com.sun.java.swing.UIManager.getUI(Compiled Code)
at com.sun.java.swing.JPanel.updateUI(Compiled Code)
at com.sun.java.swing.JPanel.<init>(Compiled Code)
at com.sun.java.swing.JPanel.<init>(Compiled Code)
at SimpleExample.<init>(Compiled Code)
at SimpleExample.main(Compiled Code)
at java.lang.reflect.Method.invoke(Native Method)
at Myapp.main(Compiled Code)

Upon further investigation, I found out that what really happens is
that a null pointer exception is raised further down the call chain,
is caught by initializeDefaultLAF(), which then throws the above
error. Here is the stack trace of that:

java.lang.NullPointerException
at sun.java2d.loops.GraphicsPrimitiveProxy.instantiate(Compiled Code)
at sun.java2d.loops.GraphicsPrimitiveMgr.locate(Compiled Code)
at sun.java2d.loops.GraphicsPrimitiveMgr.locate(Compiled Code)
at sun.awt.image.BufferedImageGraphics2D.clearRect(Compiled Code)
at sun.awt.image.OffScreenImage.initBackground(Compiled Code)
at sun.awt.image.OffScreenImage.<init>(Compiled Code)
at sun.awt.motif.MComponentPeer.createImage(Compiled Code)
at java.awt.Component.createImage(Compiled Code)
at com.sun.java.swing.plaf.metal.BumpBuffer.<init>(Compiled Code)
at com.sun.java.swing.plaf.metal.MetalBumps.createBuffer(Compiled Code)
at com.sun.java.swing.plaf.metal.MetalBumps.setBumpColors(Compiled Code)
at com.sun.java.swing.plaf.metal.MetalBumps.<init>(Compiled Code)
at com.sun.java.swing.plaf.metal.MetalBorders$ToolBarBorder.<init>(Compiled Code)
at com.sun.java.swing.plaf.metal.MetalLookAndFeel.initComponentDefaults(Compiled Code)
at com.sun.java.swing.plaf.basic.BasicLookAndFeel.getDefaults(Compiled Code)
at com.sun.java.swing.plaf.metal.MetalLookAndFeel.getDefaults(Compiled Code)
at com.sun.java.swing.UIManager.setLookAndFeel(Compiled Code)
at com.sun.java.swing.UIManager.setLookAndFeel(Compiled Code)
at com.sun.java.swing.UIManager.initializeDefaultLAF(Compiled Code)
at com.sun.java.swing.UIManager.initialize(Compiled Code)
at com.sun.java.swing.UIManager.maybeInitialize(Compiled Code)
at com.sun.java.swing.UIManager.getUI(Compiled Code)
at com.sun.java.swing.JPanel.updateUI(Compiled Code)
at com.sun.java.swing.JPanel.<init>(Compiled Code)
at com.sun.java.swing.JPanel.<init>(Compiled Code)
at SimpleExample.<init>(Compiled Code)
at SimpleExample.main(Compiled Code)
at java.lang.reflect.Method.invoke(Native Method)
at Myapp.main(Compiled Code)

Now, what happens in sun.java2d.loops.GraphicsPrimitiveProxy.instantiate()
is something like this call:
[...] = manager.getClass().getPackage().getName() + "." + relativeClassName;
to which getPackage returns null (I'm not sure why).

Interestingly enough, even if I load all the classes in this trace but
java.awt.* (sun.* and com.sun.java.swing.*) through my loader, the
program runs normally (not only that, but GraphicsPrimitiveProxy class
doesn't even get loaded). So the culprit has to be in my loader's
handling of java.awt.*, although I don't have a clue as to why it
would cause the above problem.

Has anyone run into something like this before and/or has any ideas as
to what is happening here?

Thanks,

Davor

Davor Cubranic

unread,
Apr 21, 1999, 3:00:00 AM4/21/99
to
Davor Cubranic <cubr...@cascade.cs.ubc.ca> writes:

> Interestingly enough, even if I load all the classes in this trace but
> java.awt.* (sun.* and com.sun.java.swing.*) through my loader, the
> program runs normally (not only that, but GraphicsPrimitiveProxy class
> doesn't even get loaded).

Scratch that last remark in parenthesis. It just occured to me that if
java.awt.* is loaded through the default loader, then all the
sun.awt.* classes would probably go through it as well, which would
explain their absence from MyLoader's log of classes it loaded.

Davor

0 new messages