Hmmm... wonder what it would take to do this on the server-side. Make it a applet so all Java-Capable browsers can "test drive" Mozilla.

If the engine is all native code, it will kinda be a pain to do the applet browser, as you will need to have signed code (kinda redundant...you need a browser to get the appplet,which itself is a browser?) but, if it's just a stand alone app that uses the layout engine with a Java wrapper class to call the native methods, that's cool!

-Chris

I know that the native gecko code would have to be converted to java code (BTW, how IS Jazilla doing?) and I'm not suggesting that it wouldn't have it's draw-backs (1+ megs of Java code off the net is NASTY) but it would be an effective way to allow anyone to try out Mozilla, regardless of browser/version/OS (with obvious exceptions) before commiting to a download/install. demoware of freeware. It also allows highspeed LAN intranets to enforce a "standard browser", regardless of exsisting client-side browser prefference (and yes, in a large enough intranet, you're not always sure that all clients have a standard desktop suite; IBM, for example, has people running Win95/NT/Linux/AIX/OS2 running Netscape 3-4.5 and IE 3-5)

From what I have read, I believe the purpose of Raptor being embedded in java was to demonstrate that if you wanted to build a web enabled application or even an application that displayed style sheets (or any number of various applications that needed an HTML/CSS1 interpreter), you can reuse the Raptor engine (which is fast, native code) which is only a panel, and write the rest of the user interface/network plumbing, RMI accessing server parts, blah blah stuff in crossplatform java. Because it uses JNI, all that has to be there on the native side is the INTERFACE (sounds like XPCOM), but the actual binaries will be platform depended (like, win32 will have raptor.dll and linux would have libraptor.so, but the JNI (interface) will be the same between both, so the only platform specific stuff that needs to be ported is the engine (which has already been done). Damn cool!

-Chris

It looks like Gecko will exist on a huge number of platforms (Win32, Unix/Linux/Solaris, Mac, Amiga, etc.). If Gecko is on so many different platforms, why don't we just embed it into the standard JDK as a basic JDK service? Just as Microsoft wants to integrate the browser into the OS, why don't we just integrate Gecko into the java 'platform'? This would mean that we won't need to distribute DLLs, linked libraries, etc. for each platform if we want to use Gecko, while we would get the speed of having a native browser in our java programs. Send me email if you are interested in this. We could probably use the Sun community process to define this.

Thanks, Brad Neuberg VP of Technology, <a href="http://www.basesystem.com">BaseSystem Inc.</a> <a href="http://www.openportal.org">OpenPortal</a>, where websites become discussions, and discussions become websites.

The screenshot showed Gecko being embedded in Java on a Mac. How does JNI work? Would the exact same code also work on Win32? If not, how extensive are the changes that would have to be made?

Here is how JNI works:

First, you have a set of functions in a library (I'm sure Raptor.dll has a whole slew of them). You make this library on the target platforms (raptor.dll on Win32, and libraptor.so on linux). Now, these 2 libs prolly won't have the same code (definitely not the same binaries) but they will both contain the same method calls (or, maybe not, more on this later). Then, put this lib aside for a while.

Next, you write the Java classes that encapsulate the functions located in the raptor lib. All the methods in these Java classes will be declared 'native'. You would make multiple Java classes to logically group all the functionality in the Raptor lib. Also, in the constructor of the class, put a call to System.loadLibrary("jniraptor") (remember this name!)

Next, you use the javah on the new classes to generate the header files that will be used in writing the C++ to Java interface. Then, you create a new C++ file that includes the generated header files (along with some other necessary JNI header files), and you hookup the JNI calls to their appropriate native calls located in the Raptor lib. Then you comple this code into a linkable library. Call it libjniraptor.so on linux, and jniraptor.dll on win32 (this is important naming convension!). (the jniraptor part is the important. On the Linux JVM, the JVM will look for libjniraptor.so when loadLibrary("jniraptor") is called, on a Win32 JVM, it will look for jniraptor.dll, and it will serch the SYSTEM PATH not the CLASSPATH!)

Now, as far as the drawing routines (this is a rendering engine, after all), I have no idea how that was done. I'm sure he made a class wrapper for the Raptor functionality and subclassed it from component (or panel) so that it can be used as a drawing surface inside of Java, but I'm not sure how he got the native code to draw to the Java panel (if he even has done that!) Anyways, I hope this sheds some light.

Oh, follow up for MAC:

I have no idea what libs are called on a Mac, but it's the same principle. You use the generated header files from javah in your Mac C compilier, and you map the interface calls to the raptor Library calls. Haven't actually done any of this stuff myself, I just like to read about it.

-Chris

Wow, I'm overwhelmed by the response, and the number of hits to my web page!

Chris has described the process pretty well. I do actually have a Canvas class, that through the use of getPeer() is able to get the native window pointer, and that I pass onto Raptor. So Raptor is actually drawing into the Canvas and everything is clipped properly to the bounds of the Canvas. I call the new Canvas RaptorCanvas, and it is just as easy to add to a Panel as any other Canvas would be. It's pretty slick, but it still has some bugs to be worked out, but then so does Raptor.

-Kirk

Hopefully you'll get the win32 port working soon (and now that everyone has a link to your page, feel free to update it so that we can check the progress) oh and another thing-we need to get that screenshot on the box acid test gallery in mozillazine.

I think with a little more work, this project could be as influential and newsworthy for the future of Mozilla as the ActiveX wrapper has been, especially if the Java Raptor wrapper is somehow included into the java extensions API.

The whole thing about native code (and the avoidance of it with respect to cross-platform java) is that you are supposed to be able to take any java class and run it on any other virtual machine. Now, if you want to use this native code as part of the JDK, you MUST have a port of the browser on every platform the JDK is on, but this isn't even enough, because if you have embedded systems where Java is the only platform, then you have to write the raptor functionality in Java (because there may not be another OS or Platform for the native code to run on). But, as far as a standard extension for the Java platform, I'd say go for it!!

-Chris

PS. Kirk, was it a simple matter to override the getPeer() to grab a handle to the raptor window context? If that's the case, I guess there wasn't that much method mapping (native method mapping) was there? In any case, it must have been a pretty substantial effort for you do write the interface tot he native code, and I'm damn proud to know ya! :)

-Chris

Chris, I agree with you that one should be able to take any class and move it to any JDK, but I think that Gecko has been ported to a sufficient number of platforms that this is a possibility if it were included in the standard core JDK as a new java.browser class library. For embedded platforms there is the Personal Java and Embedded Java specs, which probably shouldn't include the java.browser stuff. The reason Gecko should be in native code is that it provides fast rendering, as opposed to HotJava which is interesting but doesn't provide the speed necessary for real-world apps.

RE: override getPeer()

Do I override getPeer()?

No, I just use it and the sun.awt.DrawingSurface class to get the native window pointer. The native interface code is about 1000 lines, but it will get slightly larger, soon. The Java code is about 1000 lines of code too, but it will get larger when I get the nsIStreamObserver working. That will allow the Java code to intercept URLs, and if necessary retarget them, stop them, etc.

-Kirk

Cool! I'd really like to see this just be an "org.mozilla.raptor.*" style API ... no need to bog this down in "Java Standard Extension" API wars. Get it right first, then later worry about how to make such an API work on IE5.

To respond to the statement that you would need a browser to access the mozilla applet (why download a 1 MB applet if you already have a browser in front of you?). Could the basic "viewer" program be java enabled, and if so, could viewer be capable of loading and launching the mozilla applet? If this is a possibility the tiny footprint of viewer (124k on a mac) would be an easy sell to OEMs to put on their computers and an even easier sell to those who want to use the mozilla browser and need only to initially download a 124k file to launch it. Granted, for modem users a 1 mb java applet download every time the want to use the web would be hard to swallow, but as it has been stated in an earlier response this would be a great tool in a high speed intranet situation.

(why download a 1 MB applet if you already have a browser in front of you?)

If the intranet files you are useing are dependant on the applet's rendering engine capabilities (read, you want people to load honest to goodness HTML 4.0 complient code). then using the applet within the existing browser would make sence.

Also it would be much easier to have people click a link on a web page, rather than trying to explain to them how to reach it through appviewer via command line calls...

This "idea" (ok, pipe dream, and mindless preamble) was more of an interem step, to intice people to actually "test-drive" Mozilla first. It would actually be much more efficient to just download the apropriate Mozilla version for you're OS in the first place.

'Sides, someone would still have to port the gecko engine to Pure Java first, the existing methode just a Java interface to the existing compiled Gecko code.