<AWT Dev> <Swing Dev> internal API usage: sun.awt.AppContext

[Phil Race]

Alan,

AppContext was devised to support applets running in browsers
where the JDK internal classes were shared so were in need of
a way to provide a key that was unique to each running applet.
Note that the 'advertisement' is comments on the internal source code.
Unless your L&F is installed on the JDK bootclasspath of a
the VM running applets in a browser I am not sure how this
internal class is useful to it. Otherwise storing as static variables should
work since there will be a class per classloader.
If necessary you can roll your own that just uses the ThreadGroup
as a key to get to a map .. that's what it amounts to.

-phil.

On 06/02/2015 10:37 AM, Alan Snyder wrote:
> Is this the proper forum for asking this question? I have not seen any reply.
>
>
>
>
>
>> On May 28, 2015, at 7:13 PM, Alan Snyder <javalists at cbfiddle.com> wrote:
>>
>> I am using code — a custom Swing look and feel — that uses the getAppContext(), get(), put(), and remove() methods of sun.awt.AppContext to store configuration data.
>>
>> Since the look and feel is registered by UIManager using the same mechanism, this seems like the right way to store configuration data for a look and feel.
>>
>> I also note that AppContext advertises itself as a better solution (e.g. better than static fields) to protect applets from being disrupted by other applets, so it may have other uses.
>>
>> Is there a way to duplicate this behavior using only public APIs? If not, I request that this functionality be exported in some form by JDK 9.
>>
>>   Alan
>>