US20030135792A1 - Language subset validation - Google Patents

Language subset validation Download PDF

Info

Publication number
US20030135792A1
US20030135792A1 US10354954 US35495403A US20030135792A1 US 20030135792 A1 US20030135792 A1 US 20030135792A1 US 10354954 US10354954 US 10354954 US 35495403 A US35495403 A US 35495403A US 20030135792 A1 US20030135792 A1 US 20030135792A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
class
language
java
reference
package
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10354954
Inventor
Zhiqun Chen
Original Assignee
Zhiqun Chen
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/15Directories; Name-to-address mapping
    • H04L61/1552Mechanisms for table lookup, e.g. between directories; Directory data structures; Synchronization of directories
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3624Software debugging by performing operations on the source code, e.g. via a compiler
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44589Program code verification, e.g. Java bytecode verification, proof-carrying code
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/12Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents characterised by the data terminal contains provisionally no documents
    • H04L29/12009Arrangements for addressing and naming in data networks
    • H04L29/12047Directories; name-to-address mapping
    • H04L29/12132Mechanisms for table lookup, also between directories; Directory data structures; Synchronization of directories
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/24Presence management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer, i.e. layer seven

Abstract

A method for language subset validation includes validating multiple program modules that comprise a program. Each of the program modules includes multiple bytecodes defined for a first computer language that is a hardware-dependent subset of a second computer language. The validation includes indicating an error condition for each item in the multiple program modules that is not defined for the first computer language, indicating an error condition for each item in the multiple program modules that is not supported by an execution environment of the first computer language and indicating an error condition for each item in the plurality of program modules that is defined for the first computer language but used in a manner inconsistent with the first computer language. An apparatus for language subset validation includes at least one memory having program instructions and at least one processor configured to use the program instructions to validate multiple program modules that together form a program. The processor is further configured to use the program instructions to indicate an error condition for each item in the multiple program modules that is not defined for the first computer language, indicate an error condition for each item in the multiple program modules that is not supported by an execution environment of the first computer language and indicate an error condition for each item in the plurality of program modules that is defined for the first computer language but used in a manner inconsistent with the first computer language.

