Title: Semantics mapping between different object hierarchies
Abstract: To enhance portability of programming languages and compiled codes, methods and/or devices optionally compile a programming language code associated with one framework to a code associated with another framework and/or convert a code associated with one framework to a code associated with another framework. The aforementioned converters and/or methods include, but are not limited to, features for supporting framework differences in object hierarchy, exceptions, type characteristics, reflection transparency, and/or scoping.
Patent Number: 6,961,932 Issued on 11/01/2005 to Mishra, et al.
| Inventors:
|
Mishra; Debi (Redmond, WA);
Jain; Nikhil (New Delhi, IN);
Baid; Sushil (Kolkata, IN);
Rajaram; Sadagopan (Secunderabad, IN);
Chandrasekhar; Ramesha (Hyderabad, IN);
Krishnaswamy; Raja (Bellevue, WA);
Angeline; Dennis (Mill Creek, WA)
|
| Assignee:
|
Microsoft Corporation (Redmond, WA)
|
| Appl. No.:
|
931649 |
| Filed:
|
August 15, 2001 |
| Current U.S. Class: |
717/186 |
| Intern'l Class: |
G06F 009/45 |
| Field of Search: |
717/136
|
References Cited [Referenced By]
U.S. Patent Documents
| 5845119 | Dec., 1998 | Kozuka et al.
| |
| 5937189 | Aug., 1999 | Branson et al.
| |
| 6002874 | Dec., 1999 | Bahrs et al.
| |
| 6023578 | Feb., 2000 | Birsan et al.
| |
| 6066181 | May., 2000 | DeMaster.
| |
| 6298476 | Oct., 2001 | Misheski et al.
| |
| 6446133 | Sep., 2002 | Tan et al.
| |
| 6453356 | Sep., 2002 | Sheard et al.
| |
| 6467079 | Oct., 2002 | Ettritch et al.
| |
| 6513152 | Jan., 2003 | Branson et al.
| |
| 6553405 | Apr., 2003 | Desrochers.
| |
| 6611817 | Aug., 2003 | Dorrance et al.
| |
| 6622165 | Sep., 2003 | Philyaw.
| |
| 6718364 | Apr., 2004 | Connelly et al.
| |
| 6721942 | Apr., 2004 | Sievert.
| |
| 6738968 | May., 2004 | Bosworth et al.
| |
| 6754886 | Jun., 2004 | Merk et al.
| |
| 6760913 | Jul., 2004 | Bailey et al.
| |
Other References
Flexible Collaboration Transparency: Supporting Worker Independence in Replicated
Application-Sharing Systems, James Begole et al., VPI, ACM, Jun. 1999, pp. 95-132.
Collaboration Transparency in the DISCIPLE Framework, Wen Li et al, ACM, Jan.
1999, pp. 326-335.
JAVA Based Conservative Distributed Simulation, Alois Ferscha et al, ACM, Dec.
1997, pp. 381-388.
Programming Languages for Mobile Code, Tommy Thorn, ACM Computing Surveys, vol.
29, No. 3, Sep. 1997, pp. 213-239.
FlexiNet—A Flexible Component Oriented Middleware System, Richard Hayton
et al, ACM, Sep. 1998, pp. 17-24.
Transparency and Reflections in Distributed Systems, Robert Stroud, ACM, Apr.
1992, pp. 99-103.
StratOSphere: Mobile Processing of Distributed Objects in JAVA, Daniel Wu et
al, ACM, 1998, pp. 121-132.
The C++ Programming Language, Third Edition, Bjarne Stroustrup, Jul. 7, 1997,
pp. 130-131,384-386,496-497,847,850-851.
|
Primary Examiner: Ingberg; Todd
Attorney, Agent or Firm: Lee & Hayes, PLLC
Claims
1. A method executing on a computer-readable medium comprising:
receiving an initial code associated with a bytecode framework, the bytecode
framework having an object hierarchy; and
converting the initial code to a converted code that combines the object hierarchy
of the bytecode framework with an object hierarchy of an intermediate language
code framework.
2. The method of claim 1 wherein the converting produces a class that inherits
from a class of the bytecode framework.
3. The method of claim 2 wherein the class of the bytecode framework comprises
a superclass of the bytecode framework.
4. The method of claim 2 wherein the class of the bytecode framework comprises
a superclass named java.lang.Object.
5. The method of claim 2 wherein the class of the intermediate language code
framework comprises an array class.
6. The method of claim 2 wherein the class of the intermediate language code
framework comprises an array class named System.Array.
7. The method of claim 1 wherein the converting includes creating a new class.
8. The method of claim 7 wherein the new class inherits from java.lang.Object
and from System.Array.
9. A computer-readable medium storing computer-executable instructions to convert
an initial code associated with a bytecode framework, the bytecode framework having
an object hierarchy, to a converted code that combines the object hierarchy of
the bytecode framework with an object hierarchy of an intermediate language code framework.
10. A method executing on a computer-readable medium comprising:
receiving an initial code associated with a bytecode framework, the bytecode
framework having an exception hierarchy; and
converting the initial code to a converted code that combines the exception hierarchy
of the bytecode framework with an exception hierarchy of an intermediate language
code framework.
11. The method of claim 10 wherein the converting includes mapping exceptions.
12. A computer-readable medium storing computer-executable instructions to convert
an initial code associated with a bytecode framework, the bytecode framework having
an exception hierarchy, to a converted code that combines the exception hierarchy
of the bytecode framework with an exception hierarchy of an intermediate language
code framework.
13. A method executing on a computer-readable medium comprising:
receiving an initial code associated with a bytecode framework, the bytecode
framework having an exception hierarchy; and
converting the initial code to a converted code that maps the exception hierarchy
of the bytecode framework to an exception hierarchy of an intermediate language
code framework.
14. The method of claim 13 wherein the converting includes combining exception hierarchies.
15. A computer-readable medium storing computer-executable instructions to convert
an initial code associated with a bytecode framework, the bytecode framework having
an exception hierarchy, to a converted code that maps the exception hierarchy of
the bytecode framework with an exception hierarchy of an intermediate language
code framework.
16. A method executing on a computer-readable medium comprising:
receiving an initial code associated with a bytecode framework, the bytecode
framework having reflection transparency; and
converting the initial code to a converted code that supports the reflection
transparency of the bytecode framework on an intermediate language code framework.
17. The method of claim 16 wherein the converting includes checking for methods
associated with the reflection transparency of the bytecode framework.
18. The method of claim 16 wherein the converting includes rendering a stack
entry transparent.
19. A computer-readable medium storing computer-executable instructions to convert
an initial code associated with a bytecode framework, the bytecode framework having
reflection transparency, to a converted code that supports the reflection transparency
of the bytecode framework on an intermediate language code framework.
20. A method executing on a computer-readable medium comprising:
receiving an initial code associated with a bytecode framework, the bytecode
framework having scoping, and
converting the initial code to a converted code that supports the scoping of
the bytecode framework on an intermediate language code framework.
21. The method of claim 20 wherein the converting includes marking a package
scope and a protected scope associated with the bytecode framework as a public
scope on the intermediate language code framework.
22. The method of claim 20 wherein the converting includes marking a package
scope associated with the bytecode framework as an assembly on the intermediate
language code framework.
23. The method of claim 20 wherein the converting includes marking a protected
scope associated with the bytecode framework as an assembly or a family on the
intermediate language code framework.
24. The method of claim 20 wherein the converting includes marking, the marking
selected from a member of the group consisting of marking a protected scope associated
with the bytecode framework as an assembly or a family on the intermediate language
code framework; marking a package scope associated with the bytecode framework
as an assembly on the intermediate language code framework; marking a package scope
and a protected scope associated with the bytecode framework as a public scope
on the intermediate language code framework; and combinations thereof.
25. A computer-readable medium storing computer-executable instructions to convert
an initial code associated with a bytecode framework, the bytecode framework having
scoping to a converted code that supports the scoping of the bytecode framework
on an intermediate language code framework.
26. A method executing on a computer-readable medium comprising;
receiving an initial code associated with a bytecode framework, the bytecode
framework having type characteristics; and
converting the initial code to a converted code that supports the type characterisitics
of the bytecode framework on an intermediate language code framework.
27. The method of claim 26 wherein the converting supports type characteristics
of the bytecode framework related to casting between real and integer types on
the intermediate language code framework.
28. The method of claim 26 wherein the converting supports type characteristics
of the bytecode framework related to overflow and undefined types on the intermediate
language code framework.
29. A computer-readable medium storing computer-executable instructions to convert
an initial code associated with a bytecode framework, the bytecode framework having
type characteristics, to a converted code that supports the type characteristics
of the bytecode framework on an intermediate language code framework.
30. A method executing on a computer-readable medium comprising:
receiving an initial code associated with a bytecode framework, the bytecode
framework having at least one member selected from the group consisting of object
hierarchies, exception hierarchies, type characteristics, reflection transparencies,
and scoping; and
converting the initial code to a converted code that supports at least one of
the selected members on an intermediate language code framework.
31. A computer-readable medium storing computer-executable instructions to convert
an initial code associated with a bytecode framework, the bytecode framework having
at least one member selected from the group consisting of object hierarchies, exception
hierarchies, type characteristics, reflection transparencies, and scoping, to a
converted code that supports at least one of the selected members of the bytecode
framework on an intermediate language code framework.
Description
TECHNICAL FIELD
This invention relates generally to methods and/or devices for enhancing portability
of programming language codes and compiled codes.
BACKGROUND
An object-oriented programming language (OOPL) typically defines not only the
data type of a data structure, but also the types of functions that can be applied
to the data structure. In essence, the data structure becomes an object that includes
both data and functions. During execution of an OOPL program, access to an object's
functionality occurs by calling its methods and accessing its properties, events,
and/or fields.
In an OOPL environment, objects are often divided into classes wherein objects
that are an instance of the same class share some common property or properties
(e.g., methods and/or instance variables). Relationships between classes form a
class hierarchy, also referred to herein as an object hierarchy. Through this hierarchy,
objects can inherit characteristics from other classes.
In object-oriented programming, the terms "Virtual Machine" (VM) and "Runtime
Engine" (RE) have recently become associated with software that executes code on
a processor or a hardware platform. In the description presented herein, the term
"RE" includes VM. A RE often forms part of a larger system or framework that allows
a programmer to develop an application for a variety of users in a platform independent
manner. For a programmer, the application development process usually involves
selecting a framework, coding in an OOPL associated with that framework, and compiling
the code using framework capabilities. The resulting platform-independent, compiled
code is then made available to users, usually as an executable file and typically
in a binary format. Upon receipt of an executable file, a user can execute the
application on a RE associated with the selected framework.
Traditional frameworks, such as the JAVA™ language framework (Sun
Microsystems, Inc., Palo Alto, Calif.), were developed initially for use with a
single OOPL (i.e., monolithic at the programming language level); however, a recently
developed framework, .NET™ framework (Microsoft Corporation, Redmond, Wash.),
allows programmers to code in a variety of OOPLs. This multi-OOPL framework is
centered on a single compiled "intermediate" language having a virtual object system
(VOS). As a result, the object hierarchy and the nature of the compiled code differ
between the JAVA™ language framework and the .NET™ framework.
For the discussion presented herein, the term "bytecode" is generally associated
with a first framework and the term "intermediate language code" or "IL code" is
associated with a second framework, typically capable of compiling a variety of
programming languages. In a typical framework, the framework RE compiles code to
platform-specific or "native" machine code. This second compilation produces an
executable native machine code. Throughout the following description, a distinction
is drawn between the first compilation process (which compiles a programming language
code to bytecode or an intermediate language code) and the second compilation process
(which compiles, for example, a bytecode or an intermediate language code to native
machine code/instructions). In general, a "compiled code" (or "compiled codes")
refers to the result of the first compilation process.
To enhance portability of programming languages and compiled codes, there is a
need for methods and/or devices that can perform the following acts: (i) compile
a programming language code associated with a first framework (e.g., a bytecode
framework) to a compiled code associated with a second framework (e.g., an IL code
framework); and/or (ii) convert a compiled code associated with a first framework
(e.g., a bytecode framework) to a compiled code associated with a second framework
(e.g., an IL code framework). Such methods and/or devices should account for differences
in object hierarchy and perform without substantially compromising the original
programmer's intent.
SUMMARY
To enhance portability of programming languages and compiled codes, methods and/or
devices described herein optionally compile a programming language code associated
with one framework to a code associated with another framework; and/or convert
a code associated with one framework to a code associated with another framework.
The aforementioned devices and/or methods include, but are not limited to, features
for supporting framework differences in object hierarchy, exceptions, type characteristics,
reflection transparency, and scoping. Such methods and/or devices optionally account
for differences in object hierarchy and perform without substantially compromising
the original programmer's intent.
Additional features and advantages of the invention will be made apparent
from the following detailed description of illustrative embodiments, which proceeds
with reference to the accompanying figures.
BRIEF DESCRIPTION OF THE DRAWINGS
A more complete understanding of the various methods and arrangements described
herein, and equivalents thereof, may be had by reference to the following detailed
description when taken in conjunction with the accompanying drawings wherein:
FIG. 1 is a block diagram generally illustrating an exemplary computer system
on which the present invention may be implemented.
FIG. 2 is a block diagram illustrating two different frameworks as known to
one of ordinary skill in the art.
FIG. 3 is a block diagram illustrating two frameworks and an exemplary converter
for converting a bytecode to an IL code.
FIG. 4 is a block diagram illustrating an object hierarchy for a framework using bytecode.
FIG. 5 is a block diagram illustrating an exemplary combined object hierarchy.
FIG. 6 is a block diagram illustrating an exemplary combined object hierarchy
including an ObjectForArrays class.
FIG. 7 is a block diagram illustrating two frameworks and an exemplary converter
for converting classes.
FIG. 8 is a block diagram illustrating the JAVA™ language framework's
exception hierarchy.
FIG. 9 is a block diagram illustrating an exemplary combined exception hierarchy.
FIG. 10 is a block diagram illustrating an alternative exemplary combined exception hierarchy.
FIG. 11 is a block diagram illustrating an exemplary converter including features
for supporting differences in object hierarchy, exceptions, type characteristics,
reflection transparency, and scoping.
DETAILED DESCRIPTION
Turning to the drawings, wherein like reference numerals refer to like elements,
various methods and converters are illustrated as being implemented in a suitable
computing environment. Although not required, the methods and converters will be
described in the general context of computer-executable instructions, such as program
modules, being executed by a personal computer. Generally, program modules include
routines, programs, objects, components, data structures, etc. that perform particular
tasks or implement particular abstract data types. Moreover, those skilled in the
art will appreciate that the methods and converters may be practiced with other
computer system configurations, including hand-held devices, multi-processor systems,
microprocessor based or programmable consumer electronics, network PCs, minicomputers,
mainframe computers, and the like. The methods and converters may also be practiced
in distributed computing environments where tasks are performed by remote processing
devices that are linked through a communications network. In a distributed computing
environment, program modules may be located in both local and remote memory storage devices.
FIG. 1 illustrates an example of a suitable computing environment
120
on which the subsequently described methods and converter arrangements may be implemented.
Exemplary computing environment
120 is only one example of a suitable
computing environment and is not intended to suggest any limitation as to the scope
of use or functionality of the improved methods and arrangements described herein.
Neither should computing environment
120 be interpreted as having any dependency
or requirement relating to any one or combination of components illustrated in
computing environment
120.
The improved methods and arrangements herein are operational with numerous other
general purpose or special purpose computing system environments or configurations.
Examples of well known computing systems, environments, and/or configurations that
may be suitable include, but are not limited to, personal computers, server computers,
thin clients, thick clients, hand-held or laptop devices, multiprocessor systems,
microprocessor-based systems, set top boxes, programmable consumer electronics,
network PCs, minicomputers, mainframe computers, distributed computing environments
that include any of the above systems or devices, and the like.
As shown in FIG. 1, computing environment
120 includes a general-purpose
computing device in the form of a computer
130. The components of computer
130 may include one or more processors or processing units
132, a
system memory
134, and a bus
136 that couples various system components
including system memory
134 to processor
132.
Bus
136 represents one or more of any of several types of bus structures,
including a memory bus or memory controller, a peripheral bus, an accelerated graphics
port, and a processor or local bus using any of a variety of bus architectures.
By way of example, and not limitation, such architectures include Industry Standard
Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA)
bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component
Interconnects (PCI) bus also known as Mezzanine bus.
Computer
130 typically includes a variety of computer readable media.
Such media may be any available media that is accessible by computer
130,
and it includes both volatile and non-volatile media, removable and non-removable media.
In FIG. 1, system memory
134 includes computer readable media in the form
of volatile memory, such as random access memory (RAM)
140, and/or non-volatile
memory, such as read only memory (ROM)
138. A basic input/output system
(BIOS)
142, containing the basic routines that help to transfer information
between elements within computer
130, such as during start-up, is stored
in ROM
138. RAM
140 typically contains data and/or program modules
that are immediately accessible to and/or presently being operated on by processor
132.
Computer
130 may further include other removable/non-removable, volatile/non-volatile
computer storage media. For example, FIG. 1 illustrates a hard disk drive
144
for reading from and writing to a non-removable, non-volatile magnetic media (not
shown and typically called a "hard drive"), a magnetic disk drive
146 for
reading from and writing to a removable, non-volatile magnetic disk
148
(e.g., a "floppy disk"), and an optical disk drive
150 for reading from
or writing to a removable, non-volatile optical disk
152 such as a CD-ROM,
CD-R, CD-RW, DVD-ROM, DVD-RAM or other optical media. Hard disk drive
144,
magnetic disk drive
146 and optical disk drive
150 are each connected
to bus
136 by one or more interfaces
154.
The drives and associated computer-readable media provide nonvolatile storage
of computer readable instructions, data structures, program modules, and other
data for computer
130. Although the exemplary environment described herein
employs a hard disk, a removable magnetic disk
148 and a removable optical
disk
152, it should be appreciated by those skilled in the art that other
types of computer readable media which can store data that is accessible by a computer,
such as magnetic cassettes, flash memory cards, digital video disks, random access
memories (RAMs), read only memories (ROM), and the like, may also be used in the
exemplary operating environment.
A number of program modules may be stored on the hard disk, magnetic disk
148,
optical disk
152, ROM
138, or RAM
140, including, e.g., an
operating system
158, one or more application programs
160, other
program modules
162, and program data
164.
The improved methods and arrangements described herein may be implemented within
operating system
158, one or more application programs
160, other
program modules
162, and/or program data
164.
A user may provide commands and information into computer
130 through
input
devices such as keyboard
166 and pointing device
168 (such as a "mouse").
Other input devices (not shown) may include a microphone, joystick, game pad, satellite
dish, serial port, scanner, camera, etc. These and other input devices are connected
to the processing unit
132 through a user input interface
170 that
is coupled to bus
136, but may be connected by other interface and bus structures,
such as a parallel port, game port, or a universal serial bus (USB).
A monitor
172 or other type of display device is also connected to bus
136
via an interface, such as a video adapter
174. In addition to monitor
172,
personal computers typically include other peripheral output devices (not shown),
such as speakers and printers, which may be connected through output peripheral
interface
175.
Logical connections shown in FIG. 1 are a local area network (LAN)
177
and a general wide area network (WAN)
179. Such networking environments
are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.
When used in a LAN networking environment, computer
130 is connected
to LAN
177 via network interface or adapter
186. When used in a WAN
networking environment, the computer typically includes a modem
178 or other
means for establishing communications over WAN
179. Modem
178, which
may be internal or external, may be connected to system bus
136 via the
user input interface
170 or other appropriate mechanism.
Depicted in FIG. 1, is a specific implementation of a WAN via the Internet.
Here, computer
130 employs modem
178 to establish communications
with at least one remote computer
182 via the Internet
180.
In a networked environment, program modules depicted relative to computer
130,
or portions thereof, may be stored in a remote memory storage device. Thus, e.g.,
as depicted in FIG. 1, remote application programs
189 may reside on a memory
device of remote computer
182. It will be appreciated that the network connections
shown and described are exemplary and other means of establishing a communications
link between the computers may be used.
Converters and Conversion Processes
To enhance portability of programming languages and compiled codes, methods and
converters are presented herein to perform the following acts: (i) compile a programming
language code associated with a first framework (e.g., a bytecode framework) to
a compiled code associated with a second framework (e.g., an IL code framework);
and/or (ii) convert a compiled code associated with a first framework (e.g., a
bytecode framework) to a compiled code associated with a second framework (e.g.,
an IL code framework). While various examples presented herein include a first
framework comprising a bytecode framework and a second framework comprising an
IL code framework, the exemplary converters and exemplary methods are not limited
to bytecode and IL code frameworks. Further, conversion optionally includes conversions
between bytecode frameworks, conversions between IL code frameworks and/or conversions
to, from and/or between other types of frameworks known in the art. Additional
features are discussed below that help to retain the original programmer's intent.
FIG. 2 shows a block diagram of a first framework comprising a bytecode framework
200, a second framework comprising an IL code framework
300 and a
converter
400. The bytecode framework
200 includes a source code
block
204 for a source code written in an OOPL, such as the JAVA™
programming language (Sun Microsystems, Inc., Palo Alto, Calif.). A compiler block
208 compiles the source code to produce a bytecode, shown in bytecode block
212. Next, a RE block
216 receives bytecode from the bytecode block
212. At run time the RE block
216 interprets and/or compiles and
executes native machine code/instructions to implement applications embodied in
the bytecode.
The IL code framework
300 includes a source code block
304 for
a source code written in an OOPL, such as VISUAL C#™ (Microsoft Corporation,
Redmond, Wash.). A compiler block
308 compiles the source code to produce
an IL code, shown in IL code block
312. The compiler block
308 optionally
has the capability of compiling more than one type of OOPL. The IL code block
312
may also include metadata, which helps the RE manage objects. Next, a RE block
316 receives IL code from the IL code block
312. At run time the
RE block
316 compiles and executes native machine code/instructions to implement
applications embodied in the IL code.
The converter
400 converts various operations and/or code between one
framework and another as desired and/or as required. A variety of exemplary converters
are described below.
FIG. 3 shows the block diagram of FIG. 2 further including an exemplary converter
block
400 that converts bytecode to IL code and another exemplary converter
block
430 that converts an OOPL code to an IL code. While the description
below focuses primarily on the bytecode to IL code converter block
400,
the OOPL code to IL code converter
430 addresses similar issues.
The converter
400 accounts for a variety of issues including differences
in object hierarchies. As a specific example, consider the object hierarchy of
the OOPL-based JAVA™ language framework. In the JAVA™ language framework,
a class known as the "Object" class sits at the base of the class hierarchy, this
Object class appears herein as java.lang.Object. Referring to the object hierarchy
500 shown in FIG. 4, the java.lang.Object class
504 appears at the
base of the hierarchy
500. The java.lang.Object class
504 defines
the basic state and behavior of all objects. All other classes descend either directly
or indirectly from the Object class
504. As shown in FIG. 4, class X
1508,
class X
2512 and class X
3516 are subclasses of the java.lang.Object
class
504, which is a superclass of these subclasses. A subclass inherits
state and behavior in the form of variables and methods from its superclass. Subclasses
Y
1520 and Y
2524 inherit from classes X
1508
and X
3516, respectively, as well as from java.lang.Object class
504.
Supporting an Object Hierarchy
To adequately convert bytecode of the JAVA™ language framework to IL code
of the .NET™ framework, the converter should ensure that the object hierarchy
of the JAVA™ language framework inherits from a class within the .NET™
object hierarchy. In the .NET™ framework, the base class is the System.Object
class. FIG. 5 shows a combined object hierarchy
600 wherein a java.lang.Object
class
504 and related subclasses (
508,
512,
516,
520,
524) inherit from a .NET™ System.Object class
604.
The combined object hierarchy
600, as shown in FIG. 5, however, may not
adequately account for differences in arrays. In the JAVA™ language framework,
arrays are objects and inherit from java.lang.Object
504 directly. Thus,
assuming that class X
2512 is an array creation class called java.array,
this class should inherit from java.lang.Object
504 and System.Object
604.
However, the IL code of the .NET™ framework supports creation of arrays
only as instances of an array class, known as System.Array
606, note that
java.lang.Object
504 does not inherit from System.Array
606. Thus,
whenever a method call tries to treat an array as a java.langObject, it would fail.
For example, consider the following JAVA™ language code:
- new int[2].objectMethod( );
This code will fail because the object created by "new int[2]" is not an instance
of java.lang.Object, i.e., any attempt to call the method objectMethod( ) of java.lang.Object
will fail. Therefore, to adequately account for a JAVA™ language framework
array, the java.array class that inherits from System.Array 606 should also
inherit from java.lang.Object 504.
An additional aspect of the array issue involves type checking of array assignments.
For example, consider the following code for executing an assignment:
- Object[ ] obj={new int[2], "nikhil"};
This code tries to assign an array to an element of java.lang.Object[ ]; however,
the array is not an instance of java.lang.Object. Strict type checking at runtime
for array element assignments in .NET™ framework ensures that an exception
(e.g., ArrayTypeMismatchException) gets thrown at runtime.
An exemplary procedure for handling these java.array inheritance issues involves
the creation of a new class, referred to herein as ObjectForArrays. Referring to
FIG. 6, a combined object hierarchy
700 is shown including ObjectForArrays
720. In this object hierarchy
700, ObjectForArrays
720 inherits
from java.lang.Object
708 and java.array
716 inherits through System.Array
712 and both java.lang.Object
708 and System.Array
712 inherit
through System.Object
704. In an exemplary method, the ObjectForArray class
720 is used whenever an attempt is made to use an array like an object.
The methods of the ObjectForArray class
720 are static and take an extra
parameter that is the object on which the java.lang.Object method call is intended.
The difference though, is that this parameter is a System.Object
704 rather
than ajava.lang.Object
708. Hence, this object hierarchy
700 can
handle arrays.
The following exemplary code illustrates aspects of the object hierarchy
700
shown in FIG.
6.
##STR1##
Whenever an array is treated like a java.lang.Object, a converter converts
the code. For example, consider the following converter operation:
##STR2##
In the instance where a java.lang.Object method is called on an object whose
type
is not known at compilation time, a converter converts the corresponding code in
the following exemplary manner:
##STR3##
Referring again to FIG. 3, as described above, an exemplary converter
400
converts code from one framework, e.g., the JAVA™ language framework, to
an executable code in another framework, e.g., the .NET™ framework. The
converter
400 handles framework array element assignment issues by ensuring
an inheritance check of the object being assigned inheriting from the type of the
runtime array passes. For example, referring to the combined object hierarchy
600
of FIG. 5, whenever a need exists for java.lang.Object
504 array creation,
the exemplary converter
400 creates System.Object
604 arrays. In
the conversion process, the converter
400 does not change the signature
of the field or the local variable; only the actual object created gets changed.
##STR4##
According to this exemplary converter
400 and conversion process,
the underlying System.Object[ ] behaves seamlessly like a java.lang.Object[ ].
Note that the brackets "[ ]" represent an operator or action such as declaration
of an array, creation of an array, and access of array elements. In a further aspect
of this exemplary converter
400, whenever a user attempts to reflect upon
the type of the object by using getClass( ) method in java.lang.Object
504
on the object, the getClass code returns the type as java.lang.Object[ ] and not
System.Object[ ].
In yet another aspect, the exemplary converter
400 handles arrays created
through a reflection API. In the JAVA™ language framework, a reflection
API (e.g., available through the command "import java.lang.reflect.*") can generally
be used to determine the class of an object; to get information about a class's
modifiers, fields, methods, constructors, and superclasses; to find out what constants
and method declarations belong to an interface; to create an instance of a class
whose name is not known until runtime; to get and set the value of an object's
field, even if the field name is unknown to your program until runtime; to invoke
a method on an object, even if the method is not known until runtime; and to create
a new array, whose size and component type are not known until runtime, and then
modify the array's components.
According to the exemplary converter
400, when a code calls for
creation of a java.lang.Object[ ] array using the reflection API (e.g., using Array.newInstance),
the converter
400 creates a corresponding System.Object[ ]. The exemplary
converter
400 further accounts for verification issues upon assignment of
a System.Object[ ] to a field of type java.lang.Object [ ].
Another aspect of the exemplary converter
400 handles code containing
"instanceof" checks on an array. An object is considered to be an instance of a
class if that object directly or indirectly descends from that class. In the JAVA™
language framework, "instanceof" determines whether a first operand is an instance
of a second operand wherein, for example, the first operand is the name of an object
and the second operand is the name of a class. To ensure that "instanceof" calls
on arrays succeed for java.lang.Object, java.lang.Cloneable and java.io.Serializable,
the exemplary converter
400 includes the following operation (shown for
java.lang.Cloneable):
##STR5##
Regarding the clone method, in the JAVA™ language framework, implementation
of this method checks to see if the object on which clone was invoked implements
the Cloneable interface, and throws a CloneNotSupportedException if it does not.
In particular, note that Object itself does not implement Cloneable, so subclasses
of Object that do not explicitly implement the interface are not cloneable. Thus,
the exemplary converter
400 accounts for this characteristic of the JAVA™
language framework. In a similar vein, in the JAVA™ language framework,
an object is serializable only if its class implements the Serializable interface.
Thus, code that seeks to serialize instances of a class requires that the class
implement the Serializable interface. Again, the exemplary converter
400
accounts for this characteristic of the JAVA™ language framework.
##STR6##
JAVA™ language framework like most OOPLs has a set of class libraries
that are used by programmers as a foundation to build applications. Supporting
compilation and execution of such applications optionally requires implementation
of these class libraries on the .NET™ framework. FIG. 7 shows a block diagram
illustrating two frameworks
200,
300 and an exemplary converter
460
for converting classes
444. Accordingly, the exemplary converter
460
optionally allows for implementation of reflection in a first framework
200
(e.g., JAVA™ language framework) on top of reflection in a second framework
300 (e.g., .NET™ framework). Such an exemplary converter
460
converts classes written in source code (e.g., an OOPL code) and/or classes that
exist in a compiled code (e.g., bytecode or other compiled code) (see, e.g., FIGS.
2 and 3, the converter
400 and the converter
430). While FIG. 7 refers
to bytecode framework classes
444, which are available to the bytecode framework
RE
216 and/or the compiler for the bytecode framework
208, the classes
are optionally classes associated with yet another framework. A class converted
by such a converter and associated with a second framework is optionally referred
to herein as a first framework class, a converted class, and/or a new class.
In the .NET™ framework, System.Type is the root object of .NET™
framework reflection mechanism, wherein a type object describes a class. Thus,
for example, a reflection to get information about a class's modifiers, fields,
methods, constructors, and superclasses uses the underlying System.Type object.
For arrays, the type object for arrays is the type object for the .NET™
framework arrays, which are an instance of System.Array. The class library implementation
accounts for this difference because reflection on a .NET™ framework array
gives different results than an ordinary reflection on a JAVA™ framework
array. An exemplary method for class library implementation handles this particular
issue in a way that maintains the original programmer's intent.
In yet another aspect, an exemplary converter optionally accounts for verification
issues related to difference between frameworks. For example, a verification issue
arises upon assignment of an array to fields of types java.lang.Object. Similarly,
a verification issue arises for creation of System.Object arrays in place of java.lang.Object
arrays when assigning a field of type java.lang.Object ("JLO") to one of the System.Object
("SO") arrays. The exemplary converter
400 handles these issues by isolating
them into a file having static methods. For example, a file named VerifierFix has
static methods by the name getJLOFromSO that take SO or SO[ ] . . . [ ] as a parameter
and return JLO or JLO[ ] . . . [ ] correspondingly. This process results in isolation
of all verification issues into one class VerifierFix and hence all other binaries
generated by the compiler would not hit any of these verification issues. The following
operation demonstrates a process for handling verification issues.
##STR7##
Note that the above call to VerifierFix.getJLOFromSO calls different overloaded
methods in the two cases shown above. The first one takes an SO and returns a JLO
and the second one takes a SO[ ] and returns a JLO[ ].
As already mentioned, a reflection can also be used to set the value of an object's
field. Such reflection operations may differ from one framework to another. Thus,
the exemplary converter
400 optionally accounts for such differences. For
example, when code from a JAVA™ language framework executes on a .NET™
runtime, any attempt to set an array to a field type of java.lang.Object will fail.
The failure is due to the fact that arrays in the .NET™ framework do not
normally inherit from java.lang.Object. Consequently, the .NET™ reflection
API causes an exception. As a remedy, the exemplary converter
400 emits
a private method that takes a System.Object as an argument and within the method
assigns this argument to the field. Thus, when a reflection call to assign a value
to such a field appears, the converter
400 provides for the aforementioned
private method. The framework invokes the private method using reflection and hence
bypasses the reflection check for the type of value to be assigned.
At the code level, the converter's remedy optionally appears as follows:
##STR8##
This exemplary converter code averts the throwing of an exception by a reflection
API by calling the $setf method and assigning the value, which could be an array,
to the field f. Note that this remedy does not impact normal use of arrays, like
array assignments.
In essence, the exemplary converter introduces an instanceof check when arrays
are used as java.lang.Object by calling a method in java.lang.Object class on this
array object. Further, all calls to methods of java.lang.Object where the underlying
object is not an array result in a method call and an instanceof check. Overall,
the remedy for each verification issue requires a method call. The slight increase
in overhead however does not detract from the goal of successfully converting code
from one framework to another while retaining the programmer's original intent.
Supporting Framework Exceptions
The exemplary converter
400, described herein (see, e.g., "Supporting
a Framework Object Hierarchy"), optionally includes features that support exceptions
from one framework on another framework. For example, consider the JAVA™
language exception hierarchy
800 shown in FIG.
8. JAVA™ language
public class Object
804 sits at the base of the JAVA™ language framework's
hierarchy
800 such that every class has Object
804 as a superclass.
As described previously, all objects, including arrays, inherit the methods of
the java.lang.Object class
804.
In the exception hierarchy
800, the class java.lang.Throwable
808
sits below java.lang.Object
804. The Throwable class
808 is the superclass
of all errors and exceptions in the JAVA™ language framework. Only objects
that are instances of this class (or of one of its subclasses) are thrown by the
JAVA™ language RE or can be thrown by a "throw" statement. Similarly, only
this class or one of its subclasses can be the argument type in a catch clause.
In the JAVA™ language framework, the Throwable class
808 also contains
a snapshot of the execution stack of its thread at the time it was created.
As mentioned, the Throwable class
808 is the superclass of all errors
and
exceptions in the JAVA™ language framework. Thus, the classes java.lang.Exception
812 and java.lang.Error
816 sit below java.lang.Throwable
808
in the hierarchy
800. In general, the class java.lang.Exception
812
and its subclasses, java.lang.RuntimeException
820 (unchecked exceptions)
and Java Checked Exceptions
824, are forms of Throwable
808 that
indicate conditions that a reasonable application might want to catch. Also shown
in FIG. 8 is a subclass of java.lang.RuntimeException
820 entitled "Other
Java Runtime Exceptions"
828, which simply recognizes the possibility of
other runtime exceptions. The java.lang.Error
816 class is a subclass of
Throwable
808. The Error class
816 indicates serious problems (e.g.,
abnormal conditions) that a reasonable application should not try to catch.
A list of exceptions and/or errors thrown by the JAVA™ language RE appears below.
- java.lang.ArithmeticException
- java.lang.ArrayIndexOutOfBoundsException
- java.lang.ArrayStoreException
- java.lang.ClassCastException
- java.lang.Error
- java.lang.Exception
- java.lang.IllegalAccessError
- java.lang.IllegalArgumentException
- java.lang.IllegalMonitorStateException
- java.lang.IllegalThreadStateException
- java.lang.IncompatibleClassChangeError
- java.lang.IndexOutOfBoundsException
- java.lang.InternalError
- java.lang.InterruptedException
- java.lang.LinkageError
- java.lang.NoClassDefFoundError
- java.lang.NoSuchFieldError
- java.lang.NoSuchMethodError
- java.lang.NullPointerException
- java.lang.NumberFormatException
- java.lang.OutOfMemoryError
- java.lang.RuntimeException
- java.lang.SecurityException
- java.lang.StackOverflowError
- java.lang.ThreadDeath
- java.lang.Throwable
- java.lang.UnsatisfiedLinkError
- java.lang.VerifyError
- java.lang.VirtualMachineError
Exception handling in the .NET™ framework involves definition of
exception blocks. At the IL level, exception block definition occurs predominantly
through use of either catch types or filter blocks. For example, catch type exception
handling may include a BeginExceptionBlock( ) followed by emission of some IL code;
a BeginCatchBlock(ExceptionType) followed by emission of some IL code; and an EndExceptionBlock.
Filter block definition handling may include a BeginExceptionBlock( ) followed
by emission of some IL code; a BeginFilterBlock( ) followed by emission of some
IL code; a BeginCatchBlock(null) followed by emission of some IL code; and an EndExceptionBlock.
When defining catch type exception blocks through the .NET™ Framework's
Reflection APIs, ExceptionType must be an instance of the .NET™ framework's
System.Exception class; however, at the IL level there is no such limitation. Thus,
whenever an exception gets thrown, control goes to the entered catch block if the
exception thrown is an instance of ExceptionType.
In contrast, when an exception is thrown according to a filter block exception
block, control goes to the .NET™ framework's ExceptionFilterBlock class.
According to this scenario, the thrown exception is placed on top of the stack
wherein the filter block is used to indicate, for example, a 0 or 1. If the filter
block indicates 1, when the filter block ends, the .NET™ framework enters
a catch block. If the filter block indicates 0, then the exception goes uncaught
by this particular exception block. Hence, in this manner, the filter block filters
exceptions by either allowing them to go uncaught or directing them to a catch block.
To handle JAVA™ language framework exceptions on the .NET™ framework,
a converter should account for several issues. For example, in the JAVA™
language framework, Errors (instance of java.lang.Error
816) and runtime
exceptions (instance of java.lang.RuntimeException
820) can be thrown by
the JAVA™ language RE. When a program executes on the .NET™ RE, the
exceptions thrown by the runtime are different from those thrown by JAVA™
language RE. The following code illustrates such an instance wherein the .NET™
framework would fail to catch the exception thrown.
| |
int k = 0; |
| |
int j = 5/k; //causes a runtime exception |
| |
} catch (Exception e) { |
| |
} |
| |
|
Without an exception conversion (e.g., code conversion or mapping), the exception
thrown for the above code will not be an instance of java.lang.Exception
812
and hence it will not be caught. Further, a complete one-to-one mapping does not
exist for many frameworks. For example, a complete one-to-one mapping does not
exist between JAVA™ language exceptions and .NET™ exceptions. Thus,
an exemplary converter for handling exceptions accounts for differences in exception
class hierarchy and for the lack of a complete one-to-one mapping.
An exemplary converter converts and/or maps JAVA™ language framework exceptions
to existing and/or new .NET™ framework exceptions. According to this exemplary
converter, catch types are used to catch various JAVA™ language exceptions.
For checked exceptions (exceptions not normally thrown by either the JAVA™
language or .NET™ RE), the catch type approach suffices; however, for runtime
exceptions and errors the exemplary converter implements filter blocks.
Given a JAVA™ language framework exception throwable by the JAVA™
language RE, the exemplary converter needs to find a corresponding .NET™
framework exception throwable by the .NET™ RE. The exemplary converter should
also catch the JAVA™ language exception because, like any checked exception,
the associated JAVA™ language code could throw the exception explicitly.
To address this particular issue, the exemplary converter implements filter blocks.
During a conversion process, the converter emits IL code for a filter block designed
to catch a targeted exception or exceptions. The following code illustrates the
conversion process:
##STR9##
Note that this particular code segment represents code implied by the IL as
converted from JAVA™ language code.
The exemplary converter may also implement mapping procedures such as a static
mapping from a .NET™ framework exception to a JAVA™ language framework
exception, which is used via a method in class java.lang.Throwable. The following
code illustrates part of the process:
- public static Throwable_mapCorException (System.Exception exc)
Assuming a class "A" that is a JAVA™ language framework exception
can be thrown by the RE, the class library implementation for this class implements
the following method:
| |
|
| |
public static int_exceptFilter(System.Object o) { |
| |
Throwable t = null; |
| |
if (o instanceof A) { |
| |
}else if (o instanceof System.Exception) { |
| |
System.Exception e = (System.Exception)o; |
| |
t = Throwable._mapCorException(e); |
| |
if(t != null) { |
| |
Thread._setExceptionObject(t); |
| |
return 1; |
Converter
400 during the conversion process emits the filter code
that calls this method, passing the exception object as a parameter. Thus, via
this process, the converter implemented filter block allows the .NET™ frame
