Skip to main content

Weird error in webstartable demos...

Please note these forums are being decommissioned and use the new and improved forums at
7 replies [Last post]
Joined: 2003-06-11

can't change LAF to Metal: on selecting metal in the menu it opens an error dialog with the stacktrace (no stacktrace - doesn't the dialog support copy to clipboard?):

// error dialog title
Swinglabs Demos Error
// error message
nullto javax.swing.plaf.metal.MetalLookAndFeel
// this is the first line of the stacktrace
caused by: ClassNotFoundException: org.jdesktop.swingx.plaf.metal.MetalLookAndFeelAddons

happens only in the webstartable, all fine locally. Checked the jars (the addons class _is_ there), deleted all cached resources, ...

for your convenience, here's the link:

Question is two-fold:

- anybody else reproduce, please?
- ideas to what might be the problem?


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2011-03-29


At my System ( WinsowsXP SP3, Java 1.7 ) the web start demo is buggy.

At first the left Task-Container-Bar don't paint its content.
Only when I hover over the elements its repaint the content.

The JXTreeTable Demo is not working well.
After expanding some nodes or collapsing there are some painting bugs at some nodes and the selected row "jumps around" sometimes.
When I leave the tree table and hover over the left task container again the hover effect for the tree table ( pink rows @Nimbus L&F ) is painting some rows to ( parallel to the rows I hover over at the menu bar left ).

I got the same error trying to switch to the Metal L&F.

At the JXPanel demo, there is some nice ( Nimbus ) looking separator. But I can't move it. The cursor changed its icon when I hover over this separator but nothing happens else.

After switching to an other L&F the whole screen gets clobbered...
Worst case is the motif L&F ...

After trying to close the demo I get an ask for increasing the RAM for the java app !?

Many bugs left as it looks for me.

There are several nice things worth to mention.

The painter demos are very nice!
The functionality is great!
Nice to play with them e.G. the TextPainterDemo is awesome.

The Composite-Demo is great too!
Everythings looks nice and is fast too.

The smooth round corners for the panels looking good!

I hope you can fix the main bugs soon. If you need help I would help you, as I mentioned eralier.

Great work anyay ...



Joined: 2006-06-08

I can't respond to the other posts because they "don't exist" according to the forum software...ugh.

Debugging WebStart is a giant pain. I am guessing that we should be using the 3-arg version of Class.forName with our getClassLoader() method as the last argument. Going to make that change and if it runs locally; I will check it in.

I also don't think this is in anyway related to sandbox issues (or at least issues with escaping the sandbox).


Joined: 2003-06-11

Actually, turned out to be a two-part issue:

The throwing of ExceptionInInitializer was due to simple typo (as I should have noticed right from the start, by closely looking at the message - comforting that nobody else noticed it as well :-) in the very last fallback when looking up a suitable addon:

It turned up only because we _did_ have a sandbox issue: the way the serviceLoader was accessed isn't permitted in security restricted contexts:

What we did:

ServiceLoader<LookAndFeelAddons> addonLoader = 
     ServiceLoader.load(LookAndFeelAddons.class, getClassLoader());
for (LookAndFeelAddons addon : addonLoader) {
    // some matching code

This looked just fine (no errors anywhere except #1568), but ... the matching code was never reached because the iterable is empty in the sandbox. And that seems to be unrelated to classloader issues: it boils down to not having permission to access the resources in META-INF/services.

Doing the access in a priviledgedAction works, with a catch: the actual classLoading is done lazily. Naively wrapping the first line into the priviledgedAction doesn't help, we have to conquer the lazyness by actually accessing the iterator, something like:

protected static Iterable<LookAndFeelAddons> getProvidedLookAndFeelAddons() {
    final ServiceLoader<LookAndFeelAddons> loader = ServiceLoader.load(LookAndFeelAddons.class,
    // need to access the iterator inside a privileged action
    // probably because it's lazily loaded
            .doPrivileged(new PrivilegedAction<Iterable<LookAndFeelAddons>>() {
                public Iterable<LookAndFeelAddons> run() {
                    return loader;

    return loader;

Looks okay now - in the tests at least: previously failing tests are passing, not yet tested out in the wild.

Feedback highly welcome - not being a sandbox expert, chances are high that I might still be missing something.


Joined: 2003-06-11

yeah, the forum is ... [censored]

good that you can think of a possible solution - though I think the weirdest part of the problem is that we can switch to every installed LAF _except_ metal. Doesn't sound like a classLoader issue - or does it?


Joined: 2003-06-12

Same thing here, no idea why this would happen... Java 7u6.
If the application and libs were signed, it might work since it does locally ?

Joined: 2003-06-11

hmm ... my answer got blocked as spam by this f** site but I see it - do you?


Joined: 2003-06-11

thanks for checking :-)

hmm .. security might always be problematic, but then I would expect it to jump in when switching to any of the LAFs in the com.sun.* packages, not Metal. That's the really weird stuff: all others are just fine ...

If it really is security, we'll have to solve it somehow: SwingX _must_ run in the sandbox, no signing required.

Thanks for your feedback