CN1252591C - dynamic class encapsulation - Google Patents

Abstract

Methods and computer-readable media are provided herein for a software tool for subdividing a program into autonomous modules that enable specific functions of the program to be performed. An illustrated method includes a computer-implemented method for identifying modules of an executable program. The method starts by launching the executable program. It is then monitored while the program is running. Monitoring the executable also includes identifying an associated class for each module, where each module corresponds to a specific function of the executable.

Description

dynamic class encapsulation

Copyright recognition

A portion of the disclosure of this patent document includes the subject matter protected by copyright. The copyright owner has no objection to the appearance of copies of the patent document or patent publication in the patent files and records of the Patent and Trademark Office, but if the patent document or copies of the patent publication appear elsewhere, The copyright owner will be held accountable.

Cross References to Related Applications

This application is related to U.S. Patent Application No. ______ (Attorney Docket No. AP117HO), filed on the same date as this application, entitled "DYNAMICJAVA CLASS LOADING FOR APPLICATION EXECUTION.", which is hereby incorporated by reference for refer to.

Background of the invention

1 technical field

In general, the present invention relates to methods and apparatus for a software tool of an executable program, and more particularly, for identifying modules and associating classes with each module of the executable program.

2 Related technical description

Downloading applications via a distributed network, such as the Internet, offers attractive benefits, both for users and for software companies. However, as the complexity and size of the application increases, so does the time required to download the application. Unfortunately, dial-up users had to forego downloading applications over the Internet due to download time constraints.

FIG. 1 illustrates a block diagram 100 describing the prior art way of downloading an executable application program from the Internet to run a Java application through a web browser (such as Internet Explorer ^™ or Netscape Navigator ^™ ) program. Server 102 has a hypertext markup language (HTML) page 104 . The HTML page 104 is downloaded to the user 108 via a web browser 110 via the Internet. An ActiveX control is included in the web browser or downloaded to the user 108 . The ActiveX control contains Object Linking and Embedding (OLE) Control (OCX) 114, a zip file 116 containing the Java program and class files, and an .inf file that provides the system with the information necessary to install the OCX 114 and zip file 116. Once the ActiveX control is implemented, the Java program, OCX, zip file and .inf file from the zip file 116 are packaged into a .cab file. Thus, ActiveX installs the .cab file and unzips the zip file, and runs various Java applications through the web browser.

As described above with reference to FIG. 1 , the obstacles caused by the method of downloading application programs in the prior art make users give up downloading application programs through the Internet. For example, using a 56K dial-up modem, it takes about 5 minutes to download and install a typical .cab file. Also, the entire .cab file must be downloaded before running the application. Since the zip file contains all the classes of the Java application, even if the user does not use some of the classes, he must wait for all the classes to be downloaded. As the functionality of the software is enhanced, or more specific functions are added to the software, this waiting time will become longer as the .cab file becomes larger.

This problem does not only exist when the application is initially downloaded, but also extends to modifications to the current application. For example, if a 1K byte modification is made to an existing program to provide a new version or update, the user has to download the entire application or receive a disk with the revised application. To save money, software companies encourage users to download files over the Internet, rather than providing CDs or floppy disks of new or revised applications. It is also advantageous for the user to be able to conveniently download applications over the Internet, since the costs associated with the CD or floppy disk ultimately still fall on the user. Although patches are available in some cases, their management has become cumbersome, and updating with patches is therefore not desirable. Also, the patch fails to locate the company(?) involved in the program's initial download.

When downloading an executable program from the Internet, another factor that causes the required time to be too long is that the entire program needs to be downloaded, including all characteristic functions related to the program. Since there is a lack of a tool that can divide an executable program into modules and know how each class in each module is used by the module, it is necessary to download the entire application. The amount of work required to manually analyze the jumble of code to map the interactions between the various classes and modules is daunting. With the increasing complexity of the program, due to the larger scale of the program, manual analysis cannot be easily achieved. Even a trivial change in code requires another full manual analysis. In addition, in order to manually analyze a program, it is necessary to be able to obtain the expert opinion of the author of the code, and it is difficult to meet this luxury in the current rapidly developing environment.

Therefore, in order to solve the above-mentioned problems, there is a need for a tool that combines classes in groups to generate modules of executable programs that can be independently downloaded over a distributed network such as the Internet.

Summary of the invention

In general, the present invention addresses these needs by providing a method and apparatus for monitoring tools for recording and dividing an application into modules. It should be understood that the present invention can be implemented in various ways, including a process, an apparatus, a system or a device. Several examples of the present invention will be described below.

In one example, a computer-implemented method for identifying modules of an executable program is provided. The method first starts the executable program and then monitors the executable program while it is running. Monitoring the executable program also includes identifying the associated class of each module, where each module corresponds to a specific function of the executable program. The monitoring also includes generating a data structure for each module during execution of the executable. Here, the data structures define classes for each specific functionality.

In another example, a method for generating a class diagram showing how modules of an executable program use classes of the executable program is provided. Initially, the executable is monitored while the executable is running. Subsequently, each class associated with a core module is identified. The core module is the engine used to run the program. Then, while monitoring the program, each task related to the program is performed. And record every class used in the execution of each task. Then, define a class diagram for the core module and each task, and each class diagram defines the interrelationship of the classes in the core module and each task.

In another example of the present invention, a method for subdividing an executable program into autonomous modules is also provided, wherein each module corresponds to a task. To start, run the program first. Subsequently, the operation of the program is monitored. Next, keep a record of the classes used during each task run. Then define the class diagram of each module. Here, the class diagram represents an interrelationship of classes related to each module.

