Method and apparatus for interfacing a javascript interpreter with library of host objects implemented in java

[0002] 1. Field of the Invention

[0003] This invention relates to a method and apparatus for interpreting and executing JavaScript programs, such as JavaScript programs embedded in hypertext markup language (“HTML”) documents. More particularly, embodiments of the present invention relate to a method and apparatus for a JavaScript interpreter written in Java. Specifically, a JavaScript interpreter may intercept JavaScript source code within HTML documents, parse and convert the JavaScript source code to a proprietary intermediate form represented by objects written in Java. The JavaScript interpreter may interface with JavaScript library objects to execute the intermediate representation equivalent of the original JavaScript source code.

[0004] 2. Description of the Related Art

[0005] JavaScript is a Web scripting language developed by Netscape Communications Corporation. JavaScript was one of the first Web scripting languages and it remains one of the most popular today. (Please note that JAVA and JAVASCRIPT used herein are registered trademarks of Sun Microsystems, Inc.) JavaScript may be directly included in HTML documents. HTML is a language used to create Web documents. Referring now to FIG. 1, the JavaScript source code is typically embedded in HTML documents 110, by using a script tag, such as “<SCRIPT LANGUAGE=JavaScript>”. A Web browser 120, such as Netscape Navigator, executes HTML documents containing JavaScript source code. Unlike compiled languages, JavaScript is an interpreted language. This means the Web browser executes each line of JavaScript as it comes to it. The ability to interpret and execute JavaScript source code has been provided in popular Web browsers, such as Netscape Navigator and Microsoft Internet Explorer. JavaScript programs run within a Web browser or other JavaScript-enabled applications to produce the desired results 130. The JavaScript language is regularly updated by Netscape. The most recent version of JavaScript is version 1.3.

[0006] Typical prior art Web browsers that support JavaScript are programmed in native code complied for a particular computer platform. However, it may be desirable to support JavaScript in a Web browser programmed in a platform-independent language such as Java. A Java-based Web browser may run on any computing platform under a Java Virtual Machine for the particular platform. However, Java-based programs typically execute more and may have a larger memory footprint that natively coded programs. Thus, adding JavaScript support to a Java-based browser may exacerbate speed and memory drawbacks. It may be desirable to overcome these drawbacks for a Java-based browser with JavaScript support, especially for use in embedded devices such as personal digital assistants (PDAs), wireless communication devices, such as cellular telephones, and other small consumer devices where computer processing speed and memory resources are at a premium. The present invention may provide a method and apparatus for interpreting and executing JavaScript source code embedded in HTML documents. The interpreter of the present invention may be written using the Java programming language. The present invention uses a smaller memory footprint than the prior art in interpreting and executing JavaScript programs. Furthermore, the architecture of the present invention may enable faster execution of JavaScript programs and enable the use of independent implementations of the interpreter, the Web browser and the JavaScript object library.

[0007] A method and apparatus is disclosed for interfacing a JavaScript interpreter with a JavaScript library of host objects implemented using the Java programming language. Specifically, a method and apparatus is disclosed for accessing a JavaScript program, parsing the program, generating an intermediate representation of the JavaScript program, and executing the intermediate representation by interfacing with the JavaScript library of host objects.

[0008] In the preferred embodiment of the present invention, the JavaScript program is embedded in HTML documents in an Internet Web browser. The Web browser is programmed to intercept the JavaScript code and pass execution control over the program to an interpreter engine developed using the Java programming language. The parsing component of the engine validates the JavaScript instructions. The validated instructions are converted by the code generator component of the engine into an intermediate representation equivalent in Java code. The interpreter engine accesses the program's library of host objects through an interface to the library and executes the intermediate representation to produce the desired results as programmed in the original JavaScript source program. The implementation of the interface enables the implementation of the interpreter engine to be independent from the implementation of the library of host objects and independent from the implementation of the Web browser. The library of host objects is also implemented using the Java programming language, where the host objects are derived from abstract Java classes. The host objects of the library contain fields and methods identified in the JavaScript source program. The interface dynamically updates the host objects of the library. The dynamic update capability of the interface is implemented using hash tables. Methods previously unknown to the library are stored in the hash tables in their original source code syntax. The present invention further contemplates information media that conveys software for implementing the method disclosed herein.

