Looks fine.
On 01.04.16 18:19, Alexander Scherbatiy wrote:
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8136366/webrev.01
The UnsupportedLookAndFeelException is thrown from the
UIManager.createLookAndFeel(className) method for unsupported L&Fs.
Thanks,
Alexandr.
On 01/04/16 18:14, Sergey Bylokhov wrote:
On 01.04.16 16:02, Alexander Scherbatiy wrote:
I see the point that creating non installed system L&F may not have
many sense.
I guess we should thinking about supported/unsupported instead of
installed/non-installed.
One more use case that should be considered is using the
createLookAndFeel(className) method with custom L&Fs.
For example someone can have a list with L&F class names which
includes both system and custom L&F.
Using a class name he wants to check if the given L&F is supported.
Does he need to install the custom L&F first?
If no, he will need to handle L&Fs differently using
UIManager.createLookAndFeel(className) for system L&Fs and reflection
for custom.
Is the new method a "shortcut" for:
- UIManager.setLookAndFeel("com.foo")
- laf = UIManager.getLookAndFeel();
- laf is used...
Then probably the new method should work symmetrically to
setLookAndFeel() and throw UnsupportedLookAndFeelException()? And if
the Laf will be created will means that its state is valid(like
uidefaults etc)
Small notes:
- Should we specify the null behavior?
- It is unrelated to current fix, but I wonder why we call newInstance
for all incoming classes(we initialize the class and create the
instance), and then we cast this new object to LookAndFeel.
--
Best regards, Sergey.