In another example, a method of developing a software tool for an application is provided. The application includes several specific functions, each of which is associated with at least one class. The method begins by identifying each class of the application. Subsequently, each specific function of the application is run. Then identify each class associated with each specific function. A module is then defined for each specific function, where each module includes a set of identified classes related to a specific function. Here, each module enables a specific function corresponding to the module to be realized.

In another embodiment of the present invention, a method for generating modules of an application program is provided. The module is able to autonomously run a specific function of the application. The method begins by launching the application. Subsequently, a class loader is requested to load a class. Next, the class loader is monitored as each class of the module is loaded. Document every class of this module. Subsequently, an endpoint is detected (the endpoint indicates that all classes of the module have been loaded). Then, repeat the request, monitor, record and instrument operations for the remaining modules of the application.

In another example, a computer readable medium having stored thereon computer instructions for generating a class diagram is provided. The class diagram shows how an executable's modules use the executable's classes. The computer-readable medium includes program instructions for monitoring the executable program during execution. Also included are program instructions identifying each class associated with a core module running an engine of the program. The computer-readable medium includes program instructions for performing each task associated with the executable program while the program is being monitored. Also contains program instructions for recording each class used in each task execution. Also contains program instructions for defining a class diagram for the core module and each task, where each class diagram defines the interaction of the classes in the core module and each task.

The advantages of the invention are numerous. Most notably, the monitoring tool allows for the breakdown of an executable during its execution. In addition, the invention allows taking a complex program and defining modules capable of providing an autonomous program connected by the user, independently downloading the program to the user's computer via a distributed network.

Other aspects and advantages of the present invention will become apparent from the following detailed description of examples of the present invention, taken in conjunction with the accompanying drawings.

Figure overview

The present invention can be better understood through the following detailed description in conjunction with the accompanying drawings, wherein similar reference symbols indicate similar structural components.

Figure 1 illustrates a block diagram describing the previous way of downloading an executable program from the Internet in order to run a Java program through a web browser.

FIG. 2 illustrates a flowchart describing a method for downloading an application program from the Internet according to an example of the present invention.

Figure 3 illustrates a flow diagram of a higher level method in which a Java loader downloads and installs the application according to an embodiment of the present invention.

FIG. 4 shows a block diagram illustrating the list of modules downloaded in operation 146 of FIG. 3 in accordance with an example of the present invention.

FIG. 5 illustrates a flowchart showing a method for downloading and installing modules of an application program as needed while it is running, according to an example of the present invention.

FIG. 6 illustrates a flow chart describing in more detail a method of downloading modules of an application program according to an embodiment of the present invention.

FIG. 7 shows a flow diagram describing in more detail operation 190 of FIG. 6 in which, according to an example of the present invention, a class loader thread is used to locate a module containing the requested class.

FIG. 8 shows a flowchart representing a method for performing background downloads in a multi-threaded environment with the main application started according to the present invention.

Fig. 9 is a block diagram representing a prioritized list of modules of an application program to be downloaded according to an example of the present invention.

FIG. 10 shows a flowchart describing in more detail operation 208 of FIG. 7, in which a module is downloaded in a multi-threaded environment under the download manager logic, according to an example of the present invention.

Fig. 11 shows a flowchart showing a method for monitoring the installation of classes of an executable program to generate modules for specific functions of the program, according to an example of the present invention.

Fig. 12A shows a block diagram depicting a list of classes constituting a module of an application program according to an example of the present invention.

Fig. 12B illustrates a class diagram of module 1 of Fig. 12A, according to an example of the present invention.

Fig. 13 illustrates an example of monitoring a part of the output of an application program while it is executing, according to an example of the present invention.

Figure 14 illustrates a partial list and GIF file of classes of a core module captured by the monitoring program from a greeting card application, according to an example of the present invention.

Recommended example details

Described is a software tool that identifies classes used in individual groups or modules of an executable program to facilitate efficient downloading of the executable program from the Internet. It will be apparent, however, to one skilled in the art that some or all of these specific details may be omitted in practicing the present invention. On the other hand, in order to describe the present invention more clearly, some well-known processing operations are not described in detail here.

Embodiments of the present invention provide a method and an apparatus for timely downloading of applications from the Internet. In order to speed up the downloading of a program, in an example of the present invention, the program is first divided into software modules. The principle of module selection is that each module contains all the classes necessary to perform a specified program task. As used herein, being able to efficiently process and download an instance of an application or component is generic to any type of application or application component. However, for ease of explanation, the following will refer to a printer and the application options available to a user of that printer. These applications and options are available at the vendor's web site (for example). For example, a module can contain all the classes used to generate a graphical user interface (GUI). Another for selecting and downloading an image, a third for printing, a fourth for rotating or cropping an image, and so on. At least one module must contain the core classes necessary to run the engine of the application in this instance. The core module can receive instructions from the command bus, or, preferably, the core module downloads and installs a GUI to provide a more convenient interface for the user.

When it comes time to download an application, only the core modules, which are much smaller than the entire executable, are downloaded. Naturally, the time to download a core module is much less than the time to download the entire file. In one example, the core module then downloads and installs a GUI module that can provide the user with different program options. While running the program, when the user selects an option that is not part of the core module, the core module checks to see if a module that implements the selected option is locally available. If the required module cannot be obtained, the required module is downloaded from the web and automatically uninstalled into the running program. A description of the method is found in US Patent Application No. ______ (Attorney Docket No. AP117HO).

