jcvm04naming.html

JAVA CARD 开发包规格说明,版本为2.2.2

<h4 class="Head3"><a name="pgfId-998639"></a>4.3.7.6 <a name="22193"></a>Virtual
<a name="marker-998638"></a>Methods</h4>
<p class="Paragraph"><a name="pgfId-7135"></a>Virtual methods are
instance methods that are resolved dynamically. The set includes all
public, protected and package-visible instance methods. Private
instance methods and all constructors are not virtual methods, but
instead are resolved statically during compilation.
</p>
<p class="Paragraph"><a name="pgfId-13233"></a>All virtual methods
defined in a package are assigned either public or private <a
 name="marker-14194"></a>virtual method tokens. Virtual method token
values must be in the range from 0 to 127, inclusive. Public and
private tokens for virtual methods are assigned from different
namespaces. The high bit of the byte containing a virtual method token
is set to one if the token is a private token.
</p>
<p class="Paragraph"><a name="pgfId-7136"></a>Public tokens for the
externally visible (public or protected) introduced virtual methods in
a class are numbered consecutively starting at one greater than the
highest numbered public virtual method token of the class's superclass.
If a method overrides a method implemented in the class's superclass,
that method is assigned the same token number as the method in the
superclass. The high bit of the byte containing a public virtual method
token is always set to zero, to indicate it is a public token. The
ordering of public virtual method tokens in a class is not specified.
</p>
<p class="Paragraph"><a name="pgfId-7137"></a>Private virtual method
tokens are assigned to package-visible virtual methods. They are
assigned differently from public virtual method tokens. If a class and
its superclass are defined in the same package, the tokens for the
package-visible introduced virtual methods in that class are numbered
consecutively starting at one greater than the highest numbered private
virtual method token of the class's superclass. If the class and its
superclass are defined in different packages, the tokens for the
package-visible introduced virtual methods in that class are numbered
consecutively starting at zero. If a method overrides a method
implemented in the class's superclass, that method uses the same token
number as the method in the superclass. The definition of the Java
programming language specifies that overriding a package-visible
virtual method is only possible if both the class and its superclass
are defined in the same package. The high bit of the byte containing a
virtual method token is always set to one, to indicate it is a private
token. The ordering of private virtual method tokens in a class is not
specified.
</p>
<h4 class="Head3"><a name="pgfId-7138"></a>4.3.7.7 <a name="17038"></a>Interface
Methods</h4>
<p class="Paragraph"><a name="pgfId-7139"></a>All interface methods
defined in a package are assigned public<a name="marker-14195"></a>
interface method tokens, as interface methods are always public.
Interface methods tokens values must be in the range from 0 to 127,
inclusive. The tokens for all the interface methods defined in or
inherited by an interface are numbered consecutively starting at zero.
The token value for an interface method in a given interface is
unrelated to the token values of that same method in any of the
interface's superinterfaces. Each interface includes its own token
values for all the methods inherited from super-interfaces as well as
its defined methods. The high bit of the byte containing an interface
method token is always set to zero, to indicate it is a public token.
The ordering of interface method tokens is not specified.
</p>
<h2 class="Head1"><a name="pgfId-8240"></a>
<div>
<hr align="left" size="6" width="15%" noshade="noshade"></div>
4.4 <a name="36343"></a>Binary <a name="marker-14196"></a>Compatibility</h2>
<p class="Paragraph"><a name="pgfId-8241"></a>In the Java programming
language the granularity of binary compatibility can be between classes
since binaries are stored in individual class files. In Java Card
systems Java packages are processed as a single unit, and therefore the
granularity of binary compatibility is between packages. In Java Card
systems the binary of a package is represented in a CAP file, and the
API of a package is represented in an export file.
</p>
<p class="Paragraph"><a name="pgfId-8242"></a>In a Java Card system, a
change to a type in a Java package results in a new CAP file. A new CAP
file is binary compatible with (equivalently, does not break
compatibility with) a preexisting CAP file if another CAP file
converted using the export file of the preexisting CAP file can link
with the new CAP file without errors.
</p>
<p class="Paragraph"><a name="pgfId-8243"></a>shows an example of
binary compatible CAP files, p1 and p1'. The preconditions for the
example are: the package p1 is converted to create the p1 CAP file and
p1 export file, and package p1 is modified and converted to create the
p1' CAP file. Package p2 imports package p1, and therefore when the p2
CAP file is created the export file of p1 is used. In the example, p2
is converted using the original p1 export file. Because p1' is binary
compatible with p1, p2 may be linked with either the p1 CAP file or the
p1' CAP file.<br>
<br>
</p>
<p class="FigureBox">FIGURE 4-2 Binary Compatibility Example<a
 name="pgfId-1002353"></a><a name="pgfId-1002354"></a> </p>
