Patent Application
20080005160
The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein:
Like reference numerals are used to designate like parts in the accompanying drawings.
The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present examples may be constructed or utilized. The description sets forth the functions of the examples and the sequence of steps for constructing and operating the examples. However, the same or equivalent functions and sequences may be accomplished by different examples.
Although not required, embodiments of the invention will be described in the general context of computer readable instructions, such as program modules, being executed by one or more computers or other devices. Computer readable instructions may be distributed via computer readable media (discussed below). Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various environments.
Additionally, device 100 may also have additional features and/or functionality. For example, device 100 may also include additional storage (e.g., removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in
The term “computer readable media” as used herein includes both computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Memory 104 and storage 108 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by device 100. Any such computer storage media may be part of device 100.
Device 100 may also contain communication connection(s) 112 that allow the device 100 to communicate with other devices, such as with other computing devices through network 120. Communications connection(s) 112 is an example of communication media. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared, and other wireless media.
Device 100 may also have input device(s) 114 such as keyboard, mouse, pen, voice input device, touch input device, laser range finder, infra-red cameras, video input devices, and/or any other input device. Output device(s) 116 such as one or more displays, speakers, printers, and/or any other output device may also be included.
Those skilled in the art will realize that storage devices utilized to store computer readable instructions may be distributed across a network. For example, a remote computer accessible via network 120 may store computer readable instructions to implement one or more embodiments of the invention. A local or terminal computer may access the remote computer and download a part or all of the computer readable instructions for execution. Alternatively, the local computer may download pieces of the computer readable instructions as needed, or distributively process by executing some instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art, all or a portion of the computer readable instructions may be carried out by a dedicated circuit, such as a Digital Signal Processor (DSP), programmable logic array, and the like.
Turning to
In one embodiment, program 202 and classloader 204 may be implemented on computing device 100. Program 202 and classloader 204 may be stored on computing device 100, on remote systems that may communicate with computing device 100 over network 120, or any combination thereof.
Classloader 204 includes a class_for_name application program interface (API) 206 and a class_from_type API 208. In one embodiment, class_for_name API 206 is provided a classname and an assembly name and the corresponding class object is returned. In one embodiment, class_from_type API 208 is provided a type object and the corresponding class object is returned.
Classloader 204 may include a type cache 210 and a class cache 220. Type cache 210 may include a type object 212. A mapping 230 may be used to map between type object 212 and a classname 212B in type cache 210 associated with type object 212. Type object 212 may include an assembly 212A. Assembly 212A includes the assembly where the type object is located. Assembly 212A may include a reference to the location of the assembly and the assembly name.
Class cache 220 may include a class object 222 that includes a classname 222A. Class object 222 represents corresponding type object 212. A mapping 232 may be used to map between class object 222 and type object 212. Mapping 232 may include pointers and the like. As will be described below, embodiments of the invention maintain a one-to-one correspondence between class objects and type objects.
A single object is shown in each cache in
Embodiments of the invention use type cache 210 and class cache 220 to load classes in an assembly-sensitive manner at runtime. A one-to-one correspondence is maintained between type objects and class objects. This one-to-one correspondence enables roundtripping, that is, given a class object, the corresponding type object may be determined, and from this type object, the corresponding class object may be determined.
Embodiments herein also include a two-phase lookup scheme. Classloader 204 may perform looks ups in class cache 220 and type cache 210 to find the desired class object. This two-phase lookup ensures that the class object from the correct assembly is returned to program 202.
Conventional classloaders may load a class object based on a classname provided by the caller, such as a program. The classloader may also accept an assembly name from the caller. The classloading logic may look for the requested class object by classname in the following sequence: 1) look for the class object in an internal cache of class objects that have been loaded previously, 2) look for the class object in the calling assembly, and 3) look for the class object in all loaded assemblies.
If the class object is found, the classloader checks the assembly to which the class object belongs against the assembly referenced by the assembly name provided. If the assemblies match, then the class object is stored in the internal cache for future retrieval and returns the class object to the caller. If the assemblies do not match, then the classloader throws an exception. Thus, conventional classloaders do not support loading two type objects (i.e., class objects) with the same name from different assemblies. Once a class object associated with a particular assembly has been loaded, a class object with the same classname cannot be loaded from a different assembly. Also, conventional classloaders do not offer the capability to find and return the underlying class object given a particular type object.
Turning to
Starting in block 302 of flowchart 300, a lookup of the type cache is performed using the classname provided by the caller. Continuing to decision block 304, if the classname is not found, then the logic proceeds to block 312 (discussed below). In this case, a class having the provided classname has not been loaded. If the classname is found in the type cache, then the logic continues to block 306.
In block 306, the logic maps to the one or more type objects in the type cache associated with the provided classname. It will be appreciated that more than one type object may be associated with a classname. Next, in decision block 308, the logic determines if the assembly referenced by the assembly name provided by the caller matches the assembly of the type object(s). In one embodiment, the provided assembly name is compared to an assembly name of a type object. It will be appreciated that if multiple matching classnames are found in the type cache, then the logic compares each of the associated assemblies of the type objects having matching classnames to the provided assembly name to determine if a match occurs.
If the assemblies match, then the logic proceeds to a block 309 to map to the corresponding class object in the class cache and then to block 310 to return the class object to the caller. As used herein, returning a class object includes returning a reference to the class object, such as a memory address.
Referring to
In decision block 308, if the assemblies do not match, then the logic continues to block 312. This is the case where a class having the provided classname has been loaded from an assembly other than the assembly name provided in the request.
In block 312, a new type object is created from the assembly referenced by the caller in the provided assembly name. Next, in block 314, a new class object corresponding to the new type object is created.
Continuing to block 316, the type cache is loaded with the new type object. When loaded, the new type object is mapped to an associated classname in the type cache. Next, in block 318, the class cache is loaded with the new class object and mapped to the new type object. After block 318, the logic proceeds to block 310 to return the new class object to the caller.
Referring to
Turning to
Starting in block 502 of flowchart 500, a lookup of the classname in the class cache from the type object provided by the caller is performed. The provided type object includes a type name that is used as the classname for the lookup in the class cache.
Next, in decision block 504, the logic determines if the classname is found in the class cache. If the classname is not found, then the logic proceeds to block 512 (discussed below). If the classname is found, then the logic maps to the corresponding type object in the type cache, as shown in block 506. After block 506, the logic proceeds to decision block 508 to determine if the assembly of the provided type object matches the assembly of the type object in the type cache. In one embodiment, the assembly names are compared to determine a match. If the assemblies match, then the logic continues to block 510 to return the corresponding class object from the class cache. If the assemblies do not match, then the logic proceeds to block 512.
In block 512, a new class object is created to represent the type object provided by the caller. Next, in block 514, the type cache is loaded with the provided type object. The classname associated with the type object is mapped to the provided type object. This classname is the type name of the provided type object.
Continuing to block 516, the new class object is loaded in the class cache corresponding to the type object with a mapping to the type object in the type cache. Next, the new class object is returned to the caller, as shown in block 510.
Embodiments of the invention provide classloading of .NET types in an assembly sensitive manner from J# code. Embodiments herein enable a program to request class objects having the same name from different assemblies. A program may request a class object from a particular assembly even though a class object with the same name from a different assembly has been previously loaded.
Various operations of embodiments of the present invention are described herein. In one embodiment, one or more of the operations described may constitute computer readable instructions stored on computer readable media, which if executed by a computing device, will cause the computing device to perform the operations described. The order in which some or all of the operations are described should not be construed as to imply that these operations are necessarily order dependent. Alternative ordering will be appreciated by one skilled in the art having the benefit of this description. Further, it will be understood that not all operations are necessarily present in each embodiment of the invention.
The above description of embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. While specific embodiments and examples of the invention are described herein for illustrative purposes, various equivalent modifications are possible, as those skilled in the relevant art will recognize. These modifications may be made to embodiments of the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification. Rather, the following claims are to be construed in accordance with established doctrines of claim interpretation.
