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