[0009] FIG. 1 is a flow diagram of a typical method of interpreting JavaScript programs;

[0010] FIG. 2 is a flow diagram illustrating one embodiment of interception of JavaScript code in HTML for execution by a Java-based JavaScript interpreter;

[0011] FIG. 3 is a flow diagram illustrating an embodiment of various components for interpreting JavaScript programs;

[0012] FIG. 4 illustrates a method according to one embodiment for converting JavaScript code to an equivalent intermediate representation; and

[0013] FIG. 5 illustrates the hierarchy of the JavaScript runtime objects and its relationship to the hierarchy of library objects, according to one embodiment.

[0014] While the invention is described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that the invention is not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.

[0015] A preferred embodiment of the present invention may be developed using the Java programming language as provided in the Java Development Kit (JDK), version 1.1.7 from Sun Microsystems.

[0016] Referring now to FIG. 2, in one embodiment, a JavaScript source program may be embedded in HTML 210. The HTML may be processed by a Web browser 220, such as Netscape Navigator or Microsoft Internet Explorer. A JavaScript tag in the HTML may be used to identify the beginning of the JavaScript code section within the HTML. Upon encountering a JavaScript tag 230, the Web browser may pass execution control to an interpreter engine 250. The interpreter engine 250 may interpret the JavaScript code 210, execute it, and present the results to the user 260. Non-JavaScript code in the HTML may be executed by the Web browser 240.

[0017] The interpreter engine 250 is further illustrated in FIG. 3, according to one embodiment. Once the Web browser has identified an input stream of JavaScript source code 310 in the HTML document, the Web browser may pass processing control to a parser component 320 of the interpreter engine. The parser 320 may examine the syntax of the incoming JavaScript source code 310 to produce a validated listing of JavaScript code 330 before the code is translated by the interpreter. The parsed JavaScript code 330 may then be processed by a representation generator component 340 of the interpreter engine. The representation generator component 340 takes as input the validated JavaScript code 330 and produces an intermediate representation using a proprietary Java code equivalent 350 of the JavaScript code 310. The intermediate Java code representation 350 may then be interpreted by an interpreter component 360. The interpreter component 360 may use a library interface 370 to communicate with a JavaScript host objects library 380 to execute the intermediate representation 350 and produce desired results 390 as programmed in the original JavaScript source program 310.

[0018] As one of ordinary skill in the art will appreciate, there are various methods by which a Web browser may be enabled to recognize the parser component 320 as the appropriate subroutine to which the Web browser passes control upon encountering the JavaScript tag 230. One method is by placing “hooks” into the Web browser which instruct the browser to call certain entry point methods of the parser component 320 when a JavaScript tag is encountered in the HTML code. The general method of placing such “hooks” in a Web browser by using the JDK Reflection API is well known to those of ordinary skill in the art. Other well-known methods of instructing one program to invoke another may be applied to instruct a Web browser to invoke the parser component 320. These methods include use of the “OnAction” keyword and “Form” tag.

[0019] In the preferred embodiment of the present invention, the parser component 320 may be written using Java CC, a publicly available utility published by Metamata. Using the Java CC utility, the parser component 320 may be written to accept the syntax (grammar) of the input language to be parsed, i.e., the JavaScript syntax. This enables the parser component 320 to parse the input steam of JavaScript source code 310 to ensure that the correct syntax is followed. The parser component 320 produces a validated listing of JavaScript code 330. The parser 320 may create Java objects based on what is parsed from the input stream of the JavaScript source code 310. The Java objects, which may contain field names and methods, may be stored using a technique such as hash tables. The use of hash tables may facilitate fast access of field names and methods during the entire process of interpreting and executing the JavaScript source code 310.

[0020] As stated above, a Java CC source file may define the JavaScript grammar in one embodiment. The following illustrates the creation of Java CC source file definitions and three related parser methods as used in the preferred embodiment of the present invention:

