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

[Sergey Bylokhov]

I do not really think this new API is a good candidate to be public. The 
method which gets some unspecified name, then change it to some other, 
and at the end support only bundled L&F... The user was not able to get 
the list of built-in L&F. And at the same time the method iterates over 
the list of the installed L&F which can be changed by the user.

On 17.05.16 19:10, Phil Race wrote:
> +1
>
> -phil.
>
> On 05/17/2016 08:13 AM, Alexander Scherbatiy wrote:
>>
>>   Hello,
>>
>>   Could you review the updated fix:
>>     http://cr.openjdk.java.net/~alexsch/8136366/webrev.04
>>
>>    The proposed UIManager.createLookAndFeel(name) method allows to
>> create only Java built-in L&Fs by the given L&F name.
>>
>>  Thanks,
>>  Alexandr.
>>
>> On 4/4/2016 11:17 PM, Phil Race wrote:
>>> +1
>>>
>>> -phil.
>>>
>>> On 04/01/2016 08:19 AM, 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.