Abstract:
According to one embodiment of the present invention a method is disclosed. The method includes requesting a class to be dynamically loaded during program execution. The class includes an attribute. A properties file is searched for the attribute. An associated delegation policy is found in the properties file. The associated delegation policy is associated with the attribute. The class is loaded by applying the associated delegation policy.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of foreign priority to European Patent Application No. 07119132.4, filed Oct. 23, 2007. 
     BACKGROUND 
     The present disclosure is directed to dynamic class loading, and more particularly to dynamic class loading during computer program execution. 
     In modern programming languages different methods exist to dynamically load interdependent components of an executable code for an application. An example of a programming language is the Java™ programming language, which is an object oriented programming language. In the Java™ programming language the interdependent component refers to a class. An object or an instance may be created or instantiated from a class. In Java™, when the program requests a specific object, a class loader dynamically loads a class in order to instantiate the requested object from the class. The class loader may load files relating to both the class and the way of implementing the class in the application. These files are called .jar files. A class generally refers to one or more referenced classes. When a referenced class is to be loaded, a specific Java™ dedicated delegation policy, called parent first, may apply to the class loader. Indeed, the class loader used to load any referenced class of a given class is the same used to load the parent class itself. In addition, the parent first delegation policy means that when a class loader is requested to load a given class the class loader first delegates to its parent class loader the loading of the class. If there is a failure in the loading of the class by the parent class loader, then the class loader of the parent class will try to load the referenced class itself. 
     A referenced class may correspond to a class which belongs to a third party library, which means that the corresponding .jar files are external files unknown by the class loader of the application. Thus, when executing the loading of a referenced class belonging to a third party library, the class loader refers to the parent class of the referenced class before loading the referenced class. However, as the class loader relates to the application, the class loader does not know how to access the .jar file relating to the referenced class belonging to a third party library. 
     SUMMARY 
     According to one embodiment of the present invention a method is disclosed. The method includes requesting a class to be dynamically loaded during program execution. The class includes an attribute. A properties file is searched for the attribute. An associated delegation policy is found in the properties file. The associated delegation policy is associated with the attribute. The class is loaded by applying the associated delegation policy. 
    
    
     
       DRAWING DESCRIPTION 
       Reference will now be made, by way of example, to the accompanying drawings. 
         FIG. 1  shows a definition of a class which belongs to the application and which refers to some other classes, belonging either to the application itself or to a third party library, in accordance with one embodiment of the invention, given by way of example. 
         FIG. 2  shows an algorithm followed by the class loader in accordance with one embodiment of the invention, given by way of example. 
         FIG. 3  shows a flowchart of the method in accordance with one embodiment of the invention, given by way of example. 
         FIG. 4  shows another algorithm followed by the class loader in accordance with one embodiment of the invention, given by way of example. 
     
    
    
     DETAILED DESCRIPTION 
     A Java™ application executes a program, which uses internal and external classes. Each class includes data and functions. Functions are associated with the method to process the data. Thus, the Java™ application uses two types of files referring to internal and external classes. The first type of file contains internal classes and it is an internal file of the application called an internal jar file. As shown in  FIG. 1 , the internal jar file comprises internal classes having the form of InternalClass&lt;x&gt; and belongs to the application. The second type of file contains external classes and it is an external file of the application called an external jar file. The external jar file comprises external classes having the form of ExternalClass&lt;x&gt; and belongs to an external library. The internal jar file includes files relating to classes and files relating to resources associated to the application. Internal classes reference external classes which means that the internal classes are identified as being parent of the external classes. A specific class path refers to each jar file. Thus, an internal class path refers to the internal jar file and an external class path refers to the external jar file. For each internal class an internal class loader runs when the program requests an internal class. The class loader allows a specific class requested when executing a program of the application to be loaded. The internal class loader uses the common delegation policy of Java™. Thus, before loading a requested class, the class loader of the child class may check its parent class loader. Thus, if the parent class loader is not able to load the class, then the child class loader will try to load the class. 
     When the program requests a class referenced by an internal class, a specific customized class loader may be instantiated in order to load that class. The instantiated class loader has a dynamic delegation policy. 
     Thus, depending on an attribute of the requested class a class loader is instantiated with a specific delegation policy. In the current embodiment, the attribute is a class name. The delegation policy is defined in a properties file. The properties file defines, for each class, a specific delegation policy referring either to a parent first delegation policy or parent last delegation policy. Thus, when the program requests a class, the properties file defines the matching between the requested class and the associated delegation policy as will be described below. 
     When the application needs to use resources or classes belonging to external libraries and when classes of the application, i.e. internal classes, reference such external libraries, a specific and customized class loader may be instantiated as shown in  FIG. 3 . Thus, when the program requests a class as indicated in step  300 , the algorithm described in  FIG. 2  is launched to create the customized class loader. In a step  300 , the program requests an external class to be loaded. The class loader of the application has a dynamic delegation policy. Thus, as shown in step  302 , before loading the requested class by applying the common parent first delegation policy of Java™, the class loader first searches for the requested class in the properties file as defined above. Then, in a step  304 , the class loader may find in the properties file the associated delegation policy which matches the requested class. The properties file may specify a delegation policy of a group or class. For instance, a specific kind of class such as all the classes belonging to the package “com.ibm.xyz” may be defined as having a parent last delegation policy and all the other classes have a parent first delegation policy. In a step  306 , the class loader loads the requested class by applying the associated delegation policy found in the properties file. 
     It may occur that the application needs to use the services implemented by an external library. This may imply that the services are accessed through a common interface defined inside the application (i.e. com.ibm.myapp.IService) and implemented in an application class called com.ibm.myapp.service.Servicelmpl1. Thus, when the application requests the services, the class com.ibm.myapp.service.Servicelmpl1 may be instantiated as described in  FIG. 4 . 
     With the system described, all the classes of the application may be archived into a single jar file without losing the capability to determine at runtime which version of the external libraries to load. In this way, we are able to improve the isolation between the core application code and the external services allowing the application to load its version of the external library without affecting other components of the application itself and without the need to split the application code into several separate jar files. 
     It will be appreciated that the examples described above relate to the loading of classes. Other alternatives may exist relating to any kind of resources that are loaded through a class loader, which fall within the scope of the present disclosure. 
     Embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. An embodiment that is implemented in software may include, but is not limited to, firmware, resident software, microcode, etc. 
     Furthermore, embodiments may take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. 
     The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD. 
     A data processing system suitable for storing and/or executing program code may include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. 
     Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. 
     Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems and Ethernet cards are just a few of the currently available types of network adapters. 
     This disclosure has been presented for purposes of illustration and description but is not intended to be exhaustive or limiting. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments were chosen and described in order to explain principles and practical application, and to enable others of ordinary skill in the art to understand the disclosure for various embodiments with various modifications as are suited to the particular use contemplated.