We should try to remove support for the XPCOM plugin API in Mozilla 2. Simply put, it is a confusing mess. Only Java uses it now and we're trying to get Java moved off of it. The Java plugin included with Java SE 6 Update N for Windows, Linux, and Solaris does not depend on the XPCOM plugin API. Still need to figure out the Mac OS X situation.

Sun is ready to help in whatever way we can to help Mozilla remove this legacy code. Note that the new NPAPI and NPRuntime-based Java Plug-In still uses the XPCOM for a few operations: asking the browser for the proxy for a given URL (nsIPluginManager2), getting and setting cookies (nsICookieStorage), and asking the browser for the authentication information for a given location (nsIJVMAuthTools). We would need to promote these operations to a new version of the NPAPI in order for us to completely remove our XPCOM dependencies. We might also want to be able to query the browser for its display connection on X11 platforms to be able to implement the same sort of nested message loop we do during JavaScript-to-Java calls on Windows -- if the NPNVxDisplay NPN_GetValue query is fully supported (we haven't tested it) then that is covered.

Kenneth, could you tell us how the Java plugin gets to the interfaces you listed above, using the service manager? IOW, what classid's or uuids do you depend on to get to what you need through the service manager?

Ken is very busy lately so I'll take a shot at answering your question. According to latest trunk on lxr.mozilla.org, the uuid for these interfaces are: - For nsIPluginManager2: [uuid(d2962dc0-4eb6-11d2-8164-006008119d7a)] - For nsICookieStorage: [uuid(c8c05100-cfdb-11d2-bab8-b088e084e5bc)] - For nsIJVMAuthTools: [uuid(d8e716f9-c96e-4e84-ab12-980f5567e2a4)] Of these, the uuid for nsIJVMAuthTools is referenced statically in new plugin code. But for the other 2 services, we do not specify the nsIID statically when querying for the service through the manager. Rather we reference them using NS_GET_IID() for nsIPluginManager2 and nsICookieStorage, respectively.

Just for completeness, these are the routines we are calling against these interfaces and for which we would need NPAPI analogues: nsIJVMAuthTools::GetAuthenticationInfo(const char *protocol, const char *host, PRInt32 port, const char *scheme, const char *realm, nsIAuthenticationInfo **_retval); nsIAuthenticationInfo::GetUsername(const char * *aUsername); nsIAuthenticationInfo::GetPassword(const char * *aPassword); nsICookieStorage::GetCookie(const char *aCookieURL, void * aCookieBuffer, PRUint32 & aCookieSize); nsICookieStorage::SetCookie(const char *aCookieURL, const void * aCookieBuffer, PRUint32 aCookieSize); nsIPluginManager2::FindProxyForURL(const char *aURL, char **aResult);

Danielle and Kenneth, thanks for the info. Can you also tell me how you get to the implementations of those interfaces? I'm assuming you call NPN_GetValue(), passing in NPNVserviceManager. Once you have that, what functions do you call, and with what string/uuid arguments? I need that information to make sure the objects you depend on live past us removing the OJI code as I know some of the classes you use live in that code (but they're trivial classes and easy to maintain outside of OJI until we no longer need them).

Attached is an excerpt of the code from the new Java Plug-In which queries and interacts with these interfaces. Let us know whether this answers your questions.

Kenneth, thank you, that shows me what I need to know!

With the addition of the NPN_GetValueForURL, NPN_SetValueForURL and NPN_GetAuthenticationInfo entry points in major version 21 of npapi.h (NPVERS_HAS_URL_AND_AUTH_INFO), the new Java Plug-In no longer has any XPCOM dependencies. Thanks for the addition of these APIs. The first release of the new Java Plug-In that fully supports running without XPCOM is Java SE 6 Update 14, early access builds of which can be downloaded from http://jdk6.dev.java.net/ .

This will be fixed by bug 488042, I should have used this bug instead but the patch and other info is there now.