96910 - Changes in the NS_NewGenericModule() method signature break the Java Plugin

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P1)

Description

[Ashu Kulkarni]

The Java Plugin uses the NS_IMPL_NSGETMODULE macro in
xpcom/components/nsIGenericFactory.h. Changes made to the NS_NewGenericModule
method which this macro calls have caused the Java Plugin to break. These
changes were made while fixing 71248 and 93100. Since there is no backward
compatibility, the Java Plugin designed to work with the Mozilla trunk will not
work with any version of Mozilla before 08/06/01.

A backward compatible function NS_NewGenericModule with the old signature needs
to be provided and the new method should be named something like
NS_NewGenericModule2 to fix this problem.

Comment 1

[Brendan Eich [:brendan]]

Or not.  We never promised frozen APIs here.  When is the next JVM, based on the
revised extern function, due out?

/be

Comment 2

[Ashu Kulkarni]

JDK 1.4 is the next version and it's approaching beta. Anyways, if lack of 
backward compatibility in the extern func means that the JVM will run with 
either 6.1 or 6.2 (and beyond), but not both; that would be undesirable. What 
would be the reason to not provide backward compatibility?

_Ashu

Comment 3

[Chris Waterson]

Yeah, but this is trivial to fix, and incurs minimal overhead. Plus, I'm sure
that eclient and ``the embedding customer'' would be disappointed to see Java
not work. I'll whip up a patch.

Comment 4

[Chris Waterson]

Attachment: revert NS_NewGenericModule() to its old signature; add NS_NewGenericModule2()

Comment 5

[Chris Waterson]

I reverted NS_NewGenericModule() to its old signature, and added a new entry
point NS_NewGenericModule2() with the updated signature. I think this is
probably the best way to maintain compatibility with older versions of
Mozilla-based products, and makes it easier on vendors.

dougt, what do you think?

Comment 6

[Doug Turner (:dougt)]

Sad thing to do, but needed.  Just like InitXPCOM2().  r/sr=me

Comment 7

[John Bandhauer]

sr=jband

Comment 8

[Asa Dotzler [:asa]]

a=asa on behalf of drivers.

Comment 9

[Chris Waterson]

Attachment: needed to fix xpfe/bootstrap and modules/staticmod, as well

Comment 10

[Chris Waterson]

Fix checked in on the branch and the trunk, thanks attinasi for wiping my chin.

Comment 11

[edburns]

*** Bug 97285 has been marked as a duplicate of this bug. ***

Comment 12

[Knut J]

LoadPlugin: failed to initialize shared library
/usr/java/j2sdk1.4.0/jre/plugin/i386/ns600/libjavaplugin_oji140.so
[/usr/java/j2sdk1.4.0/jre/plugin/i386/ns600/libjavaplugin_oji140.so: undefined
symbol:
GetService__16nsServiceManagerRC4nsIDRC4nsIDPP11nsISupportsP19nsIShutdownListener]

I am using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010901,
which is from 1 sep 2001. There are still some isuess with java 1.4.0 beta2.

Comment 13

[Mike Shaver (:shaver emeritus)]

Can eClient and "the embedding customer" not use waterfall or some other
open-source, shorter-than-18-mos-turnaround Java plugin, rather than relying on
the fragile Sun one?

(Now that the new Sun plugin is going to write to NS_NewGenericModule2, is
_that_ frozen and perma-supported as well?  Where do we draw the line, if not at
the public API stuff?  We sent ea.com back to the drawing board because of a
bogus dependency on _just_this_function_ a few months back, and everyone was on
board with that.)

And now it looks like they're calling nsServiceManager::GetService as well --
what fun!

Comment 14

[Mike Shaver (:shaver emeritus)]

Forgot to add before:

This _isn't_ like NS_InitXPCOM2 (whose value we can debate some other time): you
_need_ to call NS_InitXPCOM(2) in order to use XPCOM, but there is no need to
call NS_NewGenericModule.  You can _choose_ to use that function _if_ you're
willing to live with the fact that it's not a frozen API, and you don't mind the
libxpcom linkage.  People writing binary plugins will probably not be happy with
either of those conditions, and should therefore not use the utility
function.Also, I didn't think that there had been a Java plugin released that
used the NSGetModule stuff, which is why everyone was up in arms about the
removal of NSGetFactory support.  Is there now an nsIModule-using Java plugin
floating around, so we can remove the cruft from the component manager for
NSGetFactory?  Or are we trying to maintain backward compatibility for the sake
of an _unreleased_ binary-only plugin?

Comment 15

[Knut J]

I think java 1.4 beta use nsServiceManager::GetService. Is there any way to get
it back in.

Comment 16

[Mike Shaver (:shaver emeritus)]

Seems like something (along with their use of NS_NewGenericModule) that they
should fix for final, based on beta feedback, rather than having us litter our
tree with variant methods.  I'm not really compelled to do much to support a
beta plugin in that way.

Comment 17

[Ryan Pertusio]

*** Bug 97781 has been marked as a duplicate of this bug. ***

Comment 18

[Suresh Duddi (gone)]

For what it is worth, pretty soon we will merge service and component managers.
That way modules can get the servicemanager from a QI(componentmanager) that
gets passed into them at module init.

Comment 19

[Jon Granrose]

what's the confidence level that we are keeping this fix in the tree?  We
updated a Netscape plugin because of this same problem and are now going to have
to revert it (bugscape 8738) since the original change got backed out.  I don't
want to revert our plugin only to have this change get reverted and have to
update our plugin again.

Comment 20

[Doug Turner (:dougt)]

the xpcom api's are not frozen yet and *are subject to change*.  Hopefully in
the next few months, we will publicly freeze them.  After this point, there will
be no change and backwards compatiblity will be a high priority.  

Comment 21

[Steven Katz]

Mr. Shaver,

Please send us a pointer to the documentation that describes the appropriate way
to write a plugin for Mozilla.  The sections on what interfaces should and
should not be use would be especially helpfull, as would the sections on
component/plugin discovery and life cycle.

Also, an example more up to date then npsimple (which uses
nsServiceManager::GetService and NS_NewGenericModule, BTW) would be good since
this is the model we used.  Perhaps npsimple should be removed from the tree, so
as not to mislead others in the future.

Finally, we have posted several questions to the mozilla xpcom newsgroup.  If
you could take the time to respond to these, I'm sure others would benifit as
well.

Please feel free to contact me directly so that we [Sun's Plugin team] may
address your concerns.

Comment 22

[edburns]

What I'm seeing with today's trunk is: _vt.17nsGetServiceByCID is undefined. 
The JDK1.3.1 plugin somehow depends on this.

Comment 23

[edburns]

Never mind.  This is not a problem.

Comment 24

[Mike Shaver (:shaver emeritus)]

Granrose: the confidence level is low.  Don't use NS_NewGenericModule if you
don't want to sign up to stay in sync with the xpcom tip (yo); prefer instead to
implement nsIModule yourself.

Comment 25

[Knut J]

Would you like to point at where  
GetService__16nsServiceManagerRC4nsIDRC4nsIDPP11nsISupportsP19nsIShutdownListener
is in xpcom/modules. I would like to insert to get java 1.40 to work.

Comment 26

[edburns]

Please note that in order to get Java 1.4.0 to work on Unix, you must register 
the plugin using regxpcom:

cd to mozilla bin

./regxpcom <absolute_path_to_>/libjavaplugin_oji140.so

Comment 27

[Knut J]

That is strange I get segment fault when using regxpcom. I use SRPMS to compile
mozilla and java is registred by my custom built rpm.