[0021] Once the parser 320 has parsed the input stream of the JavaScript program 310, the parsed JavaScript code 330 may be translated into an intermediate representation Java code 350 by the representation generator component 340. The intermediate format of the preferred embodiment may be an arbitrary scheme that is similar to Java byte code. As one skilled in the art will appreciate, the intermediate format may be any scheme that adequately represents the input JavaScript code 310 for execution by a JavaScript interpreter. The representation or intermediate format 350 of the preferred embodiment is particularly suitable for execution by a stack-machine implemented interpreter written in Java. However, as one skilled in the art will readily appreciate, it is not required that the intermediate format 350 be designed such that it may be executed by stack-machine implemented interpreter. Depending on the representation scheme used, alternatively designed interpreters may be used without departing from the present invention.

[0022] As stated above, the representation of the input JavaScript program 310 may be accomplished using many different schemes. The preferred embodiment of the present invention demonstrates one representation scheme using Java classes and objects. Referring now to FIG. 4, a representation scheme example according to a preferred embodiment is illustrated. The input JavaScript source code sample 410 is “Echo(“2+3:”+(2+));.” The JavaScript code 410 performs the simple function of adding two numbers and displaying the result. Box 420 shows a representation of the JavaScript code 410 as it is accomplished in the preferred embodiment. More particularly, box 430 lists logical commands representing the JavaScript code 410, and box 440 lists Java objects and classes which correspond to the logical representations 430. Box 450 illustrates the foregoing with Java program code. The representation generator 340 may use a stack data structure to store the intermediate representation 350 as Java objects. For example, the JavaScript function “Echo” is represented with two pushes on the stack data structure. First, the logical command “call” is pushed on the stack to indicate the presence of a function or method. Second, the name of the function “echo” is pushed on the stack. The Java object “call” is an instance of the Java class JvScFunctionalCall. Similarly, the Java object “echo” is an instance of the Java class JvScName, used for storing host objects. The names of host objects may be names of methods or functions which are called to perform specific functions. And similarly, Java classes, such as JvScOperator, JvScString and JvScNumber may be created to hold Java objects, such as the operator “add,” the string “2+3” and the integer “2” respectively. The parameters and commands in the intermediate representation may be Java objects.

[0023] Referring now to FIG. 5, box 510 illustrates a hierarchy of the JavaScript runtime objects and its relationship to a hierarchy of library objects 580. The class JvScAtom 520 may generally consist of a JvScOperator class 530 and the JvScDatum class 540. The JvScOperator class 530 may contain objects such as “MUL,” “ADD,” “CALL,” “GETFIELD” and “RETURN.” The JvScDatum class 540 includes JvScName 550 (e.g., name of a method or function), JvScNumber 560 (e.g., the integer “2” used in an ADD operation) and JvScObject 570 (which is inserted in the stack data structure discussed above). As stated above, the representation generator 340 may use a stack data structure to store the intermediate representation 350 as Java objects.

[0024] The stack used in the representation scheme of the preferred embodiment may be an array of Java objects. Each element of this array (stack) may be either a command or a parameter. Each element may derive from an abstract Java class with very generic functionality and may contain data pertaining to the operator or data type it represents, sufficient for a stack machine interpreter to perform actions equivalent to those specified in the original JavaScript program 310. The Java class to which an object in the array (stack) belongs, may determine whether the particular object is a command or a parameter. As one of ordinary skill in the art will appreciate, there are numerous methods of representing in memory the operators and the operands of a compiled program. In the preferred embodiment of the present invention, the logical representation 430 uses the well-known Polish notation scheme.

[0025] The intermediate representation 350 may have several advantages, such as a small memory footprint. Furthermore, the representation scheme of the preferred embodiment may enable faster execution of the JavaScript code 310 by the interpreter component 360.

[0026] The following illustrates the representation generator component 340 of the preferred embodiment and an associated representation scheme suitable for execution by a stack-machine implemented interpreter:

[0027] Once the representation generator 340 has translated the parsed JavaScript code 330 to produce the intermediate representation 350, the interpreter component 360 may use the library interface 370 to communicate with the JavaScript host objects library 380 to execute the intermediate representation 350 and produce the desired results 390, as programmed in the original JavaScript source program 310.

