Computer System to Compile Non-Incremental Computer Source Code to Execute Within an Incremental Type Computer System

1. Field of the Invention

This invention relates to a technique encompassing a methodology and an apparatus for allowing non-incremental computer source code to be compiled and to operate within an incremental type of computer system. In one embodiment, the technique of this invention allows Java.RTM. type computer source code to be compiled and made to operate within a Smalltalk.TM. type computer system.

2. Discussion

Incremental computer systems, such as those which utilize the conventional and known Smalltalk.TM. software programming language, are widely known and used within the computer industry. At the outset it should be realized that the terms "system" and/or "computer system" as used in this Application mean the cooperative combination of software and/or hardware and/or firmware which cooperatively and functionally allow a software program to be developed and to executed in order to achieve its various certain objectives. Moreover, as used in this Application, the term incremental language is meant to refer to a language which is utilized by a computer system which allows individual subroutines (e.g. methods, procedures, and/or functions) to be compiled and/or modified while the program is executing and/or running. A non-incremental language refers to a language which is utilized by a computer system which requires the computer program to be stopped from executing before subroutines are modified and/or compiled.

These incremental types of computer systems are favored, by many software developers and programmers, over non-incremental computer systems since they allow for method level compilations under which single methods or portions of the developed computer program may be sequentially and singularly compiled, run, modified, and/or analyzed. This allows the software methodology or program to be changed on a method by method basis, thereby allowing the programmer and/or software developer greater control over and greater flexibility in programming. These incremental software development systems also allow the program behavior to be modified while the program is operating or "running". These features, as are known to those of ordinary skill in the computer programming art, allow for enhanced error analysis of the programming code since one may inspect the various objects and data within a program as that program is executing or "running" instead of stopping the program. Moreover, these features also allow one to evaluate the software program's response (or the response of part of the program) to arbitrary expressions, such as the known "do-it" type expressions, thereby allowing a software program developer to evaluate the program's response to a known and/or preselected set of inputs or to different modifications, thereby increasing and/or enhancing program development efficiency as well as facilitating error analysis. These incremental program features also reduce overall compiler and/or development time since methods and/or program portions may be compiled separately and the program need not be "restarted" every time a change occurs to the program's source code such as, without limitation, for testing purposes. Hence, these incremental types of computer systems allow relatively effective incremental compilation, interactive and/or dynamic "debugging", and program browsing capabilities.

While these known incremental software programming languages and/or systems have many advantages, they are not as widely used as are many of the non-incremental systems, perhaps due to the fact that the non-incremental programming languages and/or non-incremental computer systems pre-date the incremental systems and that these two systems are so different that relatively few of the non-incremental program developers desire to so drastically change the type of computer system that they employ to develop computer programs. Accordingly, non-incremental software programming languages and/or non-incremental types of computer systems, such as Java.RTM., are widely used in many applications, such as and without limitation, Internet access. Moreover, such non-incremental systems usually require less memory and have relatively fast execution speed. In particular, Java.RTM. type systems have many advantages for use in a networked environment including, but not limited to, a byte code checking algorithm which allows for secure execution within a receiving computer and reduces the probability of viral destruction, and enhanced means for representing a graphical user interface in a platform independent manner. Accordingly, there exist some inherent advantages to the use of a non-incremental system and particularly a Java.RTM. type system. Therefore, each of the incremental and non-incremental systems, such as the Java.RTM. type system, has some unique advantages, depending upon the type of computer application program which is being developed. However, because there is such a great dissimilarity between these two computer systems there is and has been no motivation on the part of those skilled in the art to actually combine these systems. Applicants have recognized the utility in combining these systems as more fully explained in this Application and particularly have recognized the utility of including Smalltalk.TM. and Java.RTM. system features.

There is therefore a need, as Applicants have recognized, for a computer system which allows and receives software programs developed and/or written by means of one or more non-incremental software languages and which contains the characteristics and advantages of the incremental computer systems. There is further a need for an integrated software development environment which is substantially similar to an incremental development environment and which may be used to create and/or develop non-incremental computer source code. Applicants' invention(s) address these needs but should not construed as being limited in this manner. Rather, as more fully set forth below, Applicants have found that combining the advantages of each of these dissimilar computer development systems (incremental and non-incremental development systems) yields surprising, innovative, and unexpected results and advantages over the prior art. These results allow for relatively efficient software creation and/or development.

It is a first object of the invention to provide a computer system which allows software programs to be created and developed by use of at least one non-incremental computer language and which allows the created and developed software program to execute and be modified within an incremental system.