Description

    CROSS REFERENCE TO RELATED APPLICATIONS
  • [0001]
    This application is related to the following:
  • [0002]
    U.S. patent application filed Feb. 2, 1999, Susser and Schwabe, entitled OBJECT-ORIENTED INSTRUCTION SET FOR RESOURCE-CONSTRAINED DEVICES.
  • [0003]
    U.S. patent application filed Apr. 15, 1997, Levy and Schwabe, entitled VIRTUAL MACHINE WITH SECURELY DISTRIBUTED BYTECODE VERIFICATION.
  • [0004]
    U.S. patent application filed Nov. 12, 1999, Chen and Schwabe, entitled OPTIMIZATION OF N-BASE TYPED AR TIC EXPRESSIONS.
  • BACKGROUND OF THE INVENTION
  • [0005]
    1. Field of the Invention
  • [0006]
    The present invention relates to computer systems. More particularly, the present invention relates to language subset validation.
  • [0007]
    2. Background
  • [0008]
    Object oriented programming techniques such as those used by the Java™ platform are widely used. The basic unit of object oriented programs is the object which has methods (procedures) and fields (data), herein called members. Objects that share members are grouped into classes. A class defines the shared members of the objects in the class. Each object then is a particular instance of the class to which it belongs. In practice, a class is often used as a template to create multiple objects (multiple instances) with similar features.
  • [0009]
    One property of classes is encapsulation, which describes the property that the actual implementation of the members within the class is hidden from an outside user, and other classes, except as exposed by an interface. This makes classes suitable for distributed development, for example by different developers at different sites on a network. A complete program can be formed by assembling the classes that are needed, linking them together, and executing the resulting program.
  • [0010]
    Classes enjoy the property of inheritance. Inheritance is a mechanism that enables one class to inherit all of the members of another class. The class that inherits from another class is called a subclass; the class that provides the attributes is the superclass. Symbolically, this can be written as subclass <=superclass, or superclass => subclass. The subclass can extend the capabilities of the superclass by adding additional members. The subclass can override a virtual method of the superclass by providing a substitute method with the same name and type.
  • [0011]
    The members of a class type are fields and methods; these include members inherited from the superclass. The class file also names the superclass. A member can be public, which means that it can be accessed by members of the class that contains its declaration. A member can also be private. A private field of a class is visible only in methods defined within that class. Similarly, a private method may only be invoked by methods within the class. Private members are not visible within subclasses, and are not inherited by subclasses as other members are. A member can also be protected.
  • [0012]
    An interface type is a type whose members are constants and abstract methods. This type has no implementation but otherwise unrelated classes can implement it by providing implementations for its abstract methods. Interfaces may have sub-interfaces, just as classes may have subclasses. A sub-interface inherits from its super-interface, and may define new methods and constants as well. Additionally, an interface can extend more than one interface at a time. An interface that extends more than one interface inherits all the abstract methods and constants from each of those interfaces, and may define its own additional methods and constants.
  • [0013]
    In the Java™ programming language, classes can be grouped and the group can be named; the named group of classes is a package. If a class member is not declared with any of the public, private or protected keywords, then it is visible only within the class that defines it and within classes that are part of the same package. A protected member may be accessed by members of declaring class or from anywhere in the package in which it is declared. The Java™ programming language is described in detail in Gosling, et al., “The Java™ Language Specification”, August 1996, Addison-Wesley Longman, Inc.
  • [0014]
    A virtual machine is an abstract computing machine generated by a software application or sequence of instructions that is executed by a processor. The term “architecture-neutral” refers to programs, such as those written in the Java™ programming language, which can be executed by a virtual machine on a variety of computer platforms having a variety of different computer architectures. Thus, for example, a virtual machine implemented on a Windows™-based personal computer system will execute an application using the same set of instructions as a virtual machine implemented on a UNIX™-based computer system. The result of the platform-independent coding of a virtual machine's sequence of instructions is a stream of one or more bytecodes, each of which is, for example, a one-byte-long numerical code.
  • [0015]
    The Java™ Virtual Machine is one example of a virtual machine. Compiled code to be executed by the Java™ Virtual Machine is represented using a hardware- and operating system-independent binary format, typically stored in a file, known as the class file format. The class file is designed to handle object oriented structures that can represent programs written in the Java™ programming language, but may also support several other programming languages. The class file format precisely defines the representation of a class or interface, including details such as byte ordering that might be taken for granted in a platform-specific object file format. For the sake of security, the Java™ Virtual Machine imposes strong format and structural constraints on the instructions in a class file. Any language with functionality that can be expressed in terms of a valid class file can be hosted by the Java™ Virtual Machine. The class file is designed to handle object oriented structures that can represent programs written in the Java™ programming language, but may also support several other programming languages. The Java™ Virtual Machine is described in detail in Lindholm, et al., “The Java™ Virtual Machine Specification”, April 1999, Addison-Wesley Longman, Inc., Second Edition.
  • [0016]
    Resource-constrained devices are generally considered to be those that are relatively restricted in memory and/or computing power or speed, as compared to typical desktop computers and the like. Other resource-constrained devices include, by way of example, cellular telephones, boundary scan devices, field programmable devices, personal digital assistants (PDAs) and pagers and other miniature or small footprint devices. The invention can also be used on non-resource constrained devices.
  • [0017]
    For the purposes of this disclosure, the term “processor” may be used to refer to a physical computer or a virtual machine.
  • [0018]
    Smart cards, also known as intelligent portable data-carrying cards, are a type of resource-constrained device. Smart cards are made of plastic or metal and have an electronic chip that includes an embedded microprocessor or microcontroller to execute programs and memory to store programs and data. Such devices, which can be about the size of a credit card, have computer chips with 8-bit or 16-bit architectures. Additionally, these devices typically have limited memory capacity. For example, some smart cards have less than one kilo-byte (1K) of random access memory (RAM) as well as limited read only memory (ROM), and/or non-volatile memory such as electrically erasable programmable read only memory (EEPROM).
  • [0019]
    A Java™ virtual machine executes programs written in the Java™ programming language and is designed for use on desktop computers, which are relatively rich in memory. It would be desirable to write programs that use the full implementation of the Java™ Virtual Machine for execution on resource constrained devices such as smart cards. However, due to the limited architecture and memory of resource-constrained devices such as smart cards, the full Java™ Virtual Machine platform cannot be implemented on such devices. Accordingly, a separate Java Card™ (the smart card that supports the Java™ programming language) technology supports a subset of the Java™ programming language for resource-constrained devices.
  • [0020]
    Some items supported in Java™ technology are not supported in Java Card™ technology. For example, Java™ technology supports types char, double, float and long, but Java Card™ technology does not. Additionally, some Java™ language features are supported in a limited fashion., Java Card™ technology limits the range of operations of these features to less than that of the Java™ technology. For example, Java™ technology allows arrays having more than one dimension, while the Java Card™ technology allows arrays having only one dimension.
  • [0021]
    In Java Card™ technology, a Java Card™ converter takes regular class files as input and converts them to a CAP (converted applet) file. The CAP format supports a subset of the class file information. Each CAP file contains all of the classes and interfaces defined in one Java™ package. A CAP file has a compact and optimized format, so that a Java™ package can be efficiently stored and executed on resource-constrained devices. After conversion, the CAP file is installed on the Java Card™ technology enabled device.
  • [0022]
    The existence of a subset of the Java™ language for Java Card™ technology means that valid Java™ program modules including items not supported by the Java Card™ subset may be created. Execution of these program modules on resource-constrained devices may produce erroneous results. Accordingly, a need exists in the prior art for a method and apparatus for language subset validation that facilitates correct execution of applications on resource-constrained devices.
  • SUMMARY OF THE INVENTION
  • [0023]
    A method for language subset validation includes validating multiple program modules that comprise a program. Each of the program modules includes multiple bytecodes defined for a first computer language that is a hardware-dependent subset of a second computer language. The validation includes indicating an error condition for each item in the multiple program modules that is not defined for the first computer language, indicating an error condition for each item in the multiple program modules that is not supported by an execution environment of the first computer language and indicating an error condition for each item in the plurality of program modules that is defined for the first computer language but used in a manner inconsistent with the first computer language. An apparatus for language subset validation includes at least one memory having program instructions and at least one processor configured to use the program instructions to validate multiple program modules that together form a program. The processor is further configured to use the program instructions to indicate an error condition for each item in the multiple program modules that is not defined for the first computer language, indicate an error condition for each item in the multiple program modules that is not supported by an execution environment of the first computer language and indicate an error condition for each item in the plurality of program modules that is defined for the first computer language but used in a manner inconsistent with the first computer language.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0024]
    [0024]FIG. 1A is a block diagram that illustrates the relationship between a language and a language subset at the source level.
  • [0025]
    [0025]FIG. 1B is a block diagram that illustrates the relationship between a language and a language subset at the class file level.
  • [0026]
    [0026]FIG. 2 is a flow diagram that illustrates a method for performing language subset validation in accordance with one embodiment of the present invention.
  • [0027]
    [0027]FIG. 3 is a flow diagram that illustrates performing static validation in accordance with one embodiment of the present invention.
  • [0028]
    [0028]FIG. 4A is a flow diagram that illustrates performing static validation on methods in accordance with one embodiment of the present invention.
  • [0029]
    [0029]FIG. 4B is a flow diagram that illustrates performing static validation on method bytecode in accordance with one embodiment of the present invention.
  • [0030]
    [0030]FIG. 5 is a flow diagram that illustrates performing static validation on fields in accordance with one embodiment of the present invention.
  • [0031]
    [0031]FIG. 6 is a flow diagram that illustrates performing method-based validation in accordance with one embodiment of the present invention.
  • [0032]
    [0032]FIG. 7 is a flow diagram that illustrates performing package-based validation in accordance with one embodiment of the present invention.
  • [0033]
    [0033]FIG. 8 is a flow diagram that illustrates validating methods in a package in accordance with one embodiment of the present invention.
  • [0034]
    [0034]FIG. 9A is a flow diagram that illustrates validating classes in a package in accordance with one embodiment of the present invention.
  • [0035]
    [0035]FIG. 9B is a block diagram that illustrates counting the number of implemented interfaces in accordance with one embodiment of the present invention.
  • [0036]
    [0036]FIG. 9C is a block diagram that illustrates counting the number of inherited interfaces in accordance with one embodiment of the present invention.
  • [0037]
    [0037]FIG. 10A is a flow diagram that illustrates validating class access control in accordance with one embodiment of the present invention.
  • [0038]
    [0038]FIG. 10B is a flow diagram that illustrates determining whether a package default method has been made a public and protected method in accordance with one embodiment of the present invention.
  • [0039]
    [0039]FIG. 11 is a flow diagram that illustrates validating package limitations in accordance with one embodiment of the present invention.
  • [0040]
    [0040]FIG. 12 is a flow diagram that illustrates performing card-based validation in accordance with one embodiment of the present invention.
  • DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS
  • [0041]
    Those of ordinary skill in the art will realize that the following description of the present invention is illustrative only. Other embodiments of the invention will readily suggest themselves to such skilled persons having the benefit of this disclosure.
  • [0042]
    This invention relates to computer systems. More particularly, the present invention relates to language subset validation. The invention further relates to machine readable media on which are stored (1) the layout parameters of the present invention and/or (2) program instructions for using the present invention in performing operations on a computer. Such media includes by way of example magnetic tape, magnetic disks, optically readable media such as CD ROMs and semiconductor memory such as PCMCIA cards. The medium may also take the form of a portable item such as a small disk, diskette or cassette. The medium may also take the form of a larger or immobile item such as a hard disk drive or a computer RAM.
  • [0043]
    [0043]FIGS. 1A and 1B illustrate the relationship between language and language subset features supported at both the high-level language source and class file levels; Turning now to FIG. 1A, a block diagram that illustrates the relationship between a language and a language subset at the language source level is presented. Java Card™ technology supports a subset of the Java™ language as represented by reference numeral 100. Java Card™ technology also limits the range of operations for some supported Java™ language features, as represented by reference numeral 102. Furthermore, some Java™ features are optionally supported by a particular Java Card™ Virtual Machine. These optional features are represented by reference numeral 104. Features supported by Java™ technology but not supported by Java Card™ technology are represented by reference numeral 106.
  • [0044]
    Turning now to FIG. 1B, a block diagram that illustrates the relationship between a language and a language subset at the class file level is presented. Java Card™ technology supports a subset of the information contained in a Java™ class file as represented by reference numeral 110. Java Card™ technology also limits the range of operations for some supported Java™ features, and these limitations can be checked at the class file level as represented by reference numeral 112. Furthermore, Java™ features that are optionally supported by a particular Java Card™ Virtual Machine can also be checked at the class file level. These optional features are represented by reference numeral 114. Features supported by Java™ technology but not supported by Java Card™ technology may also be checked at the class file level and are represented by reference numeral 116. Thus, FIG. 1B shows that there is a direct relationship between language features supported at the source level and language features supported at the class file level. Furthermore, by checking at the class file level, it is possible to determine whether programs written at the high level language source level used features that are not defined by the Java Card™ technology.
  • [0045]
    According to the present invention, instruction-level program files in a system employing a language subset are validated against the language subset. Unsupported items are detected and items that are supported in a limited fashion are checked to determine whether they are used properly. Additionally, the particular execution environment is checked to determine whether it supports optional features. If the execution environment supports optional features, the instruction-level program files are checked to determine whether the optional feature is used properly. If the execution environment does not support optional features, the instruction-level program files are checked to determine whether the unsupported optional features are used. The process proceeds in multiple stages, providing a relatively through validation.
  • [0046]
    Throughout this disclosure, the invention is illustrated with respect to Java™ technology and Java Card™ technology. However, those of ordinary skill in the art will recognize that the invention is applicable to other platforms as well. Moreover, those of ordinary skill in the art will recognize that the invention may be applied to different types of validation for a language subset.
  • [0047]
    Turning now to FIG. 2, a method for performing language subset validation in accordance with one embodiment of the present invention is presented. At reference numeral 130, static validation is performed. For the purposes of this disclosure, the term “static validation” refers to validation that may be performed by inspecting class files alone, without reference to other program units or the program execution state. In static validation, unsupported features are detected. In addition, optional features are validated. At reference numeral 135, method-based validation is performed. In method-based validation, data flow analysis is performed on instructions in methods to check intermediate values of arithmetic operations. This stage is used to detect possible overflow conditions. At reference numeral 140, package-based validation is performed. In package-based validation, supported features with limited ranges are detected. At reference numeral 145, card-based validation is performed. In card-based validation, the total amount of memory used by all programs is checked to determine whether the programs exceed the memory constraints of a target device.
  • [0048]
    Turning now to FIG. 3, a flow diagram that illustrates performing static validation in accordance with one embodiment of the present invention is presented. At reference numeral 160, a class file is received. At reference numeral 165, static validation is performed on fields. At reference numeral 170, static validation is performed on methods. At reference numeral 175, a check is made to determine whether another class file remains to be validated. If there is another class file, execution continues at reference numeral 160. This process continues until all class files have been validated.
  • [0049]
    Turning now to FIG. 4, a flow diagram that illustrates performing static validation on methods in accordance with one embodiment of the present invention is presented. At reference numeral 190, a method is received. At reference numeral 192, a check is made to determine whether the method declaration is supported by the language subset. In Java Card™ technology, parameter types, return types and access flags are checked to determine whether they are valid. For example, character string, long, double and float types are supported by Java™ technology, but the types are not supported by Java Card™ technology. Additionally, Java™ technology supports the “synchronized” and “native” access flags, but Java Card™ technology does not. If a type or access flag is not supported, an error is indicated at reference numeral 194.
  • [0050]
    If the method declaration is supported, a check is made at reference numeral 196 to determine whether a particular execution environment supports an optional feature. In Java Card™ technology, the type int is an example of an optional feature. A particular execution environment (the Java Card™ Virtual Machine) determines whether the option is supported. If the execution environment does not support an optional feature, a check is made at reference numeral 198 to determine whether the method declaration includes an optional feature. If the method declaration includes an optional feature, an error is indicated at reference numeral 194. At reference numeral 200, the bytecode of the method is validated. At reference numeral 202, a check is made to determine whether another method remains to be validated. If there is another method, execution continues at reference numeral 190. This process continues until all methods in the class file have been validated.
  • [0051]
    Turning now to FIG. 4B, a flow diagram that illustrates validating the bytecode of a method in accordance with one embodiment of the present invention is illustrated. At reference numeral 210, a bytecode is received. At reference numeral 212, a determination is made regarding whether the bytecode is supported by the language subset. The bytecode is checked to determine whether unsupported data types are used, and whether operations on values of unsupported data types are used. The bytecode is also checked to determine whether unsupported features are used. For example, threads are not supported in Java Card™ technology. The keyword “synchronized” indicates the use of monitors to synchronize threads and this keyword has a particular bytecode representation. Its presence in the bytecode indicates the use of a monitor.
  • [0052]
    If the bytecode is not supported or is used to operate on data of unsupported types, an error is indicated at reference numeral 214. If the bytecode is supported, a check is made at reference numeral 216 to determine whether the particular execution environment supports options. If the execution environment does not support options, a check is made at reference numeral 218 to determine whether the checked bytecode represents an optional feature. If the checked bytecode represents an optional feature, an error is indicated at reference numeral 214. At reference numeral 220, a check is made to determine whether more bytecodes remain in the method. If more bytecodes remain, execution continues at reference numeral 210. This process continues until all bytecodes in a method have been checked.
  • [0053]
    Turning now to FIG. 5, a flow diagram that illustrates performing static validation on fields in accordance with one embodiment of the present invention is presented. Static validation on fields is performed in a manner similar to static validation on methods. In Java Card™ technology, invalid access flags of fields include by way of example “volatile” and “transient”. An error is indicated if a field declaration uses unsupported types and access flags. An error is also indicated if a field declaration uses optional features, such as type int in Java Card™ technology, is not supported by the execution environment.
  • [0054]
    The Java™ Virtual Machine instruction set defines an instruction set to handle values of integral types byte, short and int. The variables of type byte and short are widened to the integral type int during compilation. Therefore, the values computed are also 32-bit int values. However, the Java Card™ virtual machine defines a separate instruction set to handle variables of types byte and short in addition to the instruction set to handle variables of integral type int.
  • [0055]
    Support of the 32-bit int type on Java Card™ platforms is optional. Target platforms that do not support the 32-bit int type cannot use 32-bit int type variables. Also, the 32-bit arithmetic bytecode used in the Java™ class files must be converted to a 16-bit instruction used in the Java Card™ instruction set. Consequently, values computed by 16-bit instruction are 16-bit int values. This conversion may create the potential for overflow that extends beyond the 16-bit representation. Erroneous results may be created if values that carry the potential for overflow are fed into an instruction that is sensitive to overflow or if it is used as an array index. Determining whether the potential for overflow exists includes generating a data flow. The details of this process of determining when the potential for overflow exists are discussed in U.S. patent application filed Nov. 15, 1999, Chen and Schwabe, entitled OPTIMIZATION OF N-BASE TYPED ARITHMETIC EXPRESSIONS, and will not be discussed further to prevent obfuscation of the present invention.
  • [0056]
    Turning now to FIG. 6, a flow diagram that illustrates performing method-based validation in accordance with one embodiment of the present invention is presented. In method-based validation, methods are analyzed to determine whether potential overflow conditions exist. At reference numeral 270, a method is received. At reference numeral 275, the method is checked for potential overflow conditions.
  • [0057]
    At reference numeral 285, local variable types are validated. In Java Card™ technology, a compilation directive determines whether the compiler generates a local variable attribute table as part of the code generation process. The local variable attribute variable includes type information for local variables. If the local variable attribute table is present, validation local variables for valid types may be performed in the “static validation” stage discussed above. If the local variable attribute table is not present, the data flow is used at this stage to determine the type of local variables. An error is indicated if any local variable has an unsupported type or an optional type that is not supported by the target device.
  • [0058]
    At reference numeral 290, a check is made to determine whether another method remains to be validated. If another method remains, execution continues at reference numeral 270. This process continues until all methods in the class file have been validated.
  • [0059]
    Turning now to FIG. 7, a flow diagram that illustrates performing package-based validation in accordance with one embodiment of the present invention is presented. In package-based validation, supported features with limited ranges are detected. At reference numeral 300, the class files comprising a package are received. At reference numeral 305, methods within the package are validated. At reference numeral 310, classes within the package are validated. At reference numeral 315, package limitations are validated.
  • [0060]
    Turning now to FIG. 8, a flow diagram that illustrates validating methods in a package in accordance with one embodiment of the present invention is presented. At reference numeral 330, a method is received. At reference numeral 335, a check is made to determine whether the total number of variables and parameters exceeds a predetermined number. In Java Card™ technology, the total number of variables and parameters cannot exceed 255. If the total number exceeds the predetermined number, an error is indicated at reference numeral 350. At reference numeral 337, the Java bytecodes are converted to Java Card™ bytecodes. At reference numeral 340, a check is made to determine whether the total number of Java Card™ bytecodes within the method exceed a predetermined number. In Java Card™ technology, the total number of Java Card™ bytecodes cannot exceed 32,767. If the number of bytecodes exceeds the limit, an error is indicated at reference numeral 355. At reference numeral 365, a check is made to determine whether all methods in a package have been validated. If another method remains, execution continues at reference numeral 330. This process continues until all methods have been validated.
  • [0061]
    Turning now to FIG. 9A, a flow diagram that illustrates validating classes and interfaces in a package in accordance with one embodiment of the present invention is presented. At reference numeral 380, a class file is received. At reference numeral 382, the number of instance fields within the class is validated. In Java Card™ technology, the total number of instance fields per class must not exceed 255. This number includes fields declared in the class and all instance fields declared in each superclass of the class. Typically, information about fields within a superclass is not contained within the class file for the subclass. Therefore, the class file for the superclass must be read to determine the number of instance fields in the superclass. This process continues in a recursive fashion until the root superclass has been examined. The total number of instance fields obtained this way is then compared to the maximum number of instance fields.
  • [0062]
    At reference numeral 384, the number of static fields is checked. In Java Card™ technology, the total number of public and protected static fields per class cannot exceed 256. Unlike instance fields, there exists only one incarnation of a static field. Thus, the maximum number for static fields does not apply to static fields in each superclass of the class.
  • [0063]
    At reference numeral 386, the number of instance methods is checked. In Java Card™ technology, the total number of package visible instance methods must not exceed 128, and the total number of public and protected instance methods must not exceed 128. These numbers include methods declared in the class and all methods declared in each superclass of the class. Typically, information about methods within a superclass is not contained within the class file for the subclass. Therefore, the class file for the superclass must be read to determine the number of instance methods in the superclass. For public and protected instance methods, this process continues in a recursive fashion until the root superclass has been examined. For package visible methods, the recursion continues until all super classes within the checked package have been examined. Lastly, any duplicates are removed.
  • [0064]
    At reference numeral 388, the number of static methods is checked. In Java Card™ technology, the total number of public and protected static methods must not exceed 256. Unlike instance methods, there is only one incarnation of a static method within a class. Thus, the maximum number for static methods does not apply to static methods in each superclass of the class type.
  • [0065]
    At reference numeral 390, the class access control is validated. This validation determines whether a public interface improperly extends a package visible interface, and whether the access visibility of a package default method in a superclass is improperly changed to public or protected in a subclass.
  • [0066]
    At reference numeral 392, a check is made to determine whether the class or the interface has more than a predetermined number of superinterfaces. In Java Card™ technology, the maximum number of superinterfaces is 15. If the class file represents a class, the superinterfaces of this class include interfaces directly implemented by this class and superinterfaces of each directly implemented interface, as well as interfaces implemented by any superclasses. Thus, the total number of superinterfaces is determined by recursively visiting each superinterface and superclass until all interfaces are counted. The number of interfaces remaining after duplicates have been removed is compared to the maximum number of implemented interfaces.
  • [0067]
    If the class file represents an interface, the superinterfaces of this checked interface include interfaces that are directly inherited by this interface and superinterfaces of each direct superinterface. Thus, the total number of superinterfaces is determined by recursively determining which interfaces each interface and its superinterfaces inherit from. The number of interfaces remaining after duplicates have been removed is compared to the maximum number of inheritable interfaces.
  • [0068]
    At reference numeral 396, a determination is made regarding whether more class files remain to be validated. If more classes remain, execution continues at reference numeral 380. This process continues until all classes have been validated.
  • [0069]
    Turning now to FIG. 9B, a block diagram that illustrates counting the number of superinterfaces of a class in accordance with one embodiment of the present invention is presented. Three classes are represented by C1 400, C2 402 and C3 404. Three interfaces are represented by I1 406, I2 408 and I3 410. Class C3 and interface I3 are in package B 414, while the other members are in package A 412. Starting with Class C1, the number of interfaces directly implemented by the class and all their superinterfaces is added to the number of interfaces implemented by the superclass of that class and duplicates are removed. Here, first interfaces implemented by C1 is examined. Class C1 implements I1. I1 inherits I2. Thus, I1 and I2 are counted. If I2 also inherits any interfaces, those interfaces are also counted. Next, the super class of C1 is examined. Class C1 extends from C2. Class C2 does not implement any interfaces but extends C3. Class C3 implements (I2, I3). Thus, class C2 also implements (I2 and I3). Moving back to class C1, class C1 implements interface I1 and the interface I1's superinterface I2, and interfaces implemented by its super class C2. Therefore, C1 implements (I1, I2)+(I2, I3). After removing duplicates, C1 implements three interfaces: (I1, I2)+(I12, I13)=(I1, I2, I3). This number is less than the maximum number for Java Card™ technology.
  • [0070]
    Turning now to FIG. 9C, a block diagram that illustrates counting the number of superinterfaces of an interface in accordance with one embodiment of the present invention is presented. Five interfaces are represented by I1 416, I2 418, I3 420, I4 422 and I5 424. Interfaces I4 and I5 are located in package D 428 and the other interfaces are in a separate package C 426. Interface I1 extends from I2 and I3, so Interface I1 has superinterface I2 and I3. In addition, interface I1 inherits from whatever I2 inherits from and from whatever I3 inherits from. As shown in FIG. 9C, I3 extends from I2, and I4, I4 extends from I5 and I5 extends from I2. Thus, I4 inherits from (I2)+(I5)=(I2, I5). I3 inherits from (I4)+(I2, I5)+(I2)=(I2, I4, I5). Accordingly, I1 inherits from (I2)+(I3)+(I2, I4, I5). After duplicates are removed, I1 inherits from four interfaces: (I2, I3, I4, I5). This number is less than the maximum number for Java Card™ technology.
  • [0071]
    Turning now to FIG. 10A, a flow diagram that illustrates validating access control in accordance with one embodiment of the present invention is presented. Since a class file can represent either a class or an interface, whether the examined class file contains an interface is checked at reference numeral 430. If the class file represents an interface, whether the interface is public is checked at reference numeral 431. In Java Card™ technology, a public interface must not extend a package visible interface. Since an interface may extend at least one superinterface, this determination requires examining each superinterface within a package to determine whether any of the interfaces in the chain is a package visible interface.
  • [0072]
    If the interface is public, a check is made to determine whether the current interface extends any interfaces at reference numeral 432. If the current interface directly inherits an interface, the interface is received at reference numeral 434. At reference numeral 436, a determination is made regarding whether the direct superinterface has package default visibility. A direct superinterface is an interface immediately inherited by the current interface. If the direct superinterface has package default visibility, an error is indicated at reference numeral 438. If the direct superinterface does not have package default visibility, a check is made at reference numeral 440 to determine whether another superinterface remains. If there is another superinterface, execution continues at reference numeral 434.
  • [0073]
    Java Card™ technology also provides that the access visibility of a package default method in a superclass must not be changed to public and protected in a subclass. This is checked beginning at reference numeral 442. If the current class file represents a class, a determination is made at reference numeral 442 regarding whether the current class has a superclass. If the current class has a superclass, a public or protected method of the current class is received at reference numeral 444. At reference numeral 446, the method is checked to determine whether the method is also defined in the superclass that has package default visibility. At reference numeral 448, a determination is made regarding whether there are more public or protected methods in the current class. If there are more, execution continues at reference numeral 444. This process continues until all public and protected methods in the current class have been examined.
  • [0074]
    Turning now to FIG. 10B, a flow diagram that illustrates determining whether a package default method has been made a public and protected method in accordance with the present invention is presented. At reference numeral 460, a check is made to determine whether the current class has a superclass in the same package. If the current class has a superclass in the same package, a determination is made at reference numeral 462 regarding whether the method is also defined in the superclass but has package default visibility. If the corresponding method has package default visibility in the superclass, an error is indicated at reference numeral 464. If the corresponding method is not defined in the superclass or does not have package default visibility, the current class is set to the superclass of the current class and the process is repeated, starting at reference numeral 460. This process of checking methods continues in a recursive fashion until reaching the root of the superclass or the package boundary.
  • [0075]
    Turning now to FIG. 11, a flow diagram that illustrates validating package limitations in accordance with one embodiment of the present invention is presented. At reference numeral 476, the number of classes and interfaces defined in the package is checked. In Java Card™ technology, the maximum number of classes and interfaces in a package is 255. If the number exceeds the maximum, an error is indicated at reference numeral 478. At reference numeral 480, a determination is made regarding whether the number of packages imported by this checked package is greater than a predetermined number. In Java Card™ technology, a package cannot import more than 128 packages.
  • [0076]
    At reference numeral 490, CAP file component sizes are validated after class files in a package are converted into a CAP file. In Java Card™ technology, a CAP file consists of a set of components. Each component describes a set of elements in the Java™ package defined, or an aspect of the CAP file. All components have the following general format:
    component {
    u1 tag
    u2 size
    u1 info[]
    }
  • [0077]
    The “size” item indicates the number of bytes in the “info” array component. The maximum size represented by the size component is 64K bytes. The content and format of the info array varies with the type of component. One type of component is the method component. The method component has the following general format:
    method_component {
    u1 tag
    u2 size
    .
    .
    method_info methods[]
    }
  • [0078]
    The methods array may contain multiple methods, and each method is less than 32K bytes. However, it is possible for total number of bytes used for all methods to exceed the 64K limitation. Accordingly, the number of bytes within each component is summed and the total is compared to the maximum size (64K). If the total is greater than the limit, an error is indicated at reference numeral 495.
  • [0079]
    In the Java Card technology, an “export” file is a binary file that contains all publicly accessible information of a Java package. According to another embodiment of the present invention, at the stage of performing package-based validation, checks to a super class or a super interface are performed by checking an “export” file, which represents the package that defines the superclass or the superinterface. This export file is used instead of the class file of the super class or the super interface. However, because the export file only contains publicly accessible information, Package default classes and interfaces, and package default and private methods and fields are not included. Therefore, some checks in the package-based validation will need to be deferred until card-based validation because not enough information is available
  • [0080]
    As an example of deferring checks until card-based validation, an accurate count of the number of superinterfaces requires that both package and public visible interfaces be included. Since export files contain only publicly accessible information, package visible interfaces are not included. Thus, if the number of public superinterfaces was determined during package-based validation to be less than the maximum amount, the number of public and package visible interfaces would have to be repeated later in card-based validation, when information about package visible interfaces was available. However, if a count of the number of public superinterfaces was greater than the maximum amount, further evaluation would be unnecessary because the maximum amount of superinterfaces has already been exceeded.
  • [0081]
    Another case where deferring checks until card-based validation may be required is counting the number of instance fields in a class. Since the private and package default instance fields in superclasses are not available in export files, an accurate count can not be obtained. Thus, the number of instance fields in a class must be recounted later in card-based validation when information of all classes is available.
  • [0082]
    According to another embodiment of the present invention, the validation performed in the package-based validation is deferred until the card-based validation described below. In this case, the validation is performed when information of all classes on the card is available.
  • [0083]
    Turning now to FIG. 12, a flow diagram that illustrates performing card-based validation in accordance with one embodiment of the present invention is presented. At reference numeral 500, the class files or CAP files needed for an executable runtime image are received. At reference numeral 505, the memory usage for all program units within the executable image are summed. At reference numeral 510, the calculated memory usage is compared to a maximum amount. If the total memory usage is greater than the maximum defined for the executable image, an error is indicated at reference numeral 515. In Java Card™ technology, all program units must fit within a 64K boundary, which is the memory space that will be referenced by the Java Card™ Virtual Machine.
  • [0084]
    Although the present invention has been illustrated with respect to Java Card™ technology, those of ordinary skill in the art will recognize that the invention is applicable to many other platforms. These platforms include, by way of example, K Virtual Machine (KVM) technology. KVM technology is described in “The K Virtual Machine (KVM)—A White Paper”, Jun. 8, 1999, Sun Microsystems, Inc.
  • [0085]
    The present invention may be implemented in software or firmware, as well as in programmable gate array devices, Application Specific Integrated Circuits (ASICs), and other hardware.
  • [0086]
    Thus, a novel method for language subset validation has been described. While embodiments and applications of this invention have been shown and described, it would be apparent to those skilled in the art having the benefit of this disclosure that many more modifications than mentioned above are possible without departing from the inventive concepts herein. The invention, therefore, is not to be restricted except in the spirit of the appended claims.

