[cap-talk] Java coding rules for capability discipline

[Stiegler, Marc D]

> > Anyway, to answer your question about a single-access 
> resource, i.e., 
> > a singleton object, here is an oddball idea: have a public static 
> > "make" method that creates and returns an object the first 
> time it is 
> > called...but instead of always returning the cached created object 
> > each successive time, as in the typical singleton pattern, make it 
> > return a null every time it is called after the first time. 
> This way 
> > you are guaranteed that the object is created once, and that it is 
> > moved around via explicit reference passing rather than by the 
> > unconfined and surprising (from a security perspective) 
> backchannel of 
> > a static mutable.
> 
> 
> OK, but how does the static method know to return a null
> any time after the first?  It has to have some static data 
> available to it to know that the 2nd time has arrived, no?

Hmmmm... I think it would be ok to treat this as a special case for a
private static variable, since there's only one instance ever created,
so it can't share anything across instances, but it would be better to
find a different solution. 

> 
> Alternatively, can one do a static that is final
> rather than mutable?  I must try that...  That would
> solve the singleton problem, at least, in Java.

The problem is more complicated than that. If the final object itself
has mutable state, you still have unconfined, implicitly accessible
mutable state: a final array would still allow instances to communicate
by modifying the contents of the array. The only safe thing here is
final DeepPassByCopy objects. A common example of something that is ok
is the WindowsConstants, and the other scalar/string constants that are
made available as public static final variables.

Some of these problems can be solved by using inner classes with more
enthusiasm and frequency than is typical in Java. Those problems that
can be solved with inner classes are much harder to solve in DotNet C#,
where there ain't no such thing.

--marcs