Not sure I understand exactly what you want... but, have you
considered using static fields ("class variables")? They're allocated
when the owning class is loaded and remain accessible for the entire
lifespan of the JVM. So different applications running inside the same
VM can access them. Of course you'll need to build an abstraction upon
such field(s), so that you can e.g. handle concurrency in a
transparent way, and in general adopt the good practice of denying
direct access to the fields, masking it with method calls.
Of course this works only if you are certain that all your apps will
run inside the same VM. If the VM is shut down, or the system crashes,
etc., any non-persistent state is of course lost.
Just my 2 cents...

cheers
Alessio S.

Applets are run within a strict security sandbox unless
the code is digitally signed, and accepted by the user.
Even then, the paths that they can right/read form, might
be very limited (e.g. latest IE/Vista bug).

Do your end users really need an applet?

Applets can be launched using Java Web Start*, but
if you want something free floating, you might as
well use a (J)Frame.  

JWS apps. also get a security sandbox, but the JNLP API
allows us to 'break out' of it (with user permission), to do
things like access files**.

Even better, JWS provides the 'muffin' (like a cookie, but
for web start) that allows us to share information across
different apps. from the same codebase ('site').  This is
in the PersistenceService***.

* <http://www.physci.org/jws/#jtest>
** <http://www.physci.org/jws/#fs>
*** <http://www.physci.org/jws/#ps>
(but perhaps Sun has a better example of sharing
the muffins *between* apps)
<http://java.sun.com/j2se/1.4.2/docs/guide/jws/developersguide/examples.html#Pers
istenceService

Don't store any information within the JRE
directories themselves.

Sure - web start is one way.

There are other ways for 'full permission' standard
desktop apps (Properties, Preferences..).