gecko-dev/java/xpcom

Java Bridge to XPCOM
====================

This directory contains the beginnings of the Java Bridge to XPCOM.
For now it is disconnected from the main Mozilla build, because as yet 
it is good for no more than a few demo and test programs, and because
Java compilation on Unix and Linux doesn't work quite right (as of 
Aug 13, 1999).

The source is divided into four directories

	classes
		Java source files
	src
		Native code (C++/C) for Java classes and stub support
	test
		Test code, including a dummy XPCOM component
	tools
		Support tools:

		genproxy -- Generates Java source for a proxy class 
			to an XPCOM object.  (Eventually will
			generate bytecodes and interfaces.)


Build
-----

Currently only UNIX/Linux builds are supported (mainly because it's my 
platform of choice).  Windows builds should not be too much more
difficult, and 

1. Make sure MOZILLA_FIVE_HOME is set correctly, and that JDKHOME indicates 
   a valid JDK 1.2 installation.

2. Insure that the following are in your LD_LIBRARY_PATH:

	$MOZILLA_FIVE_HOME
	$MOZILLA_FIVE_HOME/../lib
	mozilla/java/xpcom/test (or "." if you run in that directory)
	mozilla/java/xpcom/src (or "../src" if you run in "test")

3. In mozilla/java/xpcom, execute 

	../../build/autoconf/update-makefile.sh

   if necessary, to generate a Makefile, and then

	gmake JAVAC="javac -g -d $MOZILLA_FIVE_HOME/../classes"

   This is to get around bugs in Java compilation.   

4. Change directories to mozilla/java/xpcom/test

5. Execute

	gmake -f Makefile.test

   This has the side effect of creating JSISample.xpt in the main 
   Mozilla components directory; all other libraries, executables, and
   Java class files reside in the test directory.


Tests
-----

Both tests use the JSSample component, whose methods do nothing more
than print out the in and out arguments, and perhaps perform a simple
operation.

xptest

	This program takes the name of a JSSample method and a number
	of "in" parameters (coerced from strings to the expected
	data types), executes the method, and returns.  It is mainly 
	useful to test whether the "xpjava" native functions still 
	work correctly, independently of the JVM.

	Sample invocation:

		./xptest AddTwoInts 1 1

	Output:
		Starting ...
		Initializing XPCOM
		<some debugging messages>
		Registering Allocator
		Getting InterfaceInfoManager
		Registering Sample Factory
		AddTwoInts:
			0:  type = 2, in
			1:  type = 2, in
			2:  type = 2, out, retval
		Consuming 1
		Consuming 1
		Arguments are: 
		0) 1 : type 2, ptr=(nil)
		1) 1 : type 2, ptr=(nil)
		2) 7566446 : type 2, ptr=0x804fae8, data
		Calling XPTC_InvokeByIndex( 0x80932d0, 23, 3, 0x804fac8)
		Results are: 
		0) 1 : type 2, ptr=(nil)
		1) 1 : type 2, ptr=(nil)
		2) 2 : type 2, ptr=0x804fae8, data


XPCTest.main()

	This is a Java version of xptest.  Unlike xptest, each
	non-String argument to the method must be preceded by a flag
	indicating its type, out parameters require a "placeholder
	flag":

		-c:	char
		-b:	byte
		-s:	short
		-i:	int
		-j, -l:	long
		-f:	float
		-d:	double
		-z:	boolean
		-r:	placeholder for retval
		-0:	placeholder for out param (equiv. to -r)

	If the "command" argument is a number, XPCTest invokes the
	XPCOM method with that offset.

	Sample invocation:

		java -native XPCTest AddTwoInts -i 1 -i 1 -r

	Output:

		Initializing XPCOM
		Registering Allocator
		Getting InterfaceInfoManager
		Command: AddTwoInts, arguments: [1, 1, null]
		Results: [1, 1, 2]

	Notes:

	1. You must run native threads; Mozilla loads the native 
	   thread library, and the JVM will panic if it has to 
	   load both native and green threads.

	2. Because of the way the JDK links shared libraries, 
	   you must have a valid mozilla/dist/bin/component.reg;
	   otherwise, XPCOM will not bootstrap correctly.
	   Note that "apprunner" and "xptest" will create one.
	   Future versions will fix this limitation.