[0028] The interpreter 360 may pop elements off the stack, executes them and places the result back on the stack. The interpreter may execute streams of Java objects (e.g., “push” and “2+3”) in the stack containing commands and parameters belonging to various Java classes (e.g., JvScOperator or JvScString). The interpreter may pop one or more elements off the stack depending on what instruction is being executed. For example, if an “ADD” operator is encountered, then the interpreter knows that it must pop two more elements which will form the operands for the “ADD” operation. The following illustrates the execution of the intermediate representation Java code 350 by the interpreter 360, according to one embodiment:

[0029] Referring to FIG. 3, the interpreter component 360 may use the library interface 370 to communicate with the JavaScript host objects library 380 to execute the intermediate representation 350. In a JavaScript program execution environment, there may be several functionally independent components. The JavaScript interpreter and the JavaScript library are two of the most important components. In a preferred embodiment, the JavaScript program execution environment may be implemented using the Java programming language. The preferred embodiment may provide a mechanism whereby host objects in a JavaScript library are accessible to the interpreter in an execution environment designed in Java.

[0030] The method and system of the preferred embodiment may provide an interface 370 between the JavaScript interpreter 360 and the JavaScript library objects 380, where both the interpreter 360 and the library objects 380 are written in Java. The interface 370 enables the implementation of the interpreter 360 to be independent of the implementation of the library objects 380. Furthermore, the implementation of the interpreter 360 may be independent of the HTML browser 220 in which it runs. The foregoing relationship between the interpreter, the library objects and the browser may make it possible to easily incorporate the interpreter in any Java-enabled browser with an arbitrary library objects implementation.

[0031] Still referring to FIG. 3, the library objects 380 may be derived from abstract Java classes. The interpreter 360 may use the JDK Reflection API for at least two purposes. First, the Reflection API may enable the interpreter 360 to access specific information (such as properties) about known objects and classes in the library 380. Such information may include, for example, the availability of particular fields and methods within objects. Second, the Reflection API may enable the interpreter 360 to execute methods if they are not privately protected. The interface 370 may also enable manipulation of field values and call methods of an object. Additionally, fields and methods may be dynamically added or deleted in a class or object. The techniques of hash tables and the JDK Reflection API may be utilized to facilitate the foregoing processing.

[0032] One JavaScript standards specification requires five basic host objects that must be present in the local library of a JavaScript interpreter. All other objects that are called by a JavaScript program must be available in other libraries accessible to the JavaScript interpreter. The programmer of the JavaScript source code must know what objects, other than the five basic host objects, are accessible to the interpreter which will execute the JavaScript source code. The Web browser in which the JavaScript program runs may provide additional non-required host objects in its libraries. As one of ordinary skill in the art will appreciate, new fields and methods may be added or deleted to any object during run time.

[0033] As defined by a JavaScript standards specification, an object in JavaScript does not necessarily only bear traces of the class to which it belongs. The JavaScript object may have characteristics that are different from other objects belonging to the same class. Thus, objects in JavaScript may act as independent entities with methods and fields which may be different from the methods and fields in other objects belonging to the same class. However, objects in the same class may have certain basic methods and fields in common.

[0034] Still referring to FIG. 3, during the processing of the JavaScript source code 310 in the preferred embodiment, the interpreter encounters fields and methods in the JavaScript program. The interpreter may create Java objects in a library containing the fields and the methods. However, as the input stream of JavaScript source code is processed, the interpreter may learn more information about fields and methods which it has previously encountered. The library interface 370 may provide the interpreter 360 the dynamic capability to update Java objects and their related properties or attributes.

[0035] In an embodiment, the library interface 370 may have three primary Java methods through which any interaction with an object 380 is carried out. The three primary Java methods may be “get field,” “set field” and “invoke method.” These methods may be used in conjunction with JavaScript objects and classes whose methods and fields are known to the JavaScript library 380, but not known to the interpreter 360. The Reflection API may be used to access the JavaScript library 380 and thus inform the interpreter 360 about methods and fields contained in any particular object.

