Software written for the Java Card platform follows the standard rules for the Java platform packages. Java Card API classes are written as Java source files, which include package designations. Package mechanisms are used to identify and control access to classes, static fields and static methods. Except as noted in “Access Control in Java Packages” ( Section 2.2.1.1, Unsupported Features), packages in the Java Card platform are used exactly the way they are in the Java platform.

The Java Card platform programs supports dynamically created objects, both class instances and arrays. This is done, as usual, by using the new operator. Objects are allocated out of the heap.

A Java Card virtual machine will not necessarily garbage collect objects. Any object allocated by a virtual machine may continue to exist and consume resources even after it becomes unreachable. See Section 2.2.3.2, Object Deletion Mechanism for more information regarding support for an optional object deletion mechanism.

Since Java Card technology-based objects (“Java Card objects”) are Java programming language objects, invoking virtual methods on objects in a program written for the Java Card platform is exactly the same as in a program written for the Java platform. Inheritance is supported, including the use of the super keyword.

Java Card API classes may define or implement interfaces as in the Java programming language. Invoking methods on interface types works as expected. Type checking and the instanceof operator also work correctly with interfaces.

Java Card programs may define, throw and catch exceptions, as in Java programs. Class Throwable and its relevant subclasses are supported. Some Exception and Error subclasses are omitted, since those exceptions cannot occur in the Java Card platform. See Section 2.3.3, **Exception**s for specification of errors and exceptions.

This Java language facility allows a type or method to operate on objects of various types while providing compile-time type safety. It adds compile-time type safety and eliminates the need for casting.

This Java language facility lets you avoid importing an entire class simply to access its static members or qualifying static members with class names each time it is used.

This language feature lets you avoid writing boilerplate code under many circumstances by enabling tools to generate it from annotations in the source code. The Java Card platform language subset supports the use of annotations which are not visible at runtime. These annotations do not themselves use the runtime visible meta-data annotation @Retention(RetentionPolicy.RUNTIME).