Got it. Thank you. Alan
> On Jun 2, 2015, at 12:10 PM, Phil Race <philip.r...@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 <javali...@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 >>> >
