Abstract:
A method and apparatus for determining the names of Java Beans and for categorizing Java Bean sub-elements files. A two stage process is utilized for Java files having one or more .class files and .ser (serialized) files. The first stage attempts to determine the name of a Java Bean based upon the file names forming the Bean based upon suffixes and strings within the file names. The second stage is then applied to determine the category of the Bean sub-elements using the names of the Java Bean derived in the first stage. The first stage names are again examined based upon unique suffixes and word strings and the proper category determined for each file name.

Description:
FIELD OF THE INVENTION 
     The present invention relates to data processing systems, and more particularly, to determining the contents of a Java Repository containing Java Beans. 
     BACKGROUND OF THE INVENTION 
     Over the past few years, constructing applications by assembling reusable software components has emerged as a highly productive and widely accepted way to develop custom applications. First generation products such as Microsoft&#39;s Visual Basic and Borland&#39;s Delphi, have been followed by a wave of new products which have enhanced the basic component assembly application development model by adding more powerful data access components, and object-oriented component extension capabilities. Java, manufactured by the Sun Microsystems, Inc., has quickly established itself as the industry-standard platform for building fully portable Internet and corporate Internet applets and applications. The Java platform provides a number of advantages to developers which include a fully portable platform, a powerful and compact environment, and a network aware platform. Java&#39;s language, libraries and virtual machines occupy an ever increasing presence in browsers which allows developers to write application functionality once, and deploy the application broadly on a wide variety of operating systems and hardware platforms. The Java platform provides developers with the full power of an object-oriented language while eliminating the complexity, housekeeping and heavier weight object creation and registration processes required by other language and programming model environments. Java&#39;s lightweight runtime is easily incorporated into chips for embedded systems, such as PDAs as well as client and server class Personal Computers (Pcs) and workstations. Security mechanisms are provided which allow full protection against applet interference with client-side data. The platform allows applets to be built from self-describing classes, which are easily downloaded to the client environment without the need for heavy weight installation or registration processes. The recent release of Sun Microsystems Inc.&#39;s Java Beans takes the component software assembly paradigm to a new level. 
     Java Beans is an architecture and platform neutral Application Programming Interface (API) for creating and using dynamic Java components. Java Beans builds on the strengths of the component assembly development model. It allows developers to define independent components that can be used and re-used in a variety of combinations to compose new applications inside a variety of browser and non-browser environments. Java Beans components can be Graphical User Interface (GUI) widgets, non-visual functions and services, applets and more full-scale applications. Each of these components can be built by different developers at separate times. The components do not need to be part of the same application build but are capable of communicating dynamically. 
     The Java Beans API is designed for scaling up from simpler, lighter weight, widgets and applets toward more full function applications. This is in stark contrast to existing component model APIs which scale down from complex heavyweight application size components to include lighter-weight widget size components. Consequently, the Java Beans API will not overburden the smaller widget and applet size components with complexity and weight. Java Beans are frequently transmitted in Java Archive (JAR) file format which is a platform-independent file format that aggregates many files into one. Multiple Java applets and their requisite components (.class files, images, sounds and other data) are bundled in a JAR file and subsequently downloaded to a browser in a single HyperText Transfer Protocol (HTTP) transaction, which greatly improves the download speed. The JAR format also supports compression, which reduces the file size, further improving the download time. 
     In development environments, JAR files are frequently received containing a plurality of Java Beans with minimal or no information about the Java Beans within the JAR file. The technique for determining the contents of these JAR file requires an introspection step followed by instantiation of each Java Bean. Introspection is the process that Java uses to discover the properties, methods and events of a component. The introspection step is followed by creating an instance of each Java Bean. These steps require significant execution time and thus reduce the efficiency of programmers. 
     Consequently, it would be desirable to provide a method and apparatus for determining the contents of a Java Archive file without requiring introspection and instantiation of the Java Beans stored therein. 
     SUMMARY OF THE INVENTION 
     This invention relates to a method and apparatus for determining the names of Java Beans and for categorizing Java Bean sub-element files. A two stage process is disclosed for Java files having one or more class files and ser (serialized) files. The first stage attempts to determine the name of a Java Bean based upon the file names forming the Bean. Each file name is first analyzed to determine if it ends with a .ser, .class, .java, .gif, or .jpg suffix. If a particular suffix is found, the file name undergoes an additional examination for a string equaled to “Exception”, “Customizer”, “Bean”, “BeanInfo” or “Icon”. The first stage produces a determination of each of the Java file names. The second stage is then applied to determine the category of the Bean sub-elements using the name of the Java Bean derived in the first stage. The first stage names are again examined for the .class, .ser, .java, .gif, or .jpg suffixes. After determining the proper suffix, the names are again searched for the strings “Exception”, “Customizer”, “Bean”, “BeanInfo”, etc. to determine the category for the sub-element file. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 illustrates Java Beans stored in a Java Beans Archive (JAR) file; 
     FIGS. 2-7 are flow diagrams of the procedure used to determine the names and categorize plurality of Java Beans as disclosed by this invention; 
     FIG. 8 illustrates a computer/workstation where this invention may be practiced; 
     FIG. 9 is an illustrative embodiment of a computer network where the present invention may be practiced. 
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
     This invention provides a method and apparatus for a determining the name of a Java Bean and for categorizing Java Bean sub-element files. The invention provides developers with a quick, efficient mechanism for determining the contents of a Java Archive (JAR) file containing a plurality of Java Beans, but which contains minimal or no information about the Java Beans contained within the JAR file. A Java Bean consists of one or more .class files (e.g., compiled Java code) and perhaps a serialized (.ser) Java class file. One of these files contains the “main” method which is invoked to execute the Bean. Zero or more of these files contains graphics format files that contains icons representing the Bean. An optional file may contain the BeanInfo class for the Bean. In addition, there are other specialized types of files that provide a Customizer class, or source code. It is very difficult to determine which file belongs to which category when the information is not explicitly stated for a JAR repository containing a plurality of Java Beans. 
     Referring to FIG. 1, there is shown a sample plain Manifest file  10  for a prior art Java Archive (JAR) file. The Manifest file  12  contains three Java Beans which have been designated MyBean  14 , YourBean  15  and OurBean  16 . The OurBean  16  Java Bean utilizes ColaDrinks.data  18  and the YourBean  15  Java Bean has as a sub-element YBCustomizer.class  13 . In general, sub-elements containing the name of the Java Bean or located under a Java Bean are utilized by that Bean. One skilled in the art will appreciate that a JAR file/repository may contains a plurality of Java Beans forming an applet or application program. 
     This invention uses a two step procedure for determining the names of Java Beans in a repository and categorizing the Java Bean sub-elements files. The first step attempts to guess the name of the Java Bean in a repository. The second step utilizes the name obtained in the first step to categorize the Java Bean sub-element files. The procedure places each file into one of the following Java categories: 
     OtherFile 
     OtherClass 
     ExceptionClass 
     BeanCustomizerClass 
     BeanClass 
     BeanInfoClass 
     OtherSer 
     BeanSer 
     OtherSrc 
     ExceptionSrc 
     BeanCustomizerSrc 
     BeanSrc 
     Image 
     BeanIcon 
     Referring to FIG. 2, there is shown a flow diagram for the “Main” procedure for determining the names and categorizing a Java Bean. The “Main” procedure starts at block  30  and proceeds immediately to block  32  where the procedure Guessname, used to guess the name of the Bean is called. The bean Name is set equal to the name returned from Guessname and the list of filenames is set equal to SV. At block  34  the procedure sets the next file name from SV equal to the Filename. The CategorizeFile procedure is called at block  36  and associates the Filetype returned from CategorizeFile with Filename. At block  38 , the procedure checks if SV is empty. If YES, processing ends at block  40 . Else, processing returns to block  34 . 
     Referring to FIG. 3, details of the GuessName procedure described in block  32  of FIG. 2 will now be described. The procedure begins at block  50  and proceeds to block  52  where the list of file names is set equal to SV. In addition, both best guess and Secondbestguess are set equal to null. At block  54 , Filename is set equal to the next file name from SV. A check is conducted at block  56  to determine if Filename ends with “.ser”. If YES, bestguess is set equal to all characters in Filename preceding “.ser” at block  68  and bestguess is returned at block  70 . If NO at block  56 , a check is conducted to determine if Filename ends with “.class” or “java” at block  58 . If YES, a determination is made at block  60  whether Filename contains the string “exception”. If YES, at block  72  bestguess is set equal to all characters in Filename preceding “Exception”. If NO at block  60 , the procedure checks at block  62  to determine if Filename contains “Customizer”. If “Customizer” is found within Filename, processing continues to block  74  where bestguess is set equal to all characters in Filename preceding “Customizer”. If the string “Customizer” is not found at block  62 , processing proceeds to block  64  where the Filename is checked for “Bean”. If found, processing proceeds to block  76  where bestguess is set equal to all characters in Filename preceding “Bean”. If Filename does not contain a “Bean” string at block  64 , processing continues at block  66  where a check is done to determine if Filename contains the string “BeanInfo”. If YES, at block  78  bestguess is set equal to all characters preceding “BeanInfo”. If NO at block  66 , processing continues at block  96  (FIG.  4 ). Returning to block  58 , if Filename does not end with “.class” or “.java”, a check is conducted at block  92  (FIG. 4) to determine if Filename ends with “.gif” or “.jpg”. If YES, a determination is made at block  100  to determine if Filename contains “Icon”. If YES, at block  106  second bestguess is set equal to all characters in Filename preceding “Icon”. Else, processing continues at block  96  to determine if the list SV is empty. If SV is not empty at block  96 , processing returns to block  54  (FIG. 3) to process the next Filename. Returning to block  96 , if SV is empty, a determination is made at block  102  whether bestguess equals null. If YES, the procedure returns secondbestguess at block  108 . Else, at block  104  the procedure returns bestguess. 
     Referring to FIG. 5, the procedure CategorizeFile shown in the “Main” procedure at block  36  (FIG. 2) will be described. The procedure begins at block  110  and proceeds immediately to block  112  where bean Name is set equal to the guessed Bean Name. Filename is set equal to the name of the file to be categorized and Filetype is set equal to OtherFile. At block  114  a determination is made whether Filename ends with “.class”. If YES, filetype is set equal to OtherClass at block  118 . At block  119 , a check is made whether Filename contains the string “exception”. If Yes, Filetype is set equal to ExceptionClass at block  130 . Else, at block  120  a check is conducted to determine if Filename contains the string “Customizer”. If YES, the Filetype is set equal to CustomizerClass as shown at block  132 . Else, at block  122  the Filename is checked for the string “Bean”. If YES, at block  134  Filetype is set equal to BeanClass. Else, at block  124  File name is checked for the name “BeanInfo”. If found, at block  136  Filetype is set equal to BeanInfoClass. Else, at block  126  a test is conducted for the string “BeanName”. If YES, Filetype is set equal to BeanClass as shown in block  140 . If NO, at block  128  the procedure returns Filetype. Returning to block  114 , if Filename does not end with “.class”, processing continues at block  144  (FIG.  6 ). 
     Referring now to FIG. 6, the procedure checks Filename for “.ser” at block  144 . If found, at block  150  File type is set equal to OtherSer. At block  152  a determination is made whether Filename equals Bean Name. If YES, at block  156  Filetype is set equal to BearSer. Else, at block  154  the procedure returns Filetype. Returning to block  144 , if File name does not end with “.ser”, the File name is checked at block  146  for .gif or .jpg. If either is found, Filetype is set equal to Image at block  158 , and processing proceeds to block  160  where a check is conducted to determine if Filename contains “Icon”. If YES, Filetype is set equal to BeanIcon as shown at block  164 . If NO, at block  162  the procedure returns Filetype. Returning to block  146 , if “.gif” or “.jpg” are not found, processing continues at block  172  (FIG. 7) 
     Referring to FIG. 7, at block  172  a determination is made whether Filename ends with “.java”. If NO, the procedure returns Filetype at block  176 . Else, at block  178  Filetype is set equal to OtherSrc. A check is conducted at block  180  to determine whether Filename contains the string “exception”. If YES, at block  192  Filetype is set equal to ExceptionSrc. If NO at block  180 , the procedure checks at block  182  to determine if Filename contains “Customizer”. If “Customizer” is found within the Filename, processing continues to block  194  where Filetype is set equal CustomizerSrc. If the string “Customizer” is not found at block  182 , processing proceeds to block  184  where Filename is checked for “Bean”. If found, processing proceeds to block  196  where Filetype is set equal to BeanSrc. If Filename does not contain a “Bean” string at block  184 , processing continues at block  186  where a check is done to determine if Filename contains the string “BeanInfo”. If YES, at block  198  Filetype is set equal to BeanInfoSrc. If NO at block  186 , processing continues at block  188  to determine if Filename equals beanName. If YES, Filetype is set equal to BeanSrc at block  199 . Else, the procedure returns FileType at block  190 . 
     Referring now to FIG. 8, there is shown a pictorial representation of a workstation, having a central processing unit  202 , such as a conventional microprocessor, and a number of other units interconnected via a system bus  200 . The workstation shown in FIG. 8, includes a Random Access Memory (RAM)  206 , Read Only Memory (ROM)  204 , an I/O adapter  208  for connecting peripheral devices such as floppy disk unit  226  to the bus, a user interface adapter  212  for connecting a keyboard  214 , a mouse  218 , a speaker  220 , a microphone  216 , and/or other user interface devices such as a touch screen device (not shown) to the bus, a communication adapter  210 , for connecting the workstation to a data processing network and a display adapter  224 , for connecting the bus to a display device  224 . The workstation, in the preferred embodiment, has resident thereon the computer software making up this invention, which may be loaded from diskette  228 . 
     A representative network environment where this invention may be practiced is depicted in FIG. 9, which illustrates a pictorial representation of a distributed data processing system  240 . As illustrated, data processing system  240  contains a plurality of networks, including local area networks (LAN)  242  and  244 , each of which preferably includes a plurality of individual computers  246  and  248 , respectively as shown in FIG.  8 . One skilled in the art will appreciate that a plurality of workstations coupled to a host processor may be utilized for each such network. As is common in such data processing systems, each computer  246  and  248 , may be coupled to a storage device  250 , and a printer  252 . 
     Data processing system  240  further includes one or more mainframe computers, such as mainframe computer  256 , which may be preferably coupled to LAN  242  by means of a communication link  260 . Mainframe computer  256  is preferably coupled to a storage device  254 , which serves as remote storage for LAN  242 . LAN  242  is also coupled via communications link  260  through communications controller  262  and communications link  264  to gateway server  266 . Gateway server  266  is preferably a workstation which serves to link LAN  242  to LAN  244  via communications link  268 . As understood by one skilled in the art, data processing system  240  additionally includes unillustrated gateways, routers, bridges, and various other network hardware utilized to interconnect the segments of data processing system  240 . 
     While the invention has been described with respect to a preferred embodiment thereof, it will be understood by those skilled in the art that various changes in detail may be made therein without departing from the spirit, scope, and teaching of the invention. Accordingly, the herein disclosed invention is to be limited only as specified in the following claims.