<img src="figures/JCVM04naming-5.jpg" align="bottom"><br>
<p class="Paragraph"><a name="pgfId-9072"></a>Any modification that
causes binary incompatibility in the Java programming language also
causes binary incompatibility in Java Card systems. These modifications
are described as causing a potential error in The Java Language
Specification. Any modification that does not cause binary
incompatibility in the Java programming language does not cause binary
incompatibility in a Java Card system, except under the following
conditions:
</p>
<ul>
  <li class="Bullet1"><a name="pgfId-9074"></a>The value of a token
assigned to an element in the API of a package is changed. </li>
  <p class="Linebreak"> </p>
  <li class="Bullet1"><a name="pgfId-8252"></a>The value of an
externally visible final static field (compile-time constant) is
changed. </li>
  <p class="Linebreak"> </p>
  <li class="Bullet1"><a name="pgfId-8254"></a>An externally visible
virtual method that does not override a preexisting method is added to
a non-final public class. </li>
  <p class="Linebreak"> </p>
  <li class="Bullet1"><a name="pgfId-996880"></a>An externally visible
interface method that does not override a preexisting method is added
to a public interface. </li>
  <p class="Linebreak"> </p>
</ul>
<p class="Paragraph"><a name="pgfId-8255"></a>Tokens are used to
resolve references to imported elements of a package. If a token value
is modified, a linker on a device is unable to associate the new token
value with the previous token value of the element, and therefore is
unable to resolve the reference correctly.
</p>
<p class="Paragraph"><a name="pgfId-12468"></a>Compile-time constants
are not stored as fields in CAP files. Instead their values are
recorded in export files and placed inline in the bytecodes in CAP
files. These values are said to be pre-linked in a CAP file of a
package that imports those constants. During execution, information is
not available to determine whether the value of an inlined constant is
the same as the value defined by the binary of the imported package.
</p>
<p class="Paragraph"><a name="pgfId-12472"></a>As described above,
tokens assigned to public and protected virtual methods are scoped to
the hierarchy of a class. Tokens assigned to public and protected
virtual methods introduced in a subclass have values starting at one
greater than the maximum token value assigned in a superclass. If a
new, non-override, public or protected virtual method is introduced in
a superclass it is assigned a token value that would otherwise have
been assigned in a subclass. Therefore, two unique virtual methods
could be assigned the same token value within the same class hierarchy,
making resolution of a reference to one of the methods ambiguous.
</p>
<p class="Paragraph"><a name="pgfId-997060"></a>The addition of an
externally visible, non-override method to a public interface is a
binary incompatible change. It allows classes which are not themselves
abstract to contain an abstract method. For example, consider the case
of an interface I implemented by a class C that is not abstract, where
I and C reside in different packages. If a new method is added to I,
creating I', then C cannot link with the new version of I' because this
would result in the class C containing an abstract method without the
class C being abstract. The fact that C can not link with I' means that
I and I' are not binary compatible.
</p>
<h2 class="Head1"><a name="pgfId-9139"></a>
<div>
<hr align="left" size="6" width="15%" noshade="noshade"></div>
4.5 <a name="12240"></a>Package <a name="marker-14197"></a>Versions</h2>
<p class="Paragraph"><a name="pgfId-12845"></a>Each implementation of a
package in a Java Card system is assigned a pair of major and minor
version numbers. These version numbers are used to indicate binary
compatibility or incompatibility between successive implementations of
a package.
</p>
<h3 class="Head2"><a name="pgfId-9342"></a>4.5.1 Assigning</h3>
<p class="Paragraph"><a name="pgfId-12850"></a>The major and minor
versions of a package are assigned by the package provider. It is
recommended that the initial implementation of a package be assigned a
major version of 1 and a minor version of 0. However, any values may be
chosen. It is also recommended that when either a major or a minor
version is incremented, it is incremented exactly by 1.
</p>
<p class="Paragraph"><a name="pgfId-12855"></a>A major version must be
changed when a new implementation of a package is not binary compatible
with the previous implementation. The value of the new major version
must be greater than the major version of the previous implementation.
When a major version is changed, the associated minor version must be
assigned the value of 0.
</p>
<p class="Paragraph"><a name="pgfId-12860"></a>When a new
implementation of a package is binary compatible with the previous
implementation, it must be assigned a major version equal to the major
version of the previous implementation. The minor version assigned to
the new implementation must be greater than the minor version of the
previous implementation.
</p>
<h3 class="Head2"><a name="pgfId-9346"></a>4.5.2 Linking<a
 name="marker-14198"></a></h3>
