<Swing Dev> [9] Review request for 8136366 Add a public API to create a L&F without installation

[Sergey Bylokhov]

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.