CODEWITHSUNDEEP
javaappletjavacard
Vasanth
Vasanth

Reputation: 11

After reset, what will happen to persistent arrays declared and initialized in different ways?

Assume the applet constructor and processToolkit method were called before card reset. Assume only applet constructor is called after card reset, not processToolkit method.

I have the the following three questions regarding the state of Object header's after reset.

  1. Will Object Header of array A be valid or just garbage?
  2. Will Object Header of array B be valid or just garbage?
  3. Will Object Header of array C be valid or just garbage?

For the following code:

public class TestApplet extends Applet 
{ 

    private byte[] A;
    private byte[] B;

    protected TestApplet() {
        A = JCSystem.makeTransientByteArray(100, JCSystem.CLEAR_ON_RESET);
    }

    public static void install(byte[] bArray, short bOffset, byte bLength) {
        TestApplet appToRegister = new TestApplet();
        appToRegister.register();
    }

    public void processToolkit(short event) throws ToolkitException {
        byte[] C;
        C = JCSystem.makeTransientByteArray(100, JCSystem.CLEAR_ON_RESET);
        B = JCSystem.makeTransientByteArray(100, JCSystem.CLEAR_ON_RESET);
    }
}

Upvotes: 1

Views: 187

Answers (2)

Maarten Bodewes
Maarten Bodewes

Reputation: 93948

The applet constructor can only be called once per instance. So if we are talking about a different instance then only A will have been declared and instantiated.

B will only have been declared, but note that fields are initialized by default in Java, specifically to null for object references (and references to arrays are treated as references to objects in Java).

C, of course, isn't known. It's local to processToolkit so it won't exist.

Note that the call to Applet.register seems to be missing in action, so the instance may not be available after it was instantiated.

The persistent memory claimed by the earlier instance (the object header) for C may need to be garbage collected of course. C is a known bad pattern in Java Card; you don't claim persistent memory only to throw away the reference afterwards in Java Card.

Upvotes: 2

Martin Paljak
Martin Paljak

Reputation: 4142

As per sensible and responsible JavaCard programming style, you shall not have C and shall make B next to A in the constructor and call the constructor only once during applet installation from install(). The rest is described in JavaCard runtime environment spec.

Upvotes: 3

Related Questions