It is a second object of the invention to provide a computer system which allows software programs to be created and developed by use of at least one non-incremental computer language and to be compiled in a manner which allows the created program to execute within an incremental system.

It is a third object of the invention to provide a computer system which allows software programs to be created and developed by use of the Java.RTM. programming language and which further allows the created and/or developed Java.RTM. programs to become Smalltalk.TM. compiled methods.

It is a fourth object of the invention to provide a computer system which combines the advantages of both incremental and non-incremental systems, such as, without limitation, by allowing source code to be developed in an incremental system and delivered in a manner which benefits from the advantages for a non-incremental system.

According to one aspect of the present invention, first means is provided for creating a software program by use of a non-incremental programming language. Second means is also provided, which is communicatively coupled to the first means, for converting the created software program into methods associated with incremental programs, effective to allow the created software program to execute as an incremental software program.

According to a second aspect of the present invention, a method is provided which comprises the steps of creating source code by use of a non-incremental software development system; receiving the created source code; modifying the received source code to an incremental language type code, formatting the received and modified source code within a certain parse tree structure; and executing the received and modified source code on an incremental computer system.

Further objects, features, and advantages of the present invention will become apparent from a consideration of the following description and the appended claims when taken in conjunction with the accompanying drawings.

For a fuller and more complete understanding of the nature and objects of the present invention, reference should now be had to the following in which:

FIG. 1 is a block diagram a computer system embodying the principles of the preferred embodiment of the invention.

Referring now to FIG. 1 there is shown a computer software program development and/or creation system 10 embodying the principles of the preferred embodiment of the invention. Specifically, computer system 10 includes a computer system 12 which is made in accordance with the preferred embodiment of the invention and which is adapted to receive developed and/or created non-incremental type computer source code, such as without limitation Java.RTM. source code, which is developed and/or created by use of a commercially available and conventional non-incremental computer system 14, such as and without limitation, one of the many Java.RTM. computer systems produced and commercially available from SUN Microsystems of California, to allow the received source code to be developed and/or modified and/or executed by means of an incremental system 16 and to be exported and/or communicatively coupled to non-incremental computer system 14 as shown schematically by communication channel 24. It should be realized that channel 24 schematically illustrates the exporting of developed source code from system 16 to system 14 and that the actual export may be facillitated by one or more disks or other storage mediums without the need for an actual communications channel 24.

As is further shown in FIG. 1, system 12 of the preferred embodiment of the invention is adapted to produce incremental type computer source code, such as without limitation, Smalltalk.TM. type compiled methods, which may be input and which may be executed on and/or within a conventional and commercially available Smalltalk.TM. type computer system 16 such as the system known as Visualworks.RTM. which is produced and provided by ParcPlace-Digitalk of San Jose, Calif. At the outset, it should be realized that in the current embodiment, parser 20 comprises a LALR(1) type of parser as discussed in the text entitled Compiler Construction, for example on page 173 therein, authored by Mr. William M. Waite and Mr. Gerhard Goos, published by the Springer-Verlag publishing company, in 1983, Library of Congress Number QA 76.6.W3195, 1983, which is fully and completely incorporated herein by reference, paragraph by paragraph and word for word. Applicants' utilize a LALR(1) parser, within this disclosed embodiment, since, by way of example and without limitation, it is known to those of ordinary skill in the art, that The Java Language Specification, which was written by Mr. James Gosling, Mr. Bill Joy, and Mr. Guy Steele, which was published by Addison-Wesley in 1996, and which is fully and completely incorporated herein by reference, word for word and paragraph for paragraph, defines its language in terms of a LALR(1) grammar. This parser, as explained, produces a parse tree which is accepted by an incremental compiler, such as without limitation, a Smalltalk.TM. compiler. It should be apparent to one of ordinary skill in the art that while computer system 12 of the preferred embodiment of the invention receives Java.RTM. type computer source code and generates and/or outputs Smalltalk.TM. type compiled methods, the principles of the invention are applicable to a computer system that receives computer source code from relatively any non-incremental computer system, such as systems employing the Java.RTM. programming language, and which generates and/or outputs computer compiled code which may be used on relatively any incremental computer system, such as and without limitation, those computer systems which utilize the Smalltalk.TM. programming language. Moreover, as shown computer system 10 further includes a conventional scanner 18 which receives the non-incremental source code from system 14 and couples the received code to parser 20, whose operation will be discussed. Both scanner 18 and parser 20 are communicatively coupled to systems 14 and 16. Moreover, both scanner 18 and parser 20 operate under the control of a programmable computer processor 50 which, in one embodiment, comprises the processor of the incremental system 16.