<p class="Paragraph"><a name="pgfId-12865"></a>Both an export file and
a CAP file contain the major and minor version numbers of the package
described. When a CAP file is installed on a Java Card
technology-enabled device a resident imag<a name="marker-14199"></a>e
of the package is created, and the major and minor version numbers are
recorded as part of that image. When an export file is used during
preparation of a CAP file, the version numbers indicated in the export
file are recorded in the CAP file.
</p>
<p class="Paragraph"><a name="pgfId-12771"></a>During installation,
references from the package of the CAP file being installed to an
imported package can be resolved only when the version numbers
indicated in the export file used during preparation of the CAP file
are compatible with the version numbers of the resident image. They are
compatible when the major version numbers are equal and the minor
version of the export file is less than or equal to the minor version
of the resident image.
</p>
<div class="navbar" align="center">
<br>
<br>
<table dir="ltr"
 summary="Navigation bar, includes the book title and navigation buttons"
 width="100%" cellpadding="0" cellspacing="0" border="0">
  <colgroup span="3" width="100%"><col id="1" span="1" width="45%"><col
 id="2" span="1" width="25%"><col id="3" span="1" width="30%"></colgroup><tbody>
    <tr bgcolor="#cccccc">
      <td class="navbartitle" align="left" rowspan="1" colspan="1"
 abbr="ChapTitle">&nbsp;&nbsp;Virtual Machine Specification, Java Card
Platform, v2.2.2 </td>
      <td class="navbartitle" align="right" rowspan="1" colspan="1"
 abbr="PartNum">3-11-06 </td>
      <td valign="top" align="right" rowspan="1" colspan="1"
 abbr="NavButtons"><a href="index.html"><img src="shared/toc01.gif"
 title="Table Of Contents" alt="Table Of Contents" width="30"
 height="26" border="0"></a><a href="JCVM03structVM.html"><img
 src="shared/prev01.gif" title="Previous Chapter" alt="Previous Chapter"
 width="30" height="26" border="0"></a><a href="JCVM05export.html"><img
 src="shared/next01.gif" title="Next Chapter" alt="Next Chapter"
 width="30" height="26" border="0"></a><a href="ix.html"><img
 src="shared/index01.gif" title="Book Index" alt="Book Index" width="30"
 height="26" border="0"></a> </td>
    </tr>
  </tbody>
</table>
<br>
<br>
</div>
<p class="copyrightlink"><a href="copyright.html">Copyright</a> &copy;
2005, Sun Microsystems, Inc. All Rights Reserved.
</p>
</body>
</html>