CLEAR_ON_DESELECT transient objects can be accessed only when the applet which created the object is in the same context as the currently selected applet.My reading is that CLEAR_ON_DESELECT (but not CLEAR_ON_RESET) would allow the runtime to overlay the transients (allocated on install as stated above) between two applets, as long as they are not simultaneously selected, so that several applets allocating m ~j~ bytes would consume about max( m ~j~ ) transient bytes, rather than sum( m ~j~ ).
The Java Card runtime environment will throw a SecurityException if a CLEAR_ON_DESELECT transient object is accessed when the currently selected applet is not in the same context as the applet which created the object.
fgrieu wrote:That's how I interpret the spec and also implemented in the JCOP.
Thanks lexdabear, I'm taking your answer as implying the overlay occurs in at least some cases, and how to check that in a JCOP context.
But is that universal, and what's the rule?
I'm told something on the tune that on at least some runtime environments, the overlay occurs selectively for transients allocated from different packages.That's right regarding the packages. COD is allocated per package, not applet.
But I fail to find a reference, or a precise description of such rule/mechanism.I read it from the extract you pasted above.
Also, the second question on what "context" means in the quoted restriction remains unanswered. Of course I can try, but again I'm afraid that could vary from a runtime to another.Context is here relevant in case SIO, logical channel and multiselectable are used.