Extended CAP Accessibility Example

To understand the extended CAP file accessibility, let’s consider a scenario as shown in the following figure:

Figure 8-1 Extended CAP Accessibiliy Example

The following table describes the package level access under different access conditions (1, 2, and 3):

Table 8-1 Package Level Access

Accessibility	package1	package2	package3	package4	package5
package1 has access to:	N/A	Yes (1) and (2)	Yes (1)	Yes (1)	Yes (1), (2), and (3)
package2 has access to:	Yes (1) and (2)	N/A	Yes (1)	Yes (1)	Yes (1), (2), and (3)
package3 has access to:	Yes (1) and (2)	Yes (1) and (2)	N/A	Yes (1)	Yes (1), (2), and (3)
package4 has access to:	Yes (1) and (2)	Yes (1) and (2)	Yes (1)	N/A	Yes (1), (2), and (3)
package5 has access to:	Yes (1) and (2)	No (1)	No (1) and (3)	Yes (1) and (3)	N/A

The following are the access conditions (1, 2, and 3) that are listed in the table:

1. Exported packages in an extended CAP file - Packages in an extended CAP file can be marked as public or private. Only the public packages are accessible from packages in another CAP file. However, all packages are accessible within the same CAP file.
2. Java access rules - Code access conforms to Java accessibility rules (private, public, package, protected, and so on). For example, inside the Class1 or Class2 methods, a Class3()or a Class4() constructor can be called (only if the constructors are public) or other public methods from Class3 and Class4, even if Class3 and Class4 are Java Card applets.
3. Java Card access rules for package containing an Applet - A public package containing a class extending the javacard.framework.Applet class does not export all its public classes and interfaces. Only the interfaces extending the javacard.framework.Shareable interface or the classes implementing it are exported and visible from other packages. For example, code from package5 can access only the Class5 in package4 and cannot access content of package3 because nothing is exported.