Claims (26)

    What is claimed is:
  1. 1. A method for language subset validation, comprising:
    validating a plurality of program modules comprising a program, each of said program modules including a plurality of bytecodes defined for a first computer language, said first computer language being a hardware-dependent subset of a second computer language, said validating including:
    indicating an error condition for each item in said plurality of program modules that is not defined for said first computer language;
    indicating an error condition for each item in said plurality of program modules that is not supported by an execution environment of said first computer language; and
    indicating an error condition for each item in said plurality of program modules that is defined for said first computer language but used in a manner inconsistent with said first computer language.
  2. 2. The method of claim 1 wherein
    said program modules comprise class files; and
    said validating further comprises:
    determining memory usage by summing code and data usage for all of said program modules; and
    indicating an error condition when said memory usage exceeds a maximum memory usage.
  3. 3. The method of claim 1 wherein
    said program modules comprise CAP files; and
    said validating further comprises:
    determining memory usage by summing code and data usage for all of said program modules; and
    indicating an error condition when said memory usage exceeds a maximum memory usage.
  4. 4. The method of claim 2 wherein said validating further comprises:
    reading each method within said class files;
    indicating an error when a method declaration is not supported by said first computer language; and
    indicating an error when said execution environment does not support an optional feature of said first computer language and said method declaration includes said optional feature.
  5. 5. The method of claim 4 wherein said validating further comprises:
    indicating an error when a field declaration is not supported by said first computer language; and
    indicating an error when said execution environment does not support an optional feature of said first computer language and said field declaration includes said optional feature.
  6. 6. The method of claim 5 wherein said validating further comprises:
    reading bytecode of each of said methods;
    indicating an error when said bytecode uses data types that are not supported by said first computer language;
    indicating an error when said bytecode operates on values of types that are not supported by said first computer language;
    indicating an error when said execution environment does not support an optional type of said first computer language and said instruction uses said optional type; and
    indicating an error when said execution environment does not support an optional type of said first computer language and said instruction operates on at least one value of said optional type.
  7. 7. The method of claim 4 wherein said validating further comprises:
    generating a data flow for each method within said class files; and
    using said data flow to determine whether the potential for overflow exists in an arithmetic intermediate result within a method, said potential for overflow creating a first final result that is semantically different from a second final result, said first final result obtained when said method is executed against said first computer language, said second final result obtained when said method is executed against said second computer language.
  8. 8. The method of claim 4 wherein said validating further comprises:
    reading at least one class file comprising a package;
    indicating an error when the total number of local variables and parameters within each method of each class in said package exceeds a maximum number of variables and parameters;
    converting all bytecodes within said method according to said first computer language to create converted bytecodes; and
    indicating an error when the total number of converted bytecodes exceeds a maximum number of bytecodes.
  9. 9. The method of claim 8 wherein said validating further comprises:
    indicating an error when the total number of instance fields within each class of said package exceeds a maximum number of instance fields;
    indicating an error when the total number of static fields within each class of said package exceeds a maximum number of static fields;
    indicating an error when the total number of instance methods within each class of said package exceeds a maximum number of instance methods;
    indicating an error when the total number of static methods within each class of said package exceeds a maximum number of static methods; and
    indicating an error when the total number of superinterfaces of each class or each interface of said package exceeds a maximum number of superinterfaces.
  10. 10. The method of claim 9 wherein said validating further comprises:
    indicating an error when a public interface extends a package visible interface within said package; and
    indicating an error when the access visibility of a package default method in a superclass is changed to public or protected in a subclass in within said package.
  11. 11. The method of claim 1 wherein
    said first computer language is defined for a Java Card™ Virtual Machine; and
    said second computer language comprises the Java™ language.
  12. 12. The method of claim 1 wherein
    said first computer language is defined for a Java Card™ Virtual Machine; and
    said second computer language comprises Java™ class files.
  13. 13. A program storage device readable by a machine, embodying a program of instructions executable by the machine to perform a method for language subset validation, the method comprising:
    validating a plurality of program modules comprising a program, each of said program modules including a plurality of bytecodes defined for a first computer language, said first computer language being a hardware-dependent subset of a second computer language, said validating including:
    indicating an error condition for each item in said plurality of program modules that is not defined for said first computer language;
    indicating an error condition for each item in said plurality of program modules that is not supported by an execution environment of said first computer language; and
    indicating an error condition for each item in said plurality of program modules that is defined for said first computer language but used in a manner inconsistent with said first computer language.
  14. 14. The program storage device of claim 13 wherein
    said program modules comprise class files; and
    said validating further comprises:
    determining memory usage by summing code and data usage for all of said program modules; and
    indicating an error condition when said memory usage exceeds a maximum memory usage.
  15. 15. The program storage device of claim 13 wherein
    said program modules comprise CAP files; and
    said validating further comprises:
    determining memory usage by summing code and data usage for all of said program modules; and
    indicating an error condition when said memory usage exceeds a maximum memory usage.
  16. 16. The program storage device of claim 14 wherein said validating further comprises:
    reading each method within said class files;
    indicating an error when a method declaration is not supported by said first computer language; and
    indicating an error when said execution environment does not support an optional feature of said first computer language and said method declaration includes said optional feature.
  17. 17. The program storage device of claim 16 wherein said validating further comprises:
    indicating an error when a field declaration is not supported by said first computer language; and
    indicating an error when said execution environment does not support an optional feature of said first computer language and said field declaration includes said optional feature.
  18. 18. The program storage device of claim 17 wherein said validating further comprises:
    reading bytecode of each of said methods;
    indicating an error when said bytecode uses data types that are not supported by said first computer language;
    indicating an error when said bytecode operates on values of types that are not supported by said first computer language;
    indicating an error when said execution environment does not support an optional type of said first computer language and said instruction uses said optional type; and
    indicating an error when said execution environment does not support an optional type of said first computer language and said instruction operates on at least one value of said optional type.
  19. 19. The program storage device of claim 16 wherein said validating further comprises:
    generating a data flow for each method within said class files; and
    using said data flow to determine whether the potential for overflow exists in an arithmetic intermediate result within a method, said potential for overflow creating a first final result that is semantically different from a second final result, said first final result obtained when said method is executed against said first computer language, said second final result obtained when said method is executed against said second computer language.
  20. 20. The program storage device of claim 16 wherein said validating further comprises:
    reading at least one class file comprising a package;
    indicating an error when the total number of local variables and parameters within each method of each class in said package exceeds a maximum number of variables and parameters;
    converting all bytecodes within said method according to said first computer language to create converted bytecodes; and
    indicating an error when the total number of converted bytecodes exceeds a maximum number of bytecodes.
  21. 21. The program storage device of claim 20 wherein said validating further comprises:
    indicating an error when the total number of instance fields within each class of said package exceeds a maximum number of instance fields;
    indicating an error when the total number of static fields within each class of said package exceeds a maximum number of static fields;
    indicating an error when the total number of instance methods within each class of said package exceeds a maximum number of instance methods;
    indicating an error when the total number of static methods within each class of said package exceeds a maximum number of static methods; and
    indicating an error when the total number of superinterfaces of each class or each interface of said package exceeds a maximum number of superinterfaces.
  22. 22. The program storage device of claim 21 wherein said validating further comprises:
    indicating an error when a public interface extends a package visible interface within said package; and
    indicating an error when the access visibility of a package default method in a superclass is changed to public or protected in a subclass in within said package.
  23. 23. The program storage device of claim 13 wherein
    said first computer language is defined for a Java Card™ Virtual Machine; and
    said second computer language comprises the Java™ language.
  24. 24. The program storage device of claim 13 wherein
    said first computer language is defined for a Java Card™ Virtual Machine; and
    said second computer language comprises Java™ class files.
  25. 25. An apparatus for language subset validation, comprising:
    means for validating a plurality of program modules comprising a program, each of said program modules including a plurality of bytecodes defined for a first computer language, said first computer language being a hardware-dependent subset of a second computer language, said validating including:
    means for indicating an error condition for each item in said plurality of program modules that is not defined for said first computer language;
    means for indicating an error condition for each item in said plurality of program modules that is not supported by an execution environment of said first computer language; and
    means for indicating an error condition for each item in said plurality of program modules that is defined for said first computer language but used in a manner inconsistent with said first computer language.
  26. 26. The apparatus of claim 25 wherein
    said program modules comprise class files; and
    said validating means further comprises:
    means for determining memory usage by summing code and data usage for all of said program modules; and
    means for indicating an error condition when said memory usage exceeds a maximum memory usage.
