Help! Where's my UIManager

[Zerex71]

Greetings,

I spent a frustrating amount of time yesterday trying to figure out
how to get access to the UIManager class. I am dusting off my Swing
skills after a number of years and I shouldn't have to be fighting the
compiler - the Swing paradigm is enough of a challenge as it is.

I am simply trying to set the LAF of my app to use the cool Java metal
look instead of the default Windows LAF. Here's the offending LOC:

import javax.swing.UIManager;

UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());

It throws the four exceptions listed in the Java documentation at Sun,
leading me to believe it simply does not know where to find the
UIManager class. I have a normal Java 1.6.0_05 installation.

Any help will be greatly appreciated!

Thanks,
Mike

 

[Jean-Baptiste Nizet]

Greetings,

I spent a frustrating amount of time yesterday trying to figure out
how to get access to the UIManager class. I am dusting off my Swing
skills after a number of years and I shouldn't have to be fighting the
compiler - the Swing paradigm is enough of a challenge as it is.

I am simply trying to set the LAF of my app to use the cool Java metal
look instead of the default Windows LAF. Here's the offending LOC:

import javax.swing.UIManager;

UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());

It throws the four exceptions listed in the Java documentation at Sun,
leading me to believe it simply does not know where to find the
UIManager class. I have a normal Java 1.6.0_05 installation.

How could it throw the 4 exceptions? Only one exception may be thrown
by a method at runtime, but not 4 at once.
I suspect that the *compiler* refuses to compile your code because the
method *might* throw one of these 4 exceptions, and you don't catch
them or rethrow them.
Since the call should never throw any of the exceptions (the class
name returned by getCrossPlatformLookAndFeelClassName() being of
course perfectly valid for any platform), I suggest you just catch
them and rethrow them as a runtime exception:

try {

UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());
}
catch(ClassNotFoundException e) {
// should never happen
throw new RuntimeException(e);
}
catch(InstantiationException e) {
// should never happen
throw new RuntimeException(e);
}
catch(IllegalAccessException e) {
// should never happen
throw new RuntimeException(e);
}
catch(UnsupportedLookAndFeelException e) {
// should never happen
throw new RuntimeException(e);
}

JB.

 

[Zerex71]

How could it throw the 4 exceptions? Only one exception may be thrown
by a method at runtime, but not 4 at once.
I suspect that the *compiler* refuses to compile your code because the
method *might* throw one of these 4 exceptions, and you don't catch
them or rethrow them.
Since the call should never throw any of the exceptions (the class
name returned by getCrossPlatformLookAndFeelClassName() being of
course perfectly valid for any platform), I suggest you just catch
them and rethrow them as a runtime exception:

try {

UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());}

catch(ClassNotFoundException e) {
// should never happen
throw new RuntimeException(e);}

catch(InstantiationException e) {
// should never happen
throw new RuntimeException(e);}

catch(IllegalAccessException e) {
// should never happen
throw new RuntimeException(e);}

catch(UnsupportedLookAndFeelException e) {
// should never happen
throw new RuntimeException(e);

}

JB.

Yes, the compiler is catching the four listed exceptions, which I find
weird - I thought exceptions were only runtime artifacts. I saw this
try-catch block as an example and didn't implement it. I thought,
"Why can't I just make the calls and let the chips fall where they
may?" But since it won't compile, I'm under the impression that it
simply can't find the UIManager. What's worse, if I try to type the
import statement (I use Eclipse), with each "filtering", I get to the
end of the line and there's no UIManager class anywhere, further
bolstering my opinion that somehow the class isn't even present.

Mike

 

[Jean-Baptiste Nizet]

Yes, the compiler is catching the four listed exceptions, which I find
weird - I thought exceptions were only runtime artifacts. I saw this
try-catch block as an example and didn't implement it. I thought,
"Why can't I just make the calls and let the chips fall where they
may?" But since it won't compile, I'm under the impression that it
simply can't find the UIManager. What's worse, if I try to type the
import statement (I use Eclipse), with each "filtering", I get to the
end of the line and there's no UIManager class anywhere, further
bolstering my opinion that somehow the class isn't even present.

Mike

Sorry if this sounds rude, but you should probably read a book about
basic Java programming if you don't understand how imports and
exceptions work.

The UIManager class IS present, and you should be able to import it.
BTW, if the compiler signals errors about your code not catching these
exceptions, this means that it has found the class. When the compiler
signals an error, you MUST fix it: the code won't even be compiled and
you won't be able to run it.

Regarding exceptions, Java has two kinds of exceptions: "normal"
exceptions, and runtime exceptions. Runtime exceptions all derive from
the class java.lang.RuntimeException. A runtime exception may be
ignored by the caller of a method that might throw it. But a normal
exception MUST be taken care of by the caller method: either it lets
it go to the parent caller (by declaring "throws FooBarException"), or
it catches it. If the caller method doesn't declare the exception and
doesn't catch it, the compiler will refuse to compile your code.

The example I gave you catches all the declared exceptions, and throws
a runtime exception if it happens (which should never be the case).

JB.

 

[Zerex71]

Sorry if this sounds rude, but you should probably read a book about
basic Java programming if you don't understand how imports and
exceptions work.

The UIManager class IS present, and you should be able to import it.
BTW, if the compiler signals errors about your code not catching these
exceptions, this means that it has found the class. When the compiler
signals an error, you MUST fix it: the code won't even be compiled and
you won't be able to run it.

Regarding exceptions, Java has two kinds of exceptions: "normal"
exceptions, and runtime exceptions. Runtime exceptions all derive from
the class java.lang.RuntimeException. A runtime exception may be
ignored by the caller of a method that might throw it. But a normal
exception MUST be taken care of by the caller method: either it lets
it go to the parent caller (by declaring "throws FooBarException"), or
it catches it. If the caller method doesn't declare the exception and
doesn't catch it, the compiler will refuse to compile your code.

The example I gave you catches all the declared exceptions, and throws
a runtime exception if it happens (which should never be the case).

JB.

I used your code suggestion and the LAF is still the same Windows-
looking thing. I want the Java variety. It's not working for me.

 

[Thomas Kellerer]

Zerex71, 29.04.2008 18:37:

I used your code suggestion and the LAF is still the same Windows-
looking thing. I want the Java variety. It's not working for me.

From the JavaDocs:
http://java.sun.com/j2se/1.5.0/docs...r.html#getCrossPlatformLookAndFeelClassName()

"If the system property swing.crossplatformlaf has been defined, its value will be returned."

Is it possible that you are setting that property somewhere?
Check if you have a swing.properties in your JDK installation which might set that property.

Otherwise you could call getInstalledLookAndFeels() and see which are available in your installation.

Thomas

 

[Zerex71]

Zerex71, 29.04.2008 18:37:




From the JavaDocs:http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/UIManager.html#ge...()

"If the system property swing.crossplatformlaf has been defined, its value will be returned."

Is it possible that you are setting that property somewhere?
Check if you have a swing.properties in your JDK installation which might set that property.

Otherwise you could call getInstalledLookAndFeels() and see which are available in your installation.

Thomas

I used Google Desktop to see if it could find a swing.properties file
on my system and it could not. I have never used it and don't know
where it would be on the machine. I will read up on this file and see
what it can do for me.

Thanks,
Mike