Using JavaReg

Previous

About Tools

Index

Next

Using JavaReg

Many of JavaReg's options are intended for use only with Distributed COM (DCOM), available with Microsoft® Windows NT® version 4.0. For more information about DCOM, see the Win32 Software Development Kit.

Remoting with DCOM

The Java Support in Internet Explorer runs as an in-process server, and in-process servers cannot normally be remoted using the Windows NT 4.0 Distributed COM (DCOM). However, it is possible to launch a "surrogate" .exe in its own process that then loads the in-process server. This surrogate can then be remoted using DCOM, in effect allowing the in-process server to be remoted. You can use JavaReg's /surrogate option to support remote access to a COM class implemented in Java. When first registering the class, specify the /surrogate option on the command line. For example:

javareg /register /class:MyPerformer /clsid:{42E5AFC6-DBAA-11cf-BAFD-00AA0057B223} /surrogate 

This adds a LocalServer32 key to the registry in addition to the usual InprocServer32 key. The command line under the LocalServer32 key specifies JavaReg with the /surrogate, but without the /register option.

<HKEY_CLASSES_ROOT
	CLSID
		{42E5AFC6-DBAA-11cf-BAFD-00AA0057B223}
			InprocServer32 = msjava.dll
			LocalServer32 = javareg /clsid:{42E5AFC6-DBAA-11cf-BAFD-00AA0057B223} /surrogate

This causes JavaReg to act as the surrogate itself. When a remote client requests services from the COM class that you've implemented using Java, JavaReg is invoked. JavaReg then loads the Java Support in Internet Explorer with the specified Java class. (This means that when distributing your Java program, your installation program, must install JavaReg along with the Java class.)

You can remove the LocalServer32 key by rerunning JavaReg with the /class option, specifying the same class name, but without the /clsid or /surrogate options.

Using JavaReg to Generate a CLSID

If you aren't defining new interfaces but are simply writing a Java class that implements existing interfaces, you may not need to write an .odl file. First, run JavaTLB on the type library that describes the COM interfaces you want to implement. This generates .class files for those interfaces. Then, write a Java class that implements those COM interfaces. Finally, run JavaReg with the /register and /class options, but without the /clsid option. This instructs JavaReg to generate a new CLSID and register the class using that value. You must record the CLSID that JavaReg generates, since this is the value you must publish when distributing your class. As long that the interfaces your class implements are properly registered, COM clients can specify your class's CLSID and use its interfaces as usual.

Other JavaReg Options

JavaReg also accepts other command-line options:

/unregister	Use this option to remove the registry entries for a particular class. You must include the /class option to specify the name of the class.
/progid	Use this option if you want to specify a ProgID for your class.
/defappid	This option is only meaningful if you are using the /surrogate option. By default, JavaReg uses the CLSID as the AppID. By specifying this option, JavaReg will use its own CLSID as the AppID. For more information on the AppID, see the Win32 Software Development Kit.
/single	This option is only meaningful if you are using the /surrogate option. This option causes a single instance of your class to be shared among multiple clients. Use this option if your object has no instance data, or if you want its instance data to be shared by all clients.
/console	This option is only meaningful if you are using the /surrogate option. This option creates a console window that displays the System.out output from your Java applet. This is useful for debugging purposes.