US10354954 1999-01-22 2003-01-30 Language subset validation Abandoned US20030135792A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US09235940 US6425003B1 (en) 1999-01-22 1999-01-22 Method and apparatus for DNS resolution
US09439645 US6581206B2 (en) 1999-11-12 1999-11-12 Computer program language subset validation
US10354954 US20030135792A1 (en) 1999-01-22 2003-01-30 Language subset validation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10354954 US20030135792A1 (en) 1999-01-22 2003-01-30 Language subset validation

Related Parent Applications (2)

Application Number Title Priority Date Filing Date
US09235940 Continuation US6425003B1 (en) 1999-01-22 1999-01-22 Method and apparatus for DNS resolution
US09439645 Continuation US6581206B2 (en) 1999-11-12 1999-11-12 Computer program language subset validation

Publications (1)

Publication Number Publication Date
US20030135792A1 true true US20030135792A1 (en) 2003-07-17

Family

ID=22887481

Family Applications (2)

Application Number Title Priority Date Filing Date
US09235940 Active US6425003B1 (en) 1999-01-22 1999-01-22 Method and apparatus for DNS resolution
US10354954 Abandoned US20030135792A1 (en) 1999-01-22 2003-01-30 Language subset validation

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09235940 Active US6425003B1 (en) 1999-01-22 1999-01-22 Method and apparatus for DNS resolution