In order to efficiently download the executable program, the program needs to be properly divided into autonomous class modules. As programs grow in complexity, it becomes increasingly impossible to identify all the classes used by a given task or group of tasks. The present invention subdivides a large number of classes into autonomous modules by providing a monitoring tool to record the classes used by the modules of the program.

In one example, after a software package is complete and ready for use, a monitoring program observes the execution of the software package and records all classes used during the execution of selected tasks. As previously mentioned, an application and its options may be any type of application executable by one or more processing entities. In the example of a printer connected to a personal computer, the selected task may be a task related to printing or editing an image or text file. More specifically, tasks such as rotating, printing, grading, and inserting text can be included. The monitor then defines a module for each task that contains all the classes used to implement that task.

In another example of the invention, duplicate classes from multiple modules can be moved into a common module, or placed only in the most frequently used modules. Incomplete modules that require the use of additional classes remain linked with the target module containing the classes they require. Alternatively, classes that are common to multiple modules can be inserted into the core module so that they are always available after the core module is initially downloaded to run the application's engine.

FIG. 2 illustrates a flowchart 122 outlining a method for downloading an application from the Internet, according to an example of the present invention. Flowchart 122 begins with operation 124, where a web site offering application options is accessed. As previously mentioned, an application and its options may be any type of application executable by one or more processing entities. In the example of a printer connected to a PC, an application could include functionality for generating greeting cards, invitations, book covers, art templates, document cards, gift wrap, gift boxes, and more. Subsequently, operation 126 is performed, where a content category is selected from a list of options. The user selects one of the aforementioned applications from operation 124, and the user is presented with a list of content categories. For example, a user may choose to make a greeting card, and subsequently, the user is presented with a list of content categories to be used in the greeting card. Of course, any number of images suitable for a greeting card may be present here, for example, an floral arrangement, a print, a movie star photo, etc. Then, at operation 128, a selection of images for the selected content category is provided. In one example, the image is stored in a database. Thereafter, the method proceeds to operation 130 to record the identifier of the selected image. Here, the image is stored for later use by the Java application.

Continuing with FIG. 2, at operation 132, printer and paper information is collected. In one example, printer model, paper size, margin information, etc. are collected. Next, in operation 134, a boot loader is downloaded, where the web browser downloads and installs a .cab file for loading a Java application and various modules associated with the application. In operation 136, a security option is presented to the user. In one example, if the user declines the security option, the method aborts. Assuming the user accepts the security options, the method proceeds to operation 138 where the web browser decompresses and installs the boot loader, ie, the .cab file. Then, in operation 140, a boot loader is executed. In one example, the boot loader is in the form of an ActiveX control. In step 142, the bootloader starts a Java loader. In one example, the Java loader is included in a .cab file. As will be described in detail below, the Java loader can download desired applications in an efficient and convenient manner, even if the user is using a relatively slow Internet connection. That is, the application is immediately available regardless of whether all components required for a task have been downloaded.

FIG. 3 shows a flowchart 144 describing a high-level method in which, according to an example of the present invention, the Java loader downloads and installs the application and its components. The method begins at operation 146 in which a list of modules used by the application of operation 124 is downloaded. In one example, the module list includes the names of the modules and version information of the modules. An example of a voting list is given in Figure 4, which will be described in detail below.

In FIG. 4, block diagram 158 shows a list of modules downloaded in operation 146 of FIG. 3, according to one example of the present invention. It should be understood that the list of modules in block diagram 158 are examples of modules only and that any number of modules may exist depending on the software application and its application. Considering the previously described application program 160, a core module and a number of non-core modules are shown. Here, core module version 1162 has been replaced by core module version 2164. Therefore, the list of modules downloaded in operation 146 of FIG. 3 contains only the latest version of the core module, ie, version 2164. It should be understood that core module version 1 is shown for illustrative purposes only. The list of Figure 4 also includes modules 1-5, represented by boxes 166-174. In one example of the invention, the list of modules used by the application is compared to modules on the local system to determine which modules the system needs to download.

Returning to Fig. 3, entering operation 148, the Java loader checks each module in the list to confirm whether the module exists in the local system. For example, check each of the modules in Figure 4, ie, modules 166-174, to see if they are present in the local system. Next, in operation 150, any old module versions identified in operation 148 are not installed. For example, if the local system has already loaded core module version 1162 from a previous use of the application, it will not be reinstalled here. Also, if any older versions of non-core modules exist on the local system, those modules are no longer installed. In one example, if an older version of a non-core module is a shared module, the non-core module is no longer installed. Subsequently, a decision operation 152 is made to determine whether the latest version of the core module is present on the system. If not, the latest version of the core module is downloaded and installed in operation 154 . In one example of the invention, a core module contains classes with entry points. In another example of the invention, the Java loader requests a class with an entry point to initiate the download of the core module. If the latest version of the core module is on the system, proceed to operation 156 to start the application program.

FIG. 5 shows a flowchart 176 describing a method according to an example of the present invention, ie, downloading and installing modules as needed while the application is running. Flowchart 176 begins with operation 178 to run the application on the local system. It should be understood that when the user runs the application and uses different functions, eventually a module other than the core module will be required. Continuing with the example above about a printer, for some operations such as printing, editing, formatting, etc., classes not included in the core module will be required. Operation 180 then proceeds to identify the modules containing the required classes. In operation 182, the modules containing the required classes are downloaded and installed on the local system. For example, referring to FIG. 4, if a particular function of the application requires module 4172, module 4172 is downloaded and installed. Proceeding to operation 184, the specific function provided by the class of the downloaded module is executed. After operation 184, return to operation 178 to continue running the application. Of course, the application's components typically run in the background. A user can abort or exit the application as desired.

