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

[Alan Snyder]

Got it. Thank you.

  Alan


> On Jun 2, 2015, at 12:10 PM, Phil Race <philip.race at oracle.com> wrote:
> 
> 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
>>> 
>