The present invention relates generally to a development environment for creating application programs and other software and, particularly, to a system with methods and interfaces facilitating creation of components for use in such an environment.
With the explosive growth of the Internet and the World Wide Web, an ever-increasing number of computers of disparate platforms are being connected together. As a result, there is renewed interest in distributing software in binary format which operates in this ever-increasing heterogeneous environment. In the early 1990s, a team at Sun Microsystems developed a new language, "Java," to address the issues of software distribution on the Internet. Java is a simple, object-oriented language which supports multi-thread processing and garbage collection. Although the language is based on C++, a superset of C, it is much simpler. More importantly, Java programs are "compiled" into a binary format that can be executed on many different platforms without recompilation. The language includes built-in mechanisms for verifying and executing Java "binaries" in a controlled environment, protecting the user's computer from potential viruses and security violations.
A typical Java system comprises the following set of interrelated technologies: a language specification; a compiler for the Java language that produces bytecodes for an abstract, stack-oriented machine; a virtual machine (VM) program that interprets the bytecodes at runtime; a set of class libraries; a runtime environment that includes bytecode verification, multi-threading, and garbage collection; supporting development tools, such as a bytecode disassembler; and a browser (e.g., Sun's "Hot Java" browser).
Java is designed for creating applications that will be deployed in heterogeneous networked environments. Such environments are characterized by a variety of hardware architectures. Further, applications in such environments execute atop a variety of different operating systems and interoperate with a multitude of different programming language interfaces. To accommodate such diversity, the Java compiler generates platform-neutral "bytecodes"--an architecturally neutral, intermediate format designed for deploying application code efficiently to multiple platforms.
Java bytecodes are designed to be easy to interpret on any machine. Bytecodes are essentially high-level, machine-independent instructions for a hypothetical or "virtual" machine that is implemented by the Java interpreter and runtime system. The virtual machine, which is actually a specification of an abstract machine for which a Java language compiler generates bytecode, must be available for the various hardware/software platforms on which an application is to run. The Java interpreter executes Java bytecode directly on any machine for which the interpreter and runtime system of Java have been ported. In this manner, the same Java language bytecode runs on any platform supported by Java.
Compiling Java into platform-neutral bytecodes is advantageous. Once the Java language interpreter and runtime support are available on a given hardware and operating system platform, any Java language application can be executed. The bytecodes are portable since they do not require a particular processor, architecture, or other proprietary hardware support. Further, the bytecodes are byte-order independent, so that programs can be executed on both big-endian machines (e.g., Intel architecture) and little-endian machines (e.g., Motorola architecture). Since Java bytecodes are typed, each specifies the exact type of its operands, thereby allowing verification that the bytecodes obey language constraints. All told, the interpreted bytecode approach of compiled Java language programs provides portability of programs to any system on which the Java interpreter and runtime system have been implemented.
The bytecodes are actually stored in "class" files. Each class file stores all the information for a particular Java class. A "class" in Java is a software construct which defines instance variables and methods, in effect, serving as a template for creating objects of a particular type. In this regard, a Java class is akin to a C++class. A very simple "Point" class, for instance, may be declared as follows.
class Point { public double x; /* instance variable */ public double y; /* instance variable */ }
This declaration serves as a template from which "Point" objects can be instantiated.
Actual instantiation of an object occurs in a manner similar to that found in the C++programming language. For example, a variable which refers to a "Point" object can be declared as follows: EQU Point myPoint;
An instance of a point object is allocated as follows. EQU myPoint=new Point ( );
Here, one can now access variables of the "Point" object, using familiar "dot" notation for referring to the names of the variables. EQU myPoint.x=10; EQU myPoint.y=20;
Objects communicate by sending messages to each other. A recipient object responds to a message by selecting a particular method to execute. If one object wants another object to do some work on its behalf, for instance, the first object sends a message to the second object. The second object, in response, invokes the method which is appropriate for processing the message. The methods themselves, therefore, define the behavior of objects instantiated from a class. In particular, it is an object's methods which manipulate the object's data--its instance variables.
Further description of the Java Language environment can be found in Gosling, J. et al., The Java Language Environment: A White Paper, Sun Microsystems Computer Company, October 1995, the disclosure of which is hereby incorporated by reference.
"Visual" development environments, such as Borland's JBuilder.TM., Borland's Delphi.TM., Microsoft.RTM. Visual Basic, Microsoft.RTM. J++, and Powersoft's PowerBuilder.TM., are rapidly becoming preferred development tools for quickly creating production applications, including those created with the Java programming language. Such environments are characterized by an integrated development environment (IDE) providing a form "painter" (i.e., designer), a property getter/setter manager ("inspector"), a project manager, a tool palette (with objects which the user can drag and drop on forms), an editor, a compiler, and a linker (which, for a Java environment, is provided at runtime by the Java VM). In general operation, the user "paints" objects on one or more forms, using the form painter. Attributes and properties of the objects on the forms can be modified using the property manager or inspector. In conjunction with this operation, the user attaches or associates program code with particular objects on screen (e.g., button object); the editor is used to edit program code which has been attached to particular objects.
Today, many development tools provide source code generation functionality. Here, an individual developer may use a development tool, such as an "application generator," to automatically generates source code, thus lessening the drudgery of creating certain source code (particularly, boilerplate source code). A pronounced limitation of such tools is that they are "one-way." Here, once the developer edits source code created using the automation tool, the developer cannot later return to the tool for further automating generation of source code (e.g., generating code for adding new properties for objects).
This limitation does not comport with the way the developers create source code, however, particularly for components (e.g., Java "bean" components). Instead, for instance, a developer would typically want to add a property and then write some code for the property, and probably test the new property. In fact, as the development process is a highly iterative one, such a developer would likely continue adding some properties and removing other properties, until just the right combination is found which achieves the functionality sought in the program under development. On the other hand, there are "visual" design tools, such as IBM Visual Age, which let the developer develop visually (i.e., using automated code generation) but do not allow the developer to have easy access to the actual underlying source code and, thus, interfere with the way the developer really works. All told, with present-day development tools, the developer is forced to envision the "grand scheme" of the program up front, in order to use the tool. Since this is not a practical approach, the full benefit of source code automation tools has not been realized in existing development systems.
What is needed is a system with an improved code generation capability which simplifies the task of application development. In particular, what is needed is a two-way code generation tool that may be used to not only allow automated generation of code, but also allow later automated generation of aspects of the code, even though the code itself has been edited. The present invention fulfills this and other needs.