FIG. 6 shows a flowchart 186 which describes in more detail how modules of the application are downloaded according to an example of the present invention. Flowchart 186 begins with operation 188, which receives a request from a Java Virtual Machine (JVM). For example, when the application is initially started, a class loader will receive a request from the Java virtual machine to run the main class in an instance. In another example, the main class is included in a core module. It should be understood that the Java virtual machine is concerned with classes, not modules, and class loaders map classes into modules.

Subsequently, operation 190 is performed to find out the module containing the class. Operation 190 will be described in detail with reference to FIG. 7 . Next, in decision operation 192, it is determined whether the module found in operation 190 is already installed on the local system. If not, the module is downloaded and installed in operation 194 . If the module is already installed on the local system, the method proceeds from operation 192 to operation 196 to obtain the desired class object from the module.

After the method of FIG. 6 obtains the class object from the module, the method returns to operation 188 . In one instance, the class object is returned to the Java virtual machine. It should be understood that when the application is initially loaded into the local system, the class containing the entry point requests the next class, and so on, until all related classes are loaded. In one instance, the main class containing the entry point is mapped into the core module. Following a given example, class A contains the entry point, and once initialized, the Java virtual machine first requests class A. Class A in turn requests class B, and so on, until all related classes that make up the core module have been loaded.

The examples above are also applicable to other non-core modules that perform specific functions. Once the classes containing the core modules are loaded, the user can select tasks that require specific functionality. In the example of a printer and its application, a user may wish to rotate or print an image. Once the spin or print buttons are triggered, the code will ask the Java virtual machine for a class that will allow the specific functionality. Accordingly, the Java virtual machine will request the class required for that particular function, repeating operations 188-196 for the requested class and all of its related classes. As will be described in detail below with reference to FIGS. 8-10 , in another example, modules that enable certain functions may be downloaded in the background prior to being requested by the user.

Flowchart 190 begins at operation 198, where the Java virtual machine requests the class loader to load a class. Operation 200 then proceeds to search the loaded modules for the requested class. Those skilled in the art can understand that the Java virtual machine can use various techniques to search the data structure of the requested class. Subsequently, a decision operation 202 is made to determine whether the requested class was found. If the class is found in a module loaded into the local system, then in operation 194 the class is returned to the Java virtual machine.

If the class is not found, the method in FIG. 7 proceeds to operation 206 to query the server which module contains the requested class. In one instance, each class is associated with a module on the server, ie the server has a data structure that matches classes to modules. Thus, in one example of the invention, the module containing the requested class is identified here. In operation 208, the module containing the requested class is downloaded. In one example, the modules are downloaded per related class as described with reference to FIG. 6 . In another instance, downloaded modules are also installed. Table 1 below contains the code that is used to install the module according to an example of the present invention. Of course, the code can be in any format, as long as it can complete the installation function.

Table 1

           
*Copyright 1995-2001 EPSON Palo Alto Laboratory.All Rights

Reserved.

//Load the package contained in Zf.

