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.
