fig4 and 5 depict the relationship of the hardware platform , operating system , embedded desktop , jvm and java applications in accordance with the present invention . as will be explained below , through the introduction of the embedded desktop , only one instance of a jvm is required to be run , regardless of the number of java applications which have been launched . further , the java applications which are running are able to easily communicate in a system independent manner . the embedded desktop can be implemented on any information appliance which is configured as described in fig4 . such information appliances include , but are not limited to , workstations , cellular phones , and personal digital assistants such as 3com &# 39 ; s palm pilot or apple &# 39 ; s newton . as will be appreciated by those skilled in the art , the expression “ hardware platform ” used in the drawings is a generic term used to describe the main physical components of an information appliance . in general , such information appliances comprise a bus for communicating instructions , a processor coupled to the bus for processing the instructions , random access memory coupled with the bus for storing volatile information and instructions for the processor , read only memory coupled to the bus for storing static information and instructions for the processor , a display device ( shown as 20 in fig6 ) coupled with the bus for displaying information to a user , an alphanumeric input device coupled with the bus for communicating information and command selections to the processor , and a mass storage device ( shown as 22 in fig6 ) for storing information and instructions . the processor may be any of a wide variety of general purpose processors or microprocessors such as the sparc manufactured by sun microsystems or the pentium manufactured by intel corporation . the display device may be a liquid crystal display , cathode ray tube or the like , while the mass storage device includes , but is not limited to , a hard disk , floppy disk , optical storage device or the like . the preferred embodiment of the present invention is implemented as a software module , which may be executed in a conventional manner on an information appliance as described above . the embedded desktop is stored in read only memory and subsequently loaded into and executed by the processor integral to the information appliance . once initiated , the software of the preferred embodiment operates in the manner which will be described below . fig6 is a diagrammatic overview of the embedded desktop in accordance with the present invention . an embedded desktop serves to manage all aspects of the operating environment and incorporates such user aids as an application launcher , input device manager and a remote application deployment manager ( radm ). an application launcher manages applications and provides users with a method to access applications and document shortcuts . an input device manager allows users to select the input device of their choice . finally , the radm allows users to download or receive subscription software and install it as well as providing device manufacturers and content developers the ability to upgrade their device software transparently and remotely . in general , the embedded desktop comprises a kernel or core 10 with hooks to a variety of plug - ins . one such example of a plug - in is the “ look - and - feel ” or user interface ( ui ) plug - in 12 which allows the user to integrate their own gui or adopt the standard gui provided with the embedded desktop . fig7 depicts a standard gui 14 and a customized gui 16 available through an embedded desktop . it is important to note that the embedded desktop has a relatively small footprint of approximately 50 kilobytes and is generally stored in the rom of the information appliance in which it is installed , although other storage medium would also be satisfactory . despite the small footprint , the embedded desktop provides the full functionality normally associated with much larger ( 10mbyte ) desktop managers . the present invention focuses on the relationship of the core 10 and two plug - ins , the user interface ( ui ) plug - in 12 previously discussed and the service vendor ( sv ) plug - in 18 . the ui plug - in 12 is typically configured to communicate with a display device 20 while the sv plug - in is typically configured to communicate with a local mass storage device 22 or remote network server or device 23 which stores applications to be loaded . as shown in fig8 one critical function of the core 10 is to manage all applications as specified by the service vendor plug - in 18 . as indicated above , applications may be launched from a local hard drive or from a remote server situated within a network . applications could be written by the same vendor but typically a user runs applications which have been programmed by a variety of different commercial software providers . there exists the possibility that the programmer could inadvertently use a class name which has been used by another programmer producing another application which the user desires to run on their information appliance . under the java specification , there is no guarantee of distinctive naming between applications . in the event of a class name overlap , if these applications are run on only a single jvm , a namespace collision will occur which could ultimately crash the applications . in order to avoid such collisions the present invention takes advantage of the concept of a class loader , well known in the java specification . when an application is launched , the core invokes an application class loader 24 for that first application by retrieving the class files 25 associated with that application . similarly , if a second application is launched , a second application class loader 26 is invoked . this procedure is repeated for each application that is launched . a separate system class loader 28 is also invoked by the jvm to load the embedded desktop itself . as each application class loader is invoked , an open application list 29 is maintained in the core . fig9 describes the sequence of steps which are performed on startup of an application . at step 30 the user selects an application icon presented on a display screen . at step 32 , the core launches the application selected and gives back the user interface for the application . at step 34 , the core retrieves application class files from the application . as shown at step 36 , this requires that the service vendor locate and extract the class files from either a local storage device or a remote server in a network where the application is resident . at step 38 , the class files are delivered by the service vendor to the core . at step 40 the core constructs the application class loader using the application class files and hooks the class loader to the system class loader which was invoked when the embedded desktop was launched . at step 42 the core instantiates the application so that it &# 39 ; s ready to run and updates a list of loaded applications . finally , at step 44 , the user interface for the application is presented to the user . in the preferred embodiment there is also invoked a services class loader , to facilitate access to service classes defined by the various applications . in the same manner that the user applications invoke an application class loader , a services class loader is invoked when a service application is launched . fig1 defines the hierarchical nature of the class loaders . operationally , if an application class loader needs to communicate with the system class loader , it would have to communicate first with the service class loader . it will be understood by those skilled in the art that separate application class loaders need not be invoked where there is some level of assurance that there will not be any namespace collisions . this could arise , for example , if a user has adopted software written by the same vendor who has ensured that classes associated with each application are named differently . alternately , if the software vendors adhere to a naming guideline to avoid similar class names , then separate application class loaders need not be invoked . the ability to eliminate the use of application class loaders may be important where memory is limited in the information appliance into which the embedded desktop is loaded . it will also be understood by those skilled in the art that a user interface plug - in 12 and display device 20 , as described in relation to fig6 need not be included for the present invention to operate effectively . for example , where java applications are automatically invoked on startup and do not require interaction with a user , the user interface plug - in 12 and associated display device 20 can be eliminated , with the embedded desktop maintaining full functionality including class name collision avoidance . once the class loader structure is established , communication between applications is able to be managed at the desktop level through the core . fig1 is a message flow diagram demonstrating , for a specified example , how communication between open java applications occurs at the embedded desktop level . first we assume that three java applications are running — e - mail , address book , and web browser . if the e - mail application requires an address , at step 46 it polls the core . at step 48 , the core retrieves the open application list and sequentially polls ( at steps 50 , 52 and 54 ) each open application to determine if one or more of them are “ address book ”. at step 56 , the list of applications which have responded positively to the core &# 39 ; s poll is given to the e - mail application for processing . ( a ) multiple applications can now be run under one instance of a jvm ; ( b ) there is a separation of namespaces so that the application class names do not collide ; ( c ) sandboxing ( compartmentalizing ) is introduced so that applications cannot adversely affect each other ; a person skilled in the art may now conceive of alternate structures and embodiments or variations of the above . all those which fall within the scope of the claims appended hereto are considered to be part of the present invention .