While more fully explained below, one of ordinary skill in the software programming art will appreciate that computer system 12, made in accordance with the teachings of the preferred embodiment of the invention, allows a computer software program to be developed and/or created by use of a non-incremental software programming language or within an incremental type of computer system, thereby allowing the computer software program to be developed, "run", modified, and/or "executed" in the incremental system. In this manner, Applicants have combined the advantages of both the incremental and non-incremental systems, and formed a new and novel singular computer software development system 10.

To fully understand the principles underlying Applicants' invention, it must first be realized that Applicants' invention, as embodied within computer system 12, does not simply change or convert the code from one programming language to another. Applicants' have found that this approach results in a loss of functionality, rather, Applicants have discovered that, in order for the received non-incremental type source code to be usable within the incremental system, the received non-incremental computer source code must not only be changed and/or modified to the incremental language but must be additionally stored and arranged in a certain incremental system format, corresponding to Smalltalk.TM. methods in one embodiment, in order for the desired principles and/or objects of the invention to be achieved, and certain new functionality must be added to the received source code, over that available in the non-incremental language, in order to address the functional differences between the two distinct and dissimilar computer systems. In the preferred embodiment of the invention, the modified non-incremental (e.g. Java.RTM.) scanner 18 and the incremental (e.g. Smalltalk.TM.) parser 20 perform this conversion, functionality addition, and parse tree or code format arrangements. The structure and operation of the unmodified scanner and parser are known to those of ordinary skill in the computer programming art and are delineated, for example, in the publicly available text or book entitled The Java Language Specification which was written by Mr. James Gosling, Mr. Bill Joy, and Mr. Guy Steele, which was published by Addison-Wesley in 1996, and which is fully and completely incorporated herein by reference, word for word and paragraph for paragraph.

The following discussion describes the techniques used by Applicants in creating computer system 12 and which have been found to be necessary to fulfill the previously stated objects of the invention. At the outset it must be appreciated that the non-incremental programming languages, such as the Java.RTM. programming language, differ from incremental programming languages, such as the Smalltalk.TM. programming language. For example, in Java.RTM. all names that reference methods, types, and fields must be defined in the system at the time a method is compiled. To allow Java.RTM. to be compiled incrementally, reference checking of such similar names are deferred as necessary until runtime, on demand by the developer, or just before execution in the delivery environment. As a second example, the Java.RTM. language allows method names to be overloaded and also requires the determination of the number and types of parameters to determine overall "runtime" method binding. Applicants have found that this behavior may be implemented by first, within the Smalltalk.TM. language, embedding the parameter type names into message selectors. For example, the method invocation of aString.regionMatches (true,0,"some string",0,5) is parsed as if it were the Smalltalk.TM. message-send in the following manner:

In the same manner, a method is assigned a selector that embeds the parameter type that it accepts. This allows the Smalltalk.TM. virtual machine to handle most of the method invocations directly. In the cases or situations where the parameter types of the method invocation do not exactly match the parameter types of the available methods, then a second technique is utilized by the computer system 12 of the preferred embodiment of the invention. That is, during compilation or "compile time", the parser 18 will check all method invocations for the existence of any method invocation ambiguities. If the ambiguity remains unresolved, a "compile time error" occurs. Specifically, to handle method lookup at and/or during run-time, a "doesNotUnderstand: method" for Java.RTM. classes as represented in the Smalltalk.TM. system is implemented that has a method lookup algorithm to match a method invocation with the most compatible method signature. If a suitable method is not found or if there are multiple and maximally specific methods, the method invocation is deemed to be ambiguous and a run-time-error occurs.