public static void installPackage(File zFile) throws IOException{

  ZipFile zf = new ZipFile(zFile);

  try {

     ArchiveInfo ai = new ArchiveInfo(zf);

     //Save the source file

     for(Enumeration e=zf.entries(); e.hasMoreElements();){

         ZipEntry ze = (ZipEntry) e.nextElement();

         String zipName = ze. getName();

         if(!zipName.endsWith(“.class”)){

           ze = zf.getEntry(zipName);

           zipName = zipName. replace('\\', '/');

           InputStream is = zf.getInputStream(ze);

           if(ai.isSharedModule()){

              saveResource(SmartLauncher. getSharedResourceDir(), zipName, is);

           }else{

             saveResource(SmartLauncher. getAppResourceDir(), zipName, is); }

         }

}
				
<dp n="d10"/>
//Search for system class files and load them into the shared class directory

for(Enumeration e=ai.getSystemClasses().elements(); e.hasMoreElements();){

      String sysClass = (String) e. nextElement();

      ZipEntry ze = getZipEntryFromClassName(zf, sysClass);

      if(ze==null){

         throw new IOException("Can not find system class"+sysClass);

      }

      InputStream is = zf.getInputStream(ze);

      saveClass(SmartLauncher. getSharedSystemClassDir(), sysClass, is);

      }

//Search for system class files and load them into the shared class directory

for(Enumeration e=ai.getSystemResources().elements(); e.hasMoreElements();){

   String sysResource = (String) e. nextElement();

   ZipEntry ze = zf.getEntry(sysResource);

   if(ze==null){

      throw new IOException("Can not find system class"+sysResource);

   }

    InputStream is = zf.getInputStream(ze);

    SaveResource(SmartLauncher. getSharedSystemClassDir(), sysResource, is);

}

// call the install function

if(ai.getMetaClass()!=null){

      try {

          InstallClassLoader installLoader = new InstallClassLoader(zf);

          Class clsMeta = installLoader.loadClass(ai.getMetaClass(), true);

          Object mc = clsMeta newInstance();

          Class[] clsParams = {java.util.Hashtable.class};

          Method m = clsMeta.getMethod("install", clsParams);

          Object[] objParams = {createInstallProperties(getSmartClassLoader(), zf)};

          // call the install function

          m. invoke(mc, objParams);

      }catch(Exception e){

       // cannot call meta class installation

       System.out.println("Install function ignored in class"+ai.getMetaClass());

      }

  }

}finally{

     zf. close();

}

        

FIG. 8 illustrates a flowchart 210 depicting a method for performing a background download in a multi-threaded environment while the main application program is running, in accordance with an example of the present invention. It should be understood that the method in flowchart 210 may operate in a multi-threaded environment using the method described with reference to FIG. 7 . Flowchart 210 begins with operation 212, accessing a list of modules to download. In one example, the module list includes a priority list representing the order in which modules are downloaded in the background environment. An example of a priority list is described below with reference to FIG. 9 .

FIG. 9 illustrates a block diagram 224 representing a prioritized list of various modules to download for an application, according to an example of the present invention. As depicted by block 224, each module containing the application is assigned a priority. For example, core module (Mc) 226 is assigned a priority of 1, the highest priority. The core module must be downloaded first, therefore, Mc must receive the highest priority. The remaining modules M1-M5 are assigned priorities 2-6, respectively. In one example, the priority list is maintained in a networked resource server (eg, that contains the application and its modules). As explained further below, the local system may have installed some of these modules during previous executions of the application. In this case, the download manager is initially set with a list of modules that need to be downloaded, thus ensuring that the download manager does not download modules that are already installed. In an example of the present invention, the module list may also be the module list in FIG. 4, which includes priorities.

Returning to FIG. 8, once the priority list is obtained in operation 212, operation 214 is performed to check whether all modules have been downloaded to the local system. At this point, check the lists described with reference to Figures 3, 4 and 9 to determine which modules need to be downloaded. If all the modules in the list are installed in the local system, then in operation 216, the method ends. If not, proceed to operation 218 to obtain the name of a module to be downloaded. For example, if Mc and M2 already exist in the local system, the module name of M1 is obtained in operation 218 because M1 has the highest priority among the remaining modules. In operation 220, a module corresponding to the module name obtained in operation 218 is downloaded. The downloaded modules are then installed in operation 222 . It should be understood that the code shown in Table 1 for installing modules may be executed in operation 222 according to an example of the present invention. The loop including operations 214-222 is repeated until all modules are downloaded.

FIG. 10 shows a flowchart 230 describing operation 208 of FIG. 7 in more detail. Here, according to an example of the present invention, under the download manager logic, a module is downloaded in a multi-thread environment. Flowchart 208 begins with operation 232, where the download manager requests modules to be downloaded. It should be understood that the class loader also has control here. In decision operation 234, it is determined whether the requested module is a module being downloaded by the download manager. If yes, then proceed to operation 236, the method waits until the download manager finishes downloading the module. It should be understood that common waiting techniques well known in the art may be used in this operation.

In decision operation 234 of FIG. 10 , if the requested module is not the module being downloaded by the download manager, then enter operation 240 and the current download operation is suspended. For example, a user wishes to rotate an image, module 4 (M4) is required to complete that specific function. However, the Download Manager is downloading Module 3 (M3). Then, in operation 240, the download of M3 is suspended, so that M4 can be downloaded without competing with M3 for bandwidth. In one embodiment of the present invention, the download manager logic that includes this decision operation is initiated only if the user interrupts the download of sequential modules controlled by the priority table. In operation 242, the requested module is downloaded. Continuing with the example above, here, M4 will be downloaded while M3 is paused. In one instance, another code example that downloaded M3 was used to download M4. In operation 244, the requested modules are installed. Next, the method proceeds to operation 246 to resume the interrupted downloading thread. Referring to the above example, after installing M4, resume the download of M3. Then, at operation 248, the method begins operation 220 in FIG. 8 by downloading the module.

Table 2 below contains illustrative code for a class loader according to one example of the present invention. Of course, the code can be in any format as long as it can complete the class loading function.

Table 2

           
/*

*

*SWorkfile: SmartClassLoader.java$

*

*

*

*Copyright1995-2001EPSON Palo Alto Laboratory.All Rights Reserved.

*

*EPSON Research and Development, Inc. A Seiko EPSON Subsidiary.*All rights

reserved.

*

*/

package epal.compman;

import java.util.*;

import java.util.zip.*;

import java.io.*;

import java.net.*;

importjava.lang.*;

import java.lang.reflect.*;

/**

*The following is the class description.

*
				
<dp n="d13"/>
*

*/

public class SmartClassLoader extends java.lang.ClassLoader{

    //The mapping from the class name to the loaded class object.

    private Hashtable m_classCache = new Hashtable();

    // Mapping from package name to archive file.

    private Hashtable m_packageMap = new Hashtable();

    //Map from class name to archive file.

    private Hashtable m_classMap = new Hashtable();

    //Map from resource name to archive file.

    private Hashtable m_resourceMap = new Hashtable();

    public SmartClassLoader() throws IOException{

      super();

    }

    public URL getResource(String name){

      URL url = getSystemResource(name);

      if(urI!=null)

      return url;

      String szResourceFile = name.replace('/', File.separatorChar);

      File f = new File(SmartLauncher.getAppResourceDir(), szResourceFile);

      try {

        return new URL("file", "localhost", f.getAbsolutePath());

      }catch(Exception e){

       return null;

      }

    }

    public InputStream getResourceAsStream(String name){

      InputStream is = getSystemResourceAsStream(name);

      if(is!=null)

         return is;

      String szResourceFile = name.replace('/', File.separatorChar);

      File f = new File(SmartLauncher.getAppResourceDir(), szResourceFile);

      try {

        return new FileInputStream(f);

      }catch(Exception e){

       return null;

      }

    }

    protected Class loadClass(String name, boolear resolve) throws

ClassNotFoundException{

//System.out.println(name);

    if(name.indexOf("PIMJpegNative")!=-1){
				
<dp n="d14"/>
inti=10;

}

if(name.indexOf("JopsDecoder")!=-1){

int i=10;

}

// Check if the class has been loaded before.

Class c＝(Class)m_classCache.get(name);

if(c!=null){

if(resolve){

resolveClass(c);

}

return c;

}

ArchiveInfo ai=(ArchiveInfo)m_classMap.get(name);

if(ai!=null){

// Check the version of the archive information.

// Stealing: Assumption is always OK.

// This class can be loaded from a Zip file.

// Now check if the class should be loaded from the system.

if(ai.getSystemClasses().jndexOf(name)!=-1){

// This is a class that should be installed by the system's class loader.

c = findSystemClass(name);

}else{

  //Load from Zip file.

   ZipEntry ze = SmartLauncher.getZipEntryFromClassName(ai.getZipFile(), name);

try {

c = loadClassFromZipEntry(ai.getZipFile(), ze, name);

}catch(IOException e){

throw new ClassNotFoundException("Can not find class"+name);

}

}

}else{

//This class cannot be loaded from a Zip file.

try {

// Attempt to be loaded by the system.

c = findSystemClass(name);

}catch(Exception e){

//Could not load this class from Zip file or system.

//This class could be:

//1. Category request resource bundle not found.

//2. A class that should be downloaded or installed.

if(isResourceBundleClass(name)){

//VM requests an encapsulated packaging class.

throw new ClassNotFoundException();

}
				
<dp n="d15"/>
//The system cannot find this class, try to download and install this class.

try {

  File f = SmartLauncher.getDownloadManager().getZipFile(name);

  SmartLauncher.getSmartClassLoader().loadPackage(f);

}catch(Exception ioe){

 throw new ClassNotFoundException{ioe. getMessage());

}

ai=(ArchiveInfo)m_classMap.get(name);

if(ai==null){

  // We should find the class here.

  throw new ClassNotFoundException();

} else {

  try {

    if(ai.getSystemClasses().indexOf(name)!=-1){

      // This is a class that should be loaded by the system class loader.

      c = findSystemClass(name);

    } else {

      //Load from Zip file.

      ZipEntry ze=

SmartLauncher.getZipEntryFromClassName(ai.getZipFile(), name);

              c = loadClassFromZipEntry(ai.getZipFile(), ze, name);

             }

           }cateh(Exception ex){

             throw new ClassNotFoundException(ex. getMessage());

           }

        }

     }

  }

  if(resolve){

     resolveClass(c);

  }

  m_classCache. put(name, c);

  return c;

}

public void loadPackages() throws IOException{

   File dir = SmartLauncher.getAppDir();

   String[] zfname = dir.list();

   if(zfname!=null){

      for(int i=0; i<zfname.length; i++){

       if(zfname[i].endsWith(″.zip″)){

         try {

           loadPackage(new File(dir, zfname[i]));

         }catch(ZipException ze){
				
<dp n="d16"/>
File f = new File(dir, zfname[i]);

f.delete();

}

}

  }

}

dir=SmartLauncher.getSharedDir();

zfname = dir.list();

if(zfname!=null){

for(int i=0; i<zfname.length; i++){

if(zfname[i].ehdsWith(″.zip″)){

try {

loadPackage(new File(dir, zfname[i]));

}catch(ZipException ze){

File f = new File(dir, zfname[i]);
the
          f.delete();
}

}

}

}

}

public void loadPackage(File fZipFile) throws IOException{

ZipFile zf = new ZipFile(fZipFile);

ArchiveInfo ai = new ArchiveInfo(zf);

// Load this class.

for(Enumeration e=zf.entries(); e.hasMoreElements();){

ZipEntry ze = (ZipEntry)e.nextElement();

String zipName = ze.getName();

if(zipName.endsWith(″.class″)){

String className＝getClassNameFromZipName(zipName);

m_classMap.put(className, ai);

m_packageMap.put(getPackageName(className), ai);

}else{

zipName = zipName.replace('\\', '/');

m_resourceMap.put(zipName, ai);

}

}

}

//Load a class contained in Ze.

private Class loadClassFromZipEntry(ZipFile zf, ZipEntry ze, String className)
throws IOException{

String szZipName = ze.getName();

InputStream is=zf.getInputStream(ze);

ByteArrayOutputStream baos＝new ByteArrayOutputStream();
				
<dp n="d17"/>
         byte[] tempBuf = new byte[1024];

      int bytesRead = 0;

    try {

      do {

          bytesRead = is.read(tempBuf, 0, 1024);

            if(bytesRead>0){

                baos.write(tempBuf, 0, bytesRead);

          }

        } while(bytesRead>=0);

      }catch(EOFException eofex){

       //This is fine.
      }

   is. close();

   byte[] clsData = baos.toByteArray();

   return defineClass(className, clsData, 0, clsData. length);

}

private String getClassNameFromZipName(String zipName){

   int index = zipName.lastIndexOf(".class");

   if(index<=0)

     return null;

   String className = zipName. replace('/', '.');

   className = className.replace('\\', '.');

   return className.substring(0, index);

 }

 /**

   //Return the package name of a class

 */

 private String getPackageName(String className){

   int index = className.lastIndexOf(″.”);

   if(index<=0)
      return "";

    return className.substring(0, index);

}

private String getBaseclassName(String name){

  int iBegin = Math.max(0, name.lastIndexOf("."));

  int iEnd = name.indexOf("_", iBegin);

  if(iEnd==-1){

     return name;

  }

        

Figure 11 shows a flowchart 250 illustrating a method for monitoring the installation of classes of an executable program to generate modules for specific functions of the program, according to an embodiment of the present invention. Flowchart 250 begins with operation 252, when a command to run the executable is received. Next, at operation 254, a request for a class is generated. In one example, the Java virtual machine requests the class. It should be understood that once the executable program is started, a set of classes, that is, a core module, enables the program to be executed, so that users can immediately use the functions provided by the core module. As mentioned above, once the program is started, the core module contains the main class with the entry point. The method then proceeds to operation 256, which monitors the class loader. In one example, the class loader is monitored by writing another class loader to replace the Java default class loader (the other class loader is an extension of the Java class loader). Then, at operation 258, the requested classes are loaded. In one instance, the requested class is loaded from a file system. Subsequently, operation 260 is performed to record the loaded classes. It should be understood that classes are recorded in a set or vector, thus all related classes contained in a module are recorded. Thus, operation 260 begins with defining the classes that make up the core modules or the classes that make up the modules related to the non-core modules. As mentioned here, a non-core module is a module that contains classes associated with a specific function or task of the program, whereas a core module contains classes necessary to run the application.

The method of FIG. 11 then proceeds to operation 262, at which point the class is returned to the Java virtual machine. In one example, if the class returned to the Java virtual machine is associated with another class, the Java virtual machine will request the associated class and repeat operations 254-262. For example, if class A just downloaded is associated with class B, the Java virtual machine will request class B. Class B is recorded in operation 260, and the associated classes are modeled during runtime of the application. It should be understood that a class may be associated with more than one other class. Along this line, if class B is associated with class C and class J, then the Java virtual machine will request class C and class J. Thus, class diagrams are quickly generated for each module during application runtime. Logic monitoring the application loading process can detect an endpoint indicating that all classes for a particular module have been downloaded. Once the end point is reached, the set or vector in which the classes are recorded is complete. That is, once the last class for that module has been loaded, the class diagram for that module is complete. In one example, the class diagram is stored on a networked resource server. Next, the method of FIG. 11 is repeated for the next module until all modules (representing all specific functions or tasks of the application) have been loaded. As discussed above, each specific function and task can be downloaded on demand by the user, as well as a predictive download or sequential background download. It should be understood that once the core module is loaded, the application program can start running, so that the user can perform the functions provided by the core module.

Fig. 12A shows a block diagram illustrating a list of classes constituting a module of an application program according to an example of the present invention. Module 1264 includes classes A, B, C, F, J, and H, while module 2266 includes classes D, E, and G. In one example, module 1264 may represent the core modules of an application, while modules 2266 represent some specific functions. In the greeting card example mentioned earlier, the core module 264 contains all the classes necessary to run the greeting card application engine, and module 2266 contains the classes necessary for a specific function or task, such as printing, editing, rotating, inserting text etc. In Figure 12B, only two modules are shown, in fact the application can be subdivided into any number of modules.

FIG. 12B shows a class diagram of module 1264 of FIG. 12A according to an example of the present invention. As shown in Figure 12B, class A 268 is related to class B 270, which in turn is related to class C 272 and class J 278, and so on. In one example, once all classes of module 1264 have been loaded and recorded, a class diagram is generated in the form of an image on a networked resource server. This image is quickly generated as each specific function of the application is performed while the monitoring tool monitors and records the application. In one example, the recorded modules are stored on a storage medium in communication with the server. The server then looks at each file and creates a database, an image. In a preferred example, the modules are stored as zip files, each module being associated with a zip file. The server looks at each zip file and creates a data structure. The result is that a class diagram is generated for each module during program runtime, rather than the tedious labor of manually analyzing the code. This class diagram is then used when downloading the application, as described with reference to Figures 7-10.

In one example, a module may contain classes, images, text files, code required by the class (eg, dynamic link libraries (DLLs)), string resources, or other resources capable of exhibiting the properties required by the class.

Fig. 13 shows an example of monitoring a part of the output of an application program while it is running according to an example of the present invention. As Figure 13 shows, multiple classes are logged as they are loaded. It should be understood that in addition to class files, Graphics Interchange Format (GIF) files may also be included in the module. GIF files are used to display various graphic images of applications, however, in another example, Joint Photographic Experts Group (JPEG), Tagged Image File Format (TIFF), etc. may be used instead of the GIF file format. The output shown in Figure 13 is repeated for each property of the application. If in Figure 13 the application has just started, the monitor will capture the core module. As each specific function of the application is used, a module is created and for each module an output similar to Figure 13 is generated.

Fig. 14 shows a partial output and GIF file showing classes captured by the monitoring program from a core module of a greeting card application, according to an example of the present invention. As shown in Figure 14, several files are included in the core module of this application. Along these lines, one can fully appreciate the enormous amount of work required to manually analyze an application's code to determine the interrelationships between the application's classes. Although examples of monitoring tool output are provided in FIGS. 13 and 14, this is not meant to limit the invention. It should be understood that the greeting card application is by way of example only and that the application can be any type of application that can be executed by one or more processing entities.

After monitoring and recording all specific functionality used by the application, it is possible that one or more classes are common to multiple modules. In one instance, duplicate classes are placed in one module, and the remaining modules are provided with links to the module containing the required class. In another example, duplicate classes are included in the core module, because the core module is always the first to be downloaded, and therefore, the common classes are always available. In another example, common classes are moved into a common module that is accessible to modules that require classes in the common module. Examples of the invention allow for redundant possibilities on how to structure the modules of any downloadable application so as to efficiently download the application over a distributed network such as the Internet.

Although the present invention has been described above in connection with an application program running on an operating system associated with a personal computer, it should be understood that the present invention can be implemented by other routines, programs, components, data structures, etc. specific task or to implement a specific abstract data type) implementation. In addition, the present invention is applicable to other computer system architectures, which may include handheld devices, microprocessor systems, microprocessor-based or programmable consumer electronics, microcomputers, mainframe computers, and the like. The invention may also be used in distributed computing systems where tasks are performed by remote processing devices that are linked through a communications network.

With the above examples in mind, it should be understood that the invention may employ various computer-implemented operations involving data stored in computer systems. These operations are those that request physical control of a physical entity. Usually, though not necessarily, these entities take the form of electrical or magnetic signals capable of being stored, transformed, combined, compared, or otherwise manipulated. In addition, the controlling performed generally refers to, for example, generating, identifying, judging or comparing.

Any operations described herein that form part of the invention are useful machine operations. The invention also relates to an apparatus or means for performing these operations, which means may be specially constructed for the required purpose, or it may be a general-purpose computer selectively triggered or activated by a computer program stored therein. set up. Specifically, any general-purpose machine with a computer program written in accordance with the techniques of the present invention may be used, or it may be more convenient to construct a more specialized apparatus to perform the required operations.

The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can be thereafter read by a computer system. Examples of the computer readable medium include hard disk drives, network attached storage (NAS), read only memory, random access memory, CD-ROM, CD-R, CD-RW, magnetic tape, and other optical or non-optical data storage devices. The computer readable medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

Although the invention has been described in detail above for ease of understanding, it will be understood that certain modifications may be made to the methods described above within the scope of the appended claims. As mentioned above, although in some instances the application is discussed with reference to the example of a printer application, the application can be any type of application that can be processed by one or more processing entities. The examples of the invention are therefore intended to be illustrative and not limiting, and the invention should not be limited to the details given herein, which may be modified within the scope and equivalents of the appended claims. to modify.

Claims (26)

1. A computer-implemented method for identifying modules of an executable program, the method comprising: start the executable program; During the execution of the executable program, monitoring the executable program, the monitoring also includes: Identify the interrelated classes of each module, each module corresponding to a specific function of the executable program; A data structure is generated for each module during execution of the executable program that defines each class of specific functionality. 2. The method as recited in claim 1, wherein one of the modules is a core module. 3. The method recited in claim 1, wherein the step of monitoring executable programs further comprises: record related classes in a collection; and Store this data structure. 4. The method as recited in claim 3, wherein the data structure is stored on a networked resource server. 5. The method recited in claim 1, wherein the step of monitoring executable programs further comprises: Combine classes that are common to two or more modules in a single module. 6. A method of generating a class diagram showing how a module of an executable program uses classes of the executable program, the method comprising: monitor the executable program during execution of the executable program; Identify each class associated with a core module that is used to run the program's engine; perform each task associated with the program while the program is being monitored; Record each class used in each task execution; Define a class diagram for the core module and each task, where each class diagram defines the interaction of the classes in the core module and each task. 7. The method recited in claim 6, wherein performing each task further comprises: Each class associated with each task is requested. 8. The method as recited in claim 7, wherein the requested class is loaded from a file system. 9. The method as recited in claim 6, wherein the executable program is a printing application. 10. A method for subdividing an executable program into autonomous class modules, wherein each module corresponds to a task, the method comprising: carry out the procedure; monitor the implementation of the procedure; keep a record of the classes used during the execution of each task; Define a class diagram for each module that represents the interaction of the classes associated with each module. 11. The method recited in claim 10, wherein keeping a record of a class further comprises: Load the class through a class loader; Record loaded classes; Return this class to a Java virtual machine. 12. The method as recited in claim 11, further comprising: Detects an endpoint indicating that all classes for each module have been loaded. 13. The method as recited in claim 10, wherein one of the modules is a core module of an engine running the executable program. 14. The method as recited in claim 10, wherein the record of the class for each task is saved as a zip file. 15. The method as recited in claim 10, wherein each module is associated with a zip file. 16. The method as recited in claim 13, wherein the step of keeping a record of the classes used during execution of each task further comprises: Identify classes that are common to multiple modules; and Place identified classes that are common to multiple modules in the core module. 17. A method of developing a software product for an application having a plurality of specific functions, wherein each specific function is associated with at least one class, the method comprising: Identify each class of the application; perform each specific function of the App; Identify each class associated with each specific functionality; A module is defined for each specific function, and each module contains a group of identified classes related to a specific function, and each module can complete the corresponding function of the module. 18. The method as recited in claim 17, wherein a module is a core module containing the main class with the entry point of the application. 19. The method recited in claim 17, wherein the step of defining a module for each specific function further comprises: Store each class of this module in a collection. 20. The method as recited in claim 19, wherein the module is stored as a zip file on a networked resource server, and the zip file is downloaded over a network upon request from a Java virtual machine. 21. The method as recited in claim 20, wherein the downloading over the network is initiated by a request from the user, a predictive download and a sequential background download. 22. A method for generating a module of an application that is capable of autonomously executing a specific function of the application, the method comprising: launch the application; request a class loader to load a class; The class loader is monitored as each class of the module is loaded; document each class of the module; Checks for an endpoint indicating that all classes for this module have been downloaded. Repeat the Request, Monitor, Log and Detect steps for the remaining modules of the application. 23. The method as recited in claim 22, wherein a Java virtual machine requests the class loader. 24. The method as recited in claim 22, wherein each class of the module is recorded in one of a set and a vector. 25. The method as recited in claim 22, further comprising: Return the recorded class to a Java virtual machine. 26. The method as recited in claim 22, wherein the application provides a printer function.

Images