Country Status (1)

Country Link
US (2) US6425003B1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030046613A1 (en) * 2001-09-05 2003-03-06 Eitan Farchi Method and system for integrating test coverage measurements with model based test generation
US20060041792A1 (en) * 2004-08-19 2006-02-23 International Business Machines Corporation Method, system and program for identifying a test specification for testing a file element
US20150186117A1 (en) * 2013-12-26 2015-07-02 International Business Machines Corporation Generating software code

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7188180B2 (en) * 1998-10-30 2007-03-06 Vimetx, Inc. Method for establishing secure communication link between computers of virtual private network
US7010604B1 (en) 1998-10-30 2006-03-07 Science Applications International Corporation Agile network protocol for secure communications with assured system availability
US7418504B2 (en) 1998-10-30 2008-08-26 Virnetx, Inc. Agile network protocol for secure communications using secure domain names
US6502135B1 (en) 1998-10-30 2002-12-31 Science Applications International Corporation Agile network protocol for secure communications with assured system availability
US6324585B1 (en) * 1998-11-19 2001-11-27 Cisco Technology, Inc. Method and apparatus for domain name service request resolution
US7194554B1 (en) 1998-12-08 2007-03-20 Nomadix, Inc. Systems and methods for providing dynamic network authorization authentication and accounting
US8266266B2 (en) 1998-12-08 2012-09-11 Nomadix, Inc. Systems and methods for providing dynamic network authorization, authentication and accounting
US8713641B1 (en) 1998-12-08 2014-04-29 Nomadix, Inc. Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device
US9141717B2 (en) 1999-03-22 2015-09-22 Esdr Network Solutions Llc Methods, systems, products, and devices for processing DNS friendly identifiers
USRE43690E1 (en) 1999-03-22 2012-09-25 Esdr Network Solutions Llc Search engine request method, product, and apparatus
US7188138B1 (en) * 1999-03-22 2007-03-06 Eric Schneider Method, product, and apparatus for resource identifier registration and aftermarket services
US6760746B1 (en) 1999-09-01 2004-07-06 Eric Schneider Method, product, and apparatus for processing a data request
US6880007B1 (en) * 1999-06-07 2005-04-12 Register Com, Inc. Domain manager and method of use
US7058683B1 (en) * 1999-07-20 2006-06-06 Sun Microsystems, Inc. Methods and apparatus for providing a virtual host in electronic messaging servers
US7702732B1 (en) 1999-09-29 2010-04-20 Nortel Networks Limited Methods for auto-configuring a router on an IP subnet
US6857009B1 (en) * 1999-10-22 2005-02-15 Nomadix, Inc. System and method for network access without reconfiguration
US6976258B1 (en) 1999-11-30 2005-12-13 Ensim Corporation Providing quality of service guarantees to virtual hosts
WO2001050688A1 (en) * 1999-12-29 2001-07-12 Telefonaktiebolaget Lm Ericsson (Publ.) Method and system for communication
US6754716B1 (en) 2000-02-11 2004-06-22 Ensim Corporation Restricting communication between network devices on a common network
US7343421B1 (en) * 2000-02-14 2008-03-11 Digital Asset Enterprises Llc Restricting communication of selected processes to a set of specific network addresses
US6948003B1 (en) 2000-03-15 2005-09-20 Ensim Corporation Enabling a service provider to provide intranet services
US6985937B1 (en) 2000-05-11 2006-01-10 Ensim Corporation Dynamically modifying the resources of a virtual server
US6907421B1 (en) 2000-05-16 2005-06-14 Ensim Corporation Regulating file access rates according to file type
US8204082B2 (en) 2000-06-23 2012-06-19 Cloudshield Technologies, Inc. Transparent provisioning of services over a network
US6829654B1 (en) 2000-06-23 2004-12-07 Cloudshield Technologies, Inc. Apparatus and method for virtual edge placement of web sites
US7114008B2 (en) * 2000-06-23 2006-09-26 Cloudshield Technologies, Inc. Edge adapter architecture apparatus and method
US7003555B1 (en) * 2000-06-23 2006-02-21 Cloudshield Technologies, Inc. Apparatus and method for domain name resolution
US7032031B2 (en) * 2000-06-23 2006-04-18 Cloudshield Technologies, Inc. Edge adapter apparatus and method
US9444785B2 (en) 2000-06-23 2016-09-13 Cloudshield Technologies, Inc. Transparent provisioning of network access to an application
US7165116B2 (en) * 2000-07-10 2007-01-16 Netli, Inc. Method for network discovery using name servers
US6909691B1 (en) 2000-08-07 2005-06-21 Ensim Corporation Fairly partitioning resources while limiting the maximum fair share
DE10051147B4 (en) * 2000-10-16 2005-04-14 Siemens Ag Method of accessing an IP network and to work in this
US7549160B1 (en) 2000-12-21 2009-06-16 Cisco Technology, Inc. Method and system for authenticated access to internet protocol (IP) multicast traffic
US7219354B1 (en) 2000-12-22 2007-05-15 Ensim Corporation Virtualizing super-user privileges for multiple virtual processes
US20030115040A1 (en) * 2001-02-09 2003-06-19 Yue Xing International (multiple language/non-english) domain name and email user account ID services system
US20020129149A1 (en) * 2001-03-06 2002-09-12 Kenneth Schulz Method and system for automatically directing a web user to a selected web server
US6959333B2 (en) * 2001-05-08 2005-10-25 Lucent Technologies Inc. Technique for content delivery over the internet
US7366794B2 (en) * 2001-07-13 2008-04-29 Certicom Corp. Method and apparatus for resolving a web site address when connected with a virtual private network (VPN)
US7139818B1 (en) 2001-10-04 2006-11-21 Cisco Technology, Inc. Techniques for dynamic host configuration without direct communications between client and server
US7636790B1 (en) * 2001-10-25 2009-12-22 Sprint Communications Company L.P. Service-based network packet routing redirection using an address server
US7472201B1 (en) * 2002-09-12 2008-12-30 Cisco Technology, Inc. Method and system for resolving domain name system queries in a multiprotocol communications network
US7130917B2 (en) * 2002-09-26 2006-10-31 Cisco Technology, Inc. Quality of service in a gateway
US7136922B2 (en) * 2002-10-15 2006-11-14 Akamai Technologies, Inc. Method and system for providing on-demand content delivery for an origin server
US7467194B1 (en) 2002-12-20 2008-12-16 Symantec Operating Corporation Re-mapping a location-independent address in a computer network
GB2413742B (en) * 2003-11-05 2006-05-31 Internet Comp Bureau Plc Computer address resolution
CN100375470C (en) * 2003-11-18 2008-03-12 株式会社东芝 Apparatus for and method of setting communication path
US7680954B2 (en) * 2004-03-16 2010-03-16 Thomson Licensing Proxy DNS for web browser request redirection in public hotspot accesses
US8046578B1 (en) * 2004-04-14 2011-10-25 Hewlett-Packard Development Comopany, L.P. System and method for providing HTML authentication using an access controller
US7450531B2 (en) * 2004-10-26 2008-11-11 Cisco Technology, Inc. System and method for allocating and distributing end user information in a network environment
CN1863143A (en) * 2005-08-09 2006-11-15 华为技术有限公司 Method, system and apparatus for implementing Web server access
US20070050507A1 (en) * 2005-08-24 2007-03-01 Nokia Corporation Context discovery for DNS names
DE602006003314D1 (en) * 2006-05-11 2008-12-04 Alcatel Lucent Processing of a DNS service demand
US8977739B2 (en) * 2010-05-03 2015-03-10 Salesforce.Com, Inc. Configurable frame work for testing and analysis of client-side web browser page performance
CN101931663B (en) * 2010-08-28 2014-06-11 中兴通讯股份有限公司 Method capable of dynamically setting domain name server and wireless communication terminal
WO2015100283A1 (en) * 2013-12-23 2015-07-02 Akamai Technologies, Inc. Systems and methods for delivering content to clients that are suboptimally mapped