[0036] The JavaScript library 380 may contain a static set of predefined objects containing methods and fields. In one embodiment, all objects within the input stream of JavaScript source code 310 must exist in the JavaScript library 380. However, certain objects within the JavaScript source code 310 may contain methods and fields which are not known to the JavaScript library 380. When this occurs, the JavaScript library 380 may be dynamically updated with the new methods and fields. Similarly, the interpreter 360 may need to be aware of the new methods and fields. The dynamic update of the library 380 may be accomplished with the use of hash tables. In a preferred embodiment, the JavaScript library 380 may include a hash table for each object. Initially, the hash table for each object may be empty. When the input JavaScript program 310 introduces a new method or field, an entry may be created in the hash table corresponding to the new method or field. The name of the new method or field may be used as the key to the hash table entry. The key serves as the means by which the new method or field may be accessed to acquire information about the method or field. For methods, the information to be accessed may be the code section associated with the new method, and for fields, the information to be accessed may be the data holder or the field value. The interpreter 360 may access the hash tables to get values of the new fields and to execute the code associated with the new methods.

[0037] The newly added fields and methods in the hash tables may remain available to all JavaScript program and interpreter invocations so long as the current session of the HTML browser 220 is running. Once the HTML browser 220 is closed, the newly updated methods and fields in the hash tables may be lost and therefore, the methods and fields may not be available to future JavaScript program and interpreter invocations in a subsequent session of the HTML browser. The clearing of the new methods and fields in the hash tables at the end of an HTML browser session may be done pursuant to a JavaScript standards specification.

[0038] In the preferred embodiment the source code associated with the newly added methods is not compiled when a reference to it is stored in the hash table. Instead, an intermediate representation is stored within the engine. This technique may solve certain problems encountered by the prior art. Some prior art methods compile the source code associated with the newly added methods and store the new source code in object code format for future use. The prior art technique is not efficient because it uses large amounts of memory to store the compiled object code and uses valuable processing time to convert the source code to object code. In the present invention, these problems may be overcome by storing an intermediate representation of the original JavaScript syntax.

[0039] The present invention does not require that the library host objects 380 (and their associated methods) be written in Java. The objects and methods may be native code but the entry point is written in Java, in a preferred embodiment, because in the preferred embodiment the interpreter 360 may require methods to have a Java entry point so that the interpreter 360 can call on such routines.

[0040] One desirable attribute of the present invention may be the independence and interchangeability of the JavaScript library 380. The preferred embodiment may include one implementation of the JavaScript library 380. This implementation may be written in Java based on a JavaScript standards specification. The JavaScript library 380 may be independent of the interpreter 360. Therefore, any other implementation of the JavaScript library 380 may be easily substituted for the library used in the preferred embodiment. As mentioned previously, both the interpreter and the JavaScript library may also be independent of the HTML browser. The independence and interchangeability of the JavaScript library may permit customization of the library to different environments, such as through the addition of objects, and their corresponding methods and fields, that may be better suited to certain HTML browsers.

[0041] The following illustrates how the interpreter component 360 may use the library interface 370 to communicate with the JavaScript host objects library 380 to execute the intermediate representation 350, according to one embodiment:

[0042] Although the forgoing description has focused on Java implementations, other similar programming languages may be used as well. Any of the foregoing embodiments may be implemented by programming a suitable general-purpose machine having appropriate hardware. The machine may comprise a single computer or computing device. Alternatively, the machine may comprise a plurality of computers or computing devices connected by a communications link.

[0043] Various embodiments may further include receiving, sending or storing instructions and/or data implemented in accordance with the foregoing description upon a carrier medium. Generally speaking, a carrier medium may include storage media or memory media such as magnetic or optical media, e.g., disk or CD-ROM, volatile or non-volatile media such as RAM (e.g. SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc. as well as transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as network and/or a wireless link.

[0044] It will be appreciated by those of ordinary skill having the benefit of this disclosure that the illustrative embodiments described above are capable of numerous variations without departing from the scope and spirit of the invention. Various modifications and changes may be made as would be obvious to a person skilled in the art having the benefit of this disclosure. It is intended that the following claims be interpreted to embrace all such modifications and changes and, accordingly, the specifications and drawings are to be regarded in an illustrative rather than a restrictive sense.