239831 - Java plugin 1.3.1 fails to load with Mozilla 1.7b on AIX

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, defect)

Description

[Mary Hoetzel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
Build Identifier: Mozilla/5.0 (X11; U; AIX...  rv: 1.7

The Java plugin in Java 1.3.1 has in AIX a dependency on the xpcom symbol
__vft16nsQueryInterface15nsCOMPtr_helper.
This symbol does not exist in Mozilla 1.7 anymore because class nsQueryInterface
is no longer a nsCOMPtr_helper class (see bug 234725).
Without the symbol, the Java plugin does not load.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

this is all mine

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ok, so I tested around a bit why we havn't ran into this before, and why we're
not running into this on a wider scale.

It appears that the bug is actually not in the mozilla codebase. Apparently the
Javaplugin should statically link against the xpcom-glue library, which will
contain the implementation of that symbol. If that was done the binary should be
able to run on both 1.4 and 1.7 mozillas.

I've tested this with the sample application and it works fine.

So I suspect that if you change the way the javaplugin is built so that it
statically links against the gluecode it will work fine without any codechanges
needed.

Please let me know if this works, or if this is not an acceptable solution for
one reason or the other.

Comment 3

[Mary Hoetzel]

Why is it necessary to link libxpcomglue.a statically with the Java plugin?

Since Java is proprietary code it is not always acceptable to statically link
with open source libraries.   

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

bsmedberg, please see previous comment.

If you can't link statically for legal reasons then maybe one solution could be
to dynamically link to that library and ship with it. However if more people
started doing that i suspect that we'd get problems with different versions...

Of course a better solution would be to change the license of that library so
that it can be linked to. Like some of the libraries from gcc (iirc) does.

Comment 5

[Benjamin Smedberg]

I'm no lawyer, but as far as I know there are no legal issues for any code to
link against MPL code. The MPL is a source-level license, and is not viral.

Comment 6

[Philip K. Warren]

Jonas: Is there any possibility we could restore compatibility with the Java 
1.3.1 plugin without bringing in a lot of overhead? If we need to #ifdef AIX 
the relevant sections, I'm ok with that.

It seems like Bug 234725 promised no changes in binary compatibility (see 
comment 10), however this does look like exactly that. What other alternatives 
to changing the IBM build process for the Java plugin do we have?

Comment 7

[Darin Fisher]

Can the Java plugin be modified to not use do_QueryInterface?  Can it just use
QueryInterface directly?  Or is it the case that rev'ing the Java plugin at all
is not an option?

Comment 8

[Darin Fisher]

More to the point:

A plugin or any extension that wants forward binary compatibility must either
  1) link to the static glue library or
  2) not use the glue library.
The glue library is designed to make using xpcom easier, and it is also designed
to be statically linked into plugins and extensions.  If that is not an option,
then it should not be used.  Hence, my previous comment about using
QueryInterface directly.

Also, I'm sure that using do_QueryInterface pulls some inline code into the
plugin, and while I'm not a lawyer by an means, it seems like inline code is not
much different than statically linked code.  Both cases result in the plugin
carrying MPL code.

Comment 9

[Gervase Markham [:gerv]]

There are no legal issues with statically linking to MPLed code. The MPL is a
file-level copyleft; so it would not affect any of the files which make up the
source code of the Java plugin.

Of course, the organisation shipping the Java plugin would need to follow the
terms of the MPL with respect to the glue code.

Gerv

Comment 10

[Gervase Markham [:gerv]]

> There are no legal issues with statically linking to MPLed code.

I wrote that late at night; it's obviously a bit misleading. Rephrase: "There
are no legal issues of the sort you are concerned about with statically linking
to MPLed code."

GErv

Comment 11

[Jim Dunn]

Sorry for jumping into this so late, but Ralf was asking about this.
This might be totally irrelevant, but the OS/2 team added a "legacy"
file to xpcom/build that "sort of" contains this function and the
glueiness I think to make this work.  Is that a better solution?

Comment 12

[Philip K. Warren]

We have come up with a solution with the Java plugin team here at IBM which I
think should work ok. We have removed all dependencies on the XPCOM glue library
(with Darin's help), and we now have a plugin which does not require this symbol
and just uses XPCOM frozen functions directly.

The plugin has not been released yet, but it should be available soon. I will
update this bug with the details on downloading the updated version of the
plugin when it is available.

For now, users can use the Java 1.4.1 or 1.4.2 plugins for AIX, which do not
require this symbol from the XPCOM glue library, or they can continue to use the
Java 1.3.1 plugin with earlier versions of Mozilla.

Comment 13

[Jean-Marc Desperrier]

Darin, can you document in a public document for other implementors what kind of
change is typically needed to remove the dependance on the XPCOM glue library ?

Or just give a pointer if it's all already available publicly, I think it's all
a matter of switching from the easy do_CreateInstance way to the hard
QueryInterface method, but I'm still busy making sure what happens exactly in
the various doc. 

Comment 14

[Darin Fisher]

Yeah, I plan to write up such a document at some point.  Basically, you need to
not use nsCOMPtr, and that means that you need to not use do_QueryInterface,
do_CreateInstance, etc.  There are other things like the nsMemory:: methods that
you would also need to avoid.  There are alternatives for all of these things. 
A document would be good to show how to do it both ways (i.e., with and without
the xpcom glue).

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #14)
> Yeah, I plan to write up such a document at some point.  Basically, you need to
> not use nsCOMPtr, and that means that you need to not use do_QueryInterface,
> do_CreateInstance, etc.

what about CallQueryInterface, CallCreateInstance etc?

Comment 16

[Darin Fisher]

Those functions appear to be defined inline.  I suspect they are ok to use, but
in general you probably want to verify that your DLL only depends on frozen
symbols from xpcom.