Citations (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4400769A (en) * 1979-02-21 1983-08-23 Fujitsu Limited Virtual machine system
US5305456A (en) * 1991-10-11 1994-04-19 Security Integration, Inc. Apparatus and method for computer system integrated security
US5408670A (en) * 1992-12-18 1995-04-18 Xerox Corporation Performing arithmetic in parallel on composite operands with packed multi-bit components
US5446901A (en) * 1993-06-30 1995-08-29 Digital Equipment Corporation Fault tolerant distributed garbage collection system and method for collecting network objects
US5493675A (en) * 1991-02-27 1996-02-20 Digital Equipment Corporation Compiler back end calling predetermined front end routines that use effect and dependency indicators to provide information to the compiler to determine the validity of an optimization
US5668999A (en) * 1994-12-20 1997-09-16 Sun Microsystems, Inc. System and method for pre-verification of stack usage in bytecode program loops
US5724279A (en) * 1995-08-25 1998-03-03 Microsoft Corporation Computer-implemented method and computer for performing modular reduction
US5732263A (en) * 1995-10-03 1998-03-24 International Business Machines Corporation Systems, methods and computer program products for generating and validating user defined object classes in an object oriented programming environment after build time
US5740441A (en) * 1994-12-20 1998-04-14 Sun Microsystems, Inc. Bytecode program interpreter apparatus and method with pre-verification of data type restrictions and object initialization
US5757918A (en) * 1995-01-20 1998-05-26 Tandem Computers Incorporated Method and apparatus for user and security device authentication
US5784553A (en) * 1996-01-16 1998-07-21 Parasoft Corporation Method and system for generating a computer program test suite using dynamic symbolic execution of JAVA programs
US5794049A (en) * 1996-06-05 1998-08-11 Sun Microsystems, Inc. Computer system and method for executing architecture specific code with reduced run-time memory space requirements
US5838965A (en) * 1994-11-10 1998-11-17 Cadis, Inc. Object oriented database management system
US5844218A (en) * 1996-07-16 1998-12-01 Transaction Technology, Inc. Method and system for using an application programmable smart card for financial transactions in multiple countries
US5884316A (en) * 1996-11-19 1999-03-16 Microsoft Corporation Implicit session context system with object state cache
US5999732A (en) * 1998-03-23 1999-12-07 Sun Microsystems, Inc. Techniques for reducing the cost of dynamic class initialization checks in compiled code
US6005942A (en) * 1997-03-24 1999-12-21 Visa International Service Association System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
US6092147A (en) * 1997-04-15 2000-07-18 Sun Microsystems, Inc. Virtual machine with securely distributed bytecode verification
US6128774A (en) * 1997-10-28 2000-10-03 Necula; George C. Safe to execute verification of software
US6157966A (en) * 1997-06-30 2000-12-05 Schlumberger Malco, Inc. System and method for an ISO7816 complaint smart card to become master over a terminal
US6182158B1 (en) * 1995-04-14 2001-01-30 Sun Microsystems, Inc. Method and system for providing interoperability among processes written to execute on different operating systems
US6195700B1 (en) * 1998-11-20 2001-02-27 International Business Machines Corporation Application protocol data unit management facility
US6195774B1 (en) * 1998-08-13 2001-02-27 Xilinx, Inc. Boundary-scan method using object-oriented programming language
US6212633B1 (en) * 1998-06-26 2001-04-03 Vlsi Technology, Inc. Secure data communication over a memory-mapped serial communications interface utilizing a distributed firewall
US6289502B1 (en) * 1997-09-26 2001-09-11 Massachusetts Institute Of Technology Model-based software design and validation
US6308317B1 (en) * 1996-10-25 2001-10-23 Schlumberger Technologies, Inc. Using a high level programming language with a microcontroller
US6332215B1 (en) * 1998-12-08 2001-12-18 Nazomi Communications, Inc. Java virtual machine hardware for RISC and CISC processors
US6385729B1 (en) * 1998-05-26 2002-05-07 Sun Microsystems, Inc. Secure token device access to services provided by an internet service provider (ISP)
US6402028B1 (en) * 1999-04-06 2002-06-11 Visa International Service Association Integrated production of smart cards

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5357510A (en) 1992-02-19 1994-10-18 Fujitsu Limited Apparatus and a method for supervising and controlling ATM traffic
US5241594A (en) 1992-06-02 1993-08-31 Hughes Aircraft Company One-time logon means and methods for distributed computing systems
JP3151103B2 (en) 1994-03-30 2001-04-03 日立プロセスコンピュータエンジニアリング株式会社 Communication system and communication method
US5617421A (en) 1994-06-17 1997-04-01 Cisco Systems, Inc. Extended domain computer network using standard links
US5655077A (en) 1994-12-13 1997-08-05 Microsoft Corporation Method and system for authenticating access to heterogeneous computing services
JPH08235114A (en) 1995-02-28 1996-09-13 Hitachi Comput Eng Corp Ltd Server access method and charge information managing method
US5793763A (en) 1995-11-03 1998-08-11 Cisco Technology, Inc. Security system for network address translation systems
US5959990A (en) 1996-03-12 1999-09-28 Bay Networks, Inc. VLAN frame format
US5854901A (en) * 1996-07-23 1998-12-29 Cisco Systems, Inc. Method and apparatus for serverless internet protocol address discovery using source address of broadcast or unicast packet
US5684950A (en) 1996-09-23 1997-11-04 Lockheed Martin Corporation Method and system for authenticating users to multiple computer servers via a single sign-on
US6047376A (en) 1996-10-18 2000-04-04 Toshiba Information Systems (Japan) Corporation Client-server system, server access authentication method, memory medium stores server-access authentication programs, and issuance device which issues the memory medium contents
US5983270A (en) * 1997-03-11 1999-11-09 Sequel Technology Corporation Method and apparatus for managing internetwork and intranetwork activity
US6130892A (en) 1997-03-12 2000-10-10 Nomadix, Inc. Nomadic translator or router
US6011910A (en) 1997-04-08 2000-01-04 3Com Corporation Supporting authentication across multiple network access servers
US5944824A (en) 1997-04-30 1999-08-31 Mci Communications Corporation System and method for single sign-on to a plurality of network elements
US5884038A (en) * 1997-05-02 1999-03-16 Whowhere? Inc. Method for providing an Internet protocol address with a domain name server
US6091951A (en) 1997-05-14 2000-07-18 Telxon Corporation Seamless roaming among multiple networks
US6021496A (en) 1997-07-07 2000-02-01 International Business Machines Corporation User authentication from non-native server domains in a computer network
US5991810A (en) 1997-08-01 1999-11-23 Novell, Inc. User name authentication for gateway clients accessing a proxy cache server
US6023724A (en) * 1997-09-26 2000-02-08 3Com Corporation Apparatus and methods for use therein for an ISDN LAN modem that displays fault information to local hosts through interception of host DNS request messages
US5974453A (en) 1997-10-08 1999-10-26 Intel Corporation Method and apparatus for translating a static identifier including a telephone number into a dynamically assigned network address
US6092196A (en) 1997-11-25 2000-07-18 Nortel Networks Limited HTTP distributed remote user authentication system
US6026441A (en) 1997-12-16 2000-02-15 At&T Corporation Method for establishing communication on the internet with a client having a dynamically assigned IP address
US6009103A (en) 1997-12-23 1999-12-28 Mediaone Group, Inc. Method and system for automatic allocation of resources in a network
US6205479B1 (en) 1998-04-14 2001-03-20 Juno Online Services, Inc. Two-tier authentication system where clients first authenticate with independent service providers and then automatically exchange messages with a client controller to gain network access
US6141687A (en) 1998-05-08 2000-10-31 Cisco Technology, Inc. Using an authentication server to obtain dial-out information on a network
US6092178A (en) 1998-09-03 2000-07-18 Sun Microsystems, Inc. System for responding to a resource request
US6119160A (en) 1998-10-13 2000-09-12 Cisco Technology, Inc. Multiple-level internet protocol accounting
US6324585B1 (en) * 1998-11-19 2001-11-27 Cisco Technology, Inc. Method and apparatus for domain name service request resolution
US6205489B1 (en) * 1999-01-05 2001-03-20 Whowhere, Inc. Method for providing an internet protocol address with a domain name server

Patent Citations (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4400769A (en) * 1979-02-21 1983-08-23 Fujitsu Limited Virtual machine system
US5493675A (en) * 1991-02-27 1996-02-20 Digital Equipment Corporation Compiler back end calling predetermined front end routines that use effect and dependency indicators to provide information to the compiler to determine the validity of an optimization
US5305456A (en) * 1991-10-11 1994-04-19 Security Integration, Inc. Apparatus and method for computer system integrated security
US5408670A (en) * 1992-12-18 1995-04-18 Xerox Corporation Performing arithmetic in parallel on composite operands with packed multi-bit components
US5446901A (en) * 1993-06-30 1995-08-29 Digital Equipment Corporation Fault tolerant distributed garbage collection system and method for collecting network objects
US5838965A (en) * 1994-11-10 1998-11-17 Cadis, Inc. Object oriented database management system
US5668999A (en) * 1994-12-20 1997-09-16 Sun Microsystems, Inc. System and method for pre-verification of stack usage in bytecode program loops
US6247171B1 (en) * 1994-12-20 2001-06-12 Sun Microsystems, Inc. Bytecode program interpreter apparatus and method with pre-verification of a data type restrictions and object initialization
US6075940A (en) * 1994-12-20 2000-06-13 Sun Microsystems Inc. System and method for pre-verification of stack usage in bytecode program loops
US5740441A (en) * 1994-12-20 1998-04-14 Sun Microsystems, Inc. Bytecode program interpreter apparatus and method with pre-verification of data type restrictions and object initialization
US5748964A (en) * 1994-12-20 1998-05-05 Sun Microsystems, Inc. Bytecode program interpreter apparatus and method with pre-verification of data type restrictions
US5999731A (en) * 1994-12-20 1999-12-07 Sun Microsystems, Inc. Bytecode program interpreter apparatus and method with pre-verification of data type restrictions and object initialization
US6477702B1 (en) * 1994-12-20 2002-11-05 Sun Microsystems, Inc. Bytecode program interpreter apparatus and method with pre-verification of data type restrictions and object initialization
US5757918A (en) * 1995-01-20 1998-05-26 Tandem Computers Incorporated Method and apparatus for user and security device authentication
US6182158B1 (en) * 1995-04-14 2001-01-30 Sun Microsystems, Inc. Method and system for providing interoperability among processes written to execute on different operating systems
US5724279A (en) * 1995-08-25 1998-03-03 Microsoft Corporation Computer-implemented method and computer for performing modular reduction
US5732263A (en) * 1995-10-03 1998-03-24 International Business Machines Corporation Systems, methods and computer program products for generating and validating user defined object classes in an object oriented programming environment after build time
US5784553A (en) * 1996-01-16 1998-07-21 Parasoft Corporation Method and system for generating a computer program test suite using dynamic symbolic execution of JAVA programs
US5794049A (en) * 1996-06-05 1998-08-11 Sun Microsystems, Inc. Computer system and method for executing architecture specific code with reduced run-time memory space requirements
US5844218A (en) * 1996-07-16 1998-12-01 Transaction Technology, Inc. Method and system for using an application programmable smart card for financial transactions in multiple countries
US6308317B1 (en) * 1996-10-25 2001-10-23 Schlumberger Technologies, Inc. Using a high level programming language with a microcontroller
US5884316A (en) * 1996-11-19 1999-03-16 Microsoft Corporation Implicit session context system with object state cache
US6233683B1 (en) * 1997-03-24 2001-05-15 Visa International Service Association System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
US6005942A (en) * 1997-03-24 1999-12-21 Visa International Service Association System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
US6092147A (en) * 1997-04-15 2000-07-18 Sun Microsystems, Inc. Virtual machine with securely distributed bytecode verification
US6157966A (en) * 1997-06-30 2000-12-05 Schlumberger Malco, Inc. System and method for an ISO7816 complaint smart card to become master over a terminal
US20010000814A1 (en) * 1997-06-30 2001-05-03 Montgomery Michael A. Smart card control of terminal and network resources
US6289502B1 (en) * 1997-09-26 2001-09-11 Massachusetts Institute Of Technology Model-based software design and validation
US6128774A (en) * 1997-10-28 2000-10-03 Necula; George C. Safe to execute verification of software
US5999732A (en) * 1998-03-23 1999-12-07 Sun Microsystems, Inc. Techniques for reducing the cost of dynamic class initialization checks in compiled code
US6385729B1 (en) * 1998-05-26 2002-05-07 Sun Microsystems, Inc. Secure token device access to services provided by an internet service provider (ISP)
US6212633B1 (en) * 1998-06-26 2001-04-03 Vlsi Technology, Inc. Secure data communication over a memory-mapped serial communications interface utilizing a distributed firewall
US6195774B1 (en) * 1998-08-13 2001-02-27 Xilinx, Inc. Boundary-scan method using object-oriented programming language
US6195700B1 (en) * 1998-11-20 2001-02-27 International Business Machines Corporation Application protocol data unit management facility
US6332215B1 (en) * 1998-12-08 2001-12-18 Nazomi Communications, Inc. Java virtual machine hardware for RISC and CISC processors
US6402028B1 (en) * 1999-04-06 2002-06-11 Visa International Service Association Integrated production of smart cards

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030046613A1 (en) * 2001-09-05 2003-03-06 Eitan Farchi Method and system for integrating test coverage measurements with model based test generation
US7272752B2 (en) * 2001-09-05 2007-09-18 International Business Machines Corporation Method and system for integrating test coverage measurements with model based test generation
US20060041792A1 (en) * 2004-08-19 2006-02-23 International Business Machines Corporation Method, system and program for identifying a test specification for testing a file element
US7536601B2 (en) * 2004-08-19 2009-05-19 International Business Machines Corporation Method, system and program for identifying a test specification for testing a file element
US20150186117A1 (en) * 2013-12-26 2015-07-02 International Business Machines Corporation Generating software code
US20150186115A1 (en) * 2013-12-26 2015-07-02 International Business Machines Corporation Generating software code
US9710234B2 (en) * 2013-12-26 2017-07-18 International Business Machines Corporation Generating software code
US9710235B2 (en) * 2013-12-26 2017-07-18 International Business Machines Corporation Generating software code

Also Published As

Publication number Publication date Type
US6425003B1 (en) 2002-07-23 grant

Similar Documents

Publication Publication Date Title
Clause et al. Dytan: a generic dynamic taint analysis framework
Wallach et al. SAFKASI: A security mechanism for language-based systems
Lindholm et al. The Java virtual machine specification
Joy et al. The Java language specification
US5418964A (en) System and method for parent class shadowing in a statically linked object hierarchy
US6298477B1 (en) Method and apparatus for selecting ways to compile at runtime
US7120572B1 (en) Memory efficient program pre-execution verifier and method
US6728963B1 (en) Highly componentized system architecture with a loadable interprocess communication manager
US6851108B1 (en) Verifying intermediate language code
US6385722B1 (en) Method, system, and article of manufacture for limiting access to program files in a shared library file
US20060190935A1 (en) Method and apparatus for transforming Java native interface function calls into simpler operations during just-in-time compilation
US20050028137A1 (en) Method and system for program editing
US5920720A (en) Efficient computer based virtual machine object structure
Qian A Formal Specification of Javaℳ Virtual Machine Instructions for Objects, Methods and Subroutines
US6637025B1 (en) Dynamic selection/definition of which class/methods should or should not be jit&#39;ed using information stored in a jar file
US6081665A (en) Method for efficient soft real-time execution of portable byte code computer programs
US20050278790A1 (en) System and method for using security levels to simplify security policy management
US5361350A (en) Object oriented method management system and software for managing class method names in a computer system
US6093216A (en) Method of run-time tracking of object references in Java programs
US5923878A (en) System, method and apparatus of directly executing an architecture-independent binary program
US20060190934A1 (en) Method and apparatus for inlining native functions into compiled Java code
US6385764B1 (en) Method and apparatus for improving invocation speed of Java methods
US6658421B1 (en) System and method for detecting release-to-release binary compatibility in compiled object code
US6298353B1 (en) Checking serialization compatibility between versions of java classes
US6526571B1 (en) Method for identifying calls in java packages whose targets are guaranteed to belong to the same package