It is known that Smalltalk.TM. numbers do not have size limitations based upon "type" but that Java.RTM. numbers do. Correct Java.RTM. behavior requires, as Applicants have found, that Java.RTM. primitive types are implemented in Smalltalk.TM. in such a way as to emulate the overflow behavior that Java.RTM. primitive types exhibit. Applicants have found that one approach to ensure that this technique is correctly implemented is to implement substantially all of the integer mathematical operations with special methods that take size as an additional parameter. For example and without limitation, according to the teachings of the preferred embodiment of the invention, when the "+" operator is used with integral types, the "+" operator is parsed to send the message #JavaPlus:size: with a byte size parameter that is appropriate for the types of operands (e.g. ints are size 4, longs are size 8). The result of the "message send" operation will be appropriately truncated to the given or specified number of bytes that are specified by the byte size parameter. Applicants have found that floating point types of operations do not require this technique since the Smalltalk.TM. "Float" operations always answer a "Float", and "Double" operations always answer a "Double" and are thus already limited in size in Smalltalk.TM.. The Java.RTM. "Float" and "Double" operations are substantially identical to that found in the Smalltalk.TM. system. Moreover, parser 20, as will be appreciated by one of ordinary skill in the art, will constantly check for parameter type compatibility in substantially all method invocations and arithmetic operators and will enforce accessibility tags or commands, such as and without limitation, "private", "protected", and "public" modifiers in order to substantially ensure the correct compilation of a Java.RTM. method. This "type checking" and "accessibility determination", in one embodiment of the invention, is done by parser 20 during compilation.

In the preferred embodiment of the invention, static type methods are implemented as Smalltalk.TM. class methods and static variables are implemented as Smalltalk.TM. class variables. Static variables cannot be implemented as class instance variables since Java.RTM. allows subclasses to have static variables with the same name as static variables in superclasses and are considered different variables with potentially different types. Furthermore, it is undesirable and inappropriate to have class instance variables inherited to subclasses in Smalltalk.TM. when they are not so inherited in Java.RTM.. In Smalltalk.TM. the scope of a class variable would normally extend to subclasses and subclasses are not permitted to define class variables with the same name as class variables defined in superclasses. These constraints can be overridden by the parser in this Java.RTM. system, forceably allowing subclasses to have class variables with the same name as class variables defined in superclasses. The parser handles the correct scoping and accessibility of these class members.

Furthermore, in the preferred embodiment of the invention, instance variables, default values, initializers, and static initializers are implemented by special methods which are called when an instance is created or a class is imported as appropriate. In the preferred embodiment of the invention, during instance creation, the instance creation method first instantiates the object using the #new message, in the usual and conventional Smalltalk.TM. manner. Next, a default value is assigned to each instance variable as appropriate for each of the types of variables. Thirdly, any initializer expressions are executed for each instance variable. Lastly, the appropriate constructor method, including any associated arguments, is selected and executed. When a class is imported, either by compiling source files or binary loading as is known and supported within a Smalltalk.TM. implementation, a class is created and compiled in the usual manner within Smalltalk.TM.. Secondly, any and all initializer expressions for all static variables are executed. Lastly, any static initializers for all of the classes are executed.

Exception handling, in the preferred embodiment of the invention, is implemented by using the Smalltalk.TM. exception handling mechanism. A class instance variable is defined on the Java.RTM. Throwable class. Each subclass stores a Signal instance and this class instance variable will be used by the parser to generate #handle:do message-sends and #raise message sends to this signal when the parser encounters "try" statements and "throw" statements. Moreover, the Signal instance in each subclass of Throwable is a child signal of the superclass of the Throwable sub-class. The parser generates code to access the Signal as if it were a static method invocation expression. Operators are implemented with conventional and known Smalltalk.TM. methods written to implement the behavior as mandated in the Java.RTM. Language Specification which has been previously incorporated by reference.

Smalltalk.TM. compilers disallow assignment to a parameter within a method. The Java.RTM. language allows this type of assignment. Applicants have discovered that this behavior may be achieved by transforming the method parse node so that it will be accepted by the Smalltalk.TM. compiler. The parser tracks the parameters that are being assigned to. After the method node is complete, the parse tree is rebuilt by adding a new temporary variable for each parameter that is being assigned to, inserting a statement at the beginning of the method that does an assignment from the parameter to the new temporary variable. A global replacement of all references to the parameter with the new temporary variable is then done. Synchronized statements and methods are implemented using a Smalltalk.TM. mutual exclusion semaphore.

In the preferred embodiment of the invention, the following additions are made to the Java.RTM. grammar to facilitate compilation from within a code browser that displays a single method, constructor, or class definition at a time, or from a text editor for evaluation of arbitrary Java.RTM. expressions:

Additionally, there are some enhancements for the Java.RTM. grammar to support communication between Java.RTM. and Smalltalk.TM.. This provides the ability for developers of this system to write code that accesses the Smalltalk.TM. class library for diagnostic and implementation purposes. Note that the word "smalltalk" is a new reserved word for Java.RTM. as enhanced by the computer system of the preferred embodiment of the invention.

In the preferred embodiment of the invention, sample parse nodes for an LALR(1) parser are generated for input to a Smalltalk.TM. compiler are provided. The production rules are substantially taken from the Java.RTM. language specification, although exceptions should be noted below. Following the production rule is a schematic for the resulting parse node which, as will be understood by one of ordinary skill in the art, is written in Smalltalk.TM. type pseudo-code. It is assumed, for purposes of the following description, that the parse node for a production rule is left on a stack which is maintained by the parser. The notation used here utilizes names from the production rules to denote parse nodes that are left on the stack as part of the parsing process. Where alternatives are noted, such as NamelPrimaryNoNewArray, this is an abbreviated way of denoting that either the "Name" parse node is used or the "PrimaryNoNewArray" parse node is used, depending upon which part of the production rule was actually parsed, thereby determining what parse node was left on the stack.

The parse nodes which are denoted as ConstructorBody, MethodBody, FormalParameterList and Identifier refer to parse nodes which are left on the stack as part of the parsing of ConstructorDeclaration or MethodDeclaration, which includes ConstructorBody, MethodBody, FormalParameterList, and Identifier as part of their own individual production rules as defined in the Java.RTM. Language Specification. Also note that the #makeSelectorFrom:andArgs: method is a supporting method in the parser that constructs a message selector from the method name and the types of the arguments.

The copyWith: message refers to an operation that appends the argument, here the Expression parse node, to the receiver which is a collection of parse nodes, here BlockStatements.

In the preferred embodiment of the invention, the #switch: method is a method added to the classes that implement the Java.RTM. primitive types char,byte,short and int which implements the Switch logic. SwitchBlock puts a parse node on the stack that will cause the creation of any Array of Associations at runtime of keys of type char,byte,short or int, and values of the associated switch statement results.

In the preferred embodiment of the invention, the #atField: method is a new method added to Java.RTM. classes that access an instance variable by name. The parser handles accessibility constraints and duplication of field names within the superclass chain.

In the preferred embodiment of the invention, the #makeSelectorFrom:andArgs: method is a supporting method in the parser that constructs a message selector from the method name and the types of the arguments. ArrayAccess:

In the preferred embodiment of the invention, first, the parser creates a MessageNode that sends the message #newOffype:dims:isFinal: to the class JavaArray. This method will create an array of the appropriate type and dimensions. The isFinal paramenter is true if there are no empty dims (› !) so the basic element types of the array are created and stored in the array. If the isFinal parameter is false, then there were at least one set of empty dims, so the basic element types are not created and stored in the array.

Second, the method #dynamicArrayCreationNodeWith: answers a parse node that will cause a Smalltalk.TM. Array to be created at runtime that contains the values of the expression nodes that were passed as parameters to the #dynamicArrayCreationNodeWith: method.

In the preferred embodiment of the invention, if the LeftHandSide is a field access or array access expression, then instead of creating an assignment node, the parser, in this context of assignment, changes the field access message from #fieldAt: to #fieldAt:put:, or the array access message from #at: to #at:put:.

These techniques can also be used or employed to create interactive development environments with incremental compilation for non-incremental languages other than Java.RTM., such as for and without limitation, the known and commercially available C, C++, and Pascal languages. Data structures that are not "objects" in other languages can be implemented in Smalltalk.TM. as objects. For example, Applicants have found that a C/C++ struct can be created as a Smalltalk.TM. object that stores the data that would otherwise be stored in the structure. Function calls that are not associated with a class can be implemented as class methods within a Smalltalk.TM. class designated to handle global functions.

Thus, as described in the foregoing discussion, computer system 12 of the preferred embodiment of the invention receives source code from a non-incremental computer system, recognizes the functionality which must be added in order to allow corresponding actions to be taken in the incremental computer system, parses the received source code, creates a parse tree so that the received source code may be compiled by an incremental computer system, develops/modifies the compiled code, and outputs and/or exports the formatted code to a non-incremental system. Applicants, in this manner, have provided a computer system in which software programs may be developed by use of a non-incremental computer system and yet modified/developed and/or executed or "run" on an incremental system and exported or communicated back to a non-incremental computer system. These non-incrementally developed software programs may also be modified and/or "debugged" on a method basis, as is an inherent incremental system characteristic. Applicants' system therefore combines the advantages and features of both dissimilar systems.

It is to be understood that the invention is not limited to the exact construction or method illustrated and described above, but that various changes and modifications may be made without departing from the spirit and the scope of the invention as defined in the following claims.