像java这样的编程语言就其用于智能卡的主要好处而言，不仅是它允许每个人可以为智能卡编写程序。对于绝大多数用汇编或c并具有极少修改的公开接口的操作系统来说也都是可能的。对于java感兴趣的主要是大型系统的运营者，他们有着要从不同的制造商购买不同芯片的掩膜的问题，这种多重来源，确实具有策略方面的意义（由于减少了对单一供应商的依赖，以及对供应商的价格压力），但却连续地引起兼容性和测试的问题。目前，不可能指望由两个不同供应商的不同操作系统，按其所有不同的选项，会在接口水平上有相同的性能，这成为系统运营者的一个严峻的问题。

　　从系统运营者的立场看来，解决这个问题的理想方案将是与硬件无关的程序代码可以标准化的方式在智能卡内由一个被评估了的解释器执行。于是，一个应用程序可以仅编写、测试、评估一次，接着它就可被所有不同类型的智能卡操作系统执行。“从外面”看即从接口看来没有任何区别。这样可以保留多来源的好处而又消除了它的缺点。

　　当考查java是如何被集成到智能卡中之时，第1个版本，仅仅提供把java字节码存储在位于mf之下或一de之下的bf中。一条execute命令启动虚拟机去执行存储在ff中的程序。一个和文件系统有关的api（应用编程接口）允许对文件读出或写人数据。

　　然而，这种方法未能流行，根据java卡规范，一个具有java的智能卡中有一台java虚拟机，它在卡完工后被激活并在卡生命周期结束时被停用。不再包括像iso/iec 7816-4中所规定的文件系统，因为它可由java应用中的对象建立起来。有几类使它能比较容易地构造一个遵照iso/iec7816-4标准的文件树。程序代码和其相关的文件树二者都是装入到智能卡的支程序的一部分。在卡中的支程序可由select命令用惟一的ad予以选择。当支程序被选择后，它自动地接收所有要进一步处理的命令。支程序中的程序代码可以对命令及其相关的数据进行鉴定和处理，以及实现相应的对文件系统的访问。

　　这一方法提供了最大的灵活性与兼容性，因为每一个应用都被包含在一个支程序及其文件树之中，真正的卡命令，诸如read binary和mutual authenticate都作为程序代码装在支程序中，这使得对单独的一张卡有可能在两个分别的支程序中具有不同的编码和不同的进程而以相互无关的方式支持相同的命令。

　　当然，这一好处是以所提及的支程序的存储空间明显增加为代价的，因为它们必然需要冗余的数据和程序。这项显著的存储量耗费在某些情况下可由允许一个支程序的对象和其他支程序共享（对象共享）而略微减少。这需要在卡中增加管理支程序的命令。为了安全起见，只能在建立了所述的对象的支程序中实现，共享一对象的处理是不能逆转的。这就是说如果一对象可为其他支程序访问应用，则在卡的生命周期中都可被应用，参看图所示。

图 具有java的智能卡的两个基本的计算操作部件

　　欢迎转载，信息来源维库电子市场网（www.dzsc.com）