Plugging into Lobo's Pure Java Web Browser

Lobo's Java Web Browser, still at a dot zero release, drew my attention today because it very recently was Java Posse's project of the week. I love the fact that this browser is pure Java! Plus, it is open source and under active development. Let's help things along by explaining how to create plugins, because this project is smart enough to expose an API for this purpose.

At the end of this article, you'll be able to start up the Lobo browser and you will then see a new menu, with a new menu item, that will produce a "Hello World" greeting in a JOptionPane. It will all look thusly:

Even though there is no "Hello world" document for Lobo plugin development (which I am hoping to remedy by means of this article), the Lobo Browser Plugin HOWTO provides most of the information you need. It is all quite intuitive, once you have the basics. Here they are:

  1. After you download the Lobo distro, put its lobo-pub.jar on your plugin-to-be's classpath.
  2. At a bare minimum, you need a class that extends org.lobobrowser.ua.NavigatorExtension. Here's mine, just to give you an idea. Note the overrides, of course, because these are the main hooks into the browser:
    public class ExtensionImpl implements NavigatorExtension {

    private JMenu menu;
    private JMenuItem item;

    @Override
    public void init(NavigatorExtensionContext ctx) {}

    @Override
    public void windowOpening(NavigatorWindow window) {
    menu = new JMenu("Greetings");
    item = new JMenuItem("Hello");
    menu.add(item);
    item.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent arg0) {
    JOptionPane.showMessageDialog(null, "hello world");
    }
    });
    window.addMenu("Demo", menu);
    }

    @Override
    public void windowClosing(NavigatorWindow window) {}

    @Override
    public void destroy() {}

    }

    That's all we need for our small scenario. Since we're simply using Swing, it is easy to imagine other things that you might do when the window opens/closes, etc. Use code completion and other tools in your IDE to figure out other things you might be able to do to the Lobo browser:

  3. Now create a properties file called lobo-extension.properties, in your src structure, at the highest level, and add the following info:
    extension.name=Demo Lobo Extension
    extension.description=This is a demo extension
    extension.by=Geertjan Wielenga
    extension.version=0.1
    extension.class=demoloboplugin.ExtensionImpl
    extension.priority=4

    The extension class is the one shown in step 2, registered by its FQN. The priority is described in the API docs, it's not so important at this stage, since w're just doing a hello world scenario.

  4. Finally, you'll have a plugin that looks similar to this:

    Now compile the plugin, creating a JAR that you put in the distro's ext folder. Below, mine is called "DemoLoboPlugin.jar":

Just restart the browser and there's your new menu. Since it is this easy to extend the browser, I'm hoping this intro has grabbed your imagination and that you'll support this super cool browser. If you love Java, you'll love this browser. Downloading the distro and setting things up was as simple as unjarring and then running java -jar from the command line. Here's hoping that the people behind this project will publish MANY small samples demonstrating the ways in which the browser can be extended. That way, they'd be giving developers handholds to making this browser all that it should be.

 

Average: 5 (1 vote)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jacek replied on Wed, 2008/02/06 - 11:20am

Forgive me for saying, but I think this type of project is really not very useful.

 Java needs to get out of its "everything must be in Java" mindset and instead integrate better with whatever higher quality native components are availabe on each platform.

I'd rather see full official support for embedded Gecko with a Java-friendly API. This would be way more useful in the long run. 

 Swing could definitely learn a few tricks from SWT. I still wince every time I see all the rendering issues with Netbeans under Ubuntu (from fonts to control rendering). 

 

 

Geertjan Wielenga replied on Wed, 2008/02/06 - 11:31am in response to: Jacek

Jacek, I agree with you that not everything must be in Java. However, on the other hand, I find these arguments from the Lobo page pretty convincing in this regard, under the heading "Why a Pure Java Browser?":

There are a number of advantages to be derived from a browser that is written in Java as opposed to a language compiled into native code, namely:
  • Security.- In principle, a Java program is less suceptible to certain types of vulnerabilities such as a buffer overflow attack. Java's security model can also allow web content to have access to a complex set of APIs, except in a controlled sandbox.
  • Extensibility.- A Java-based application can be extended via powerful cross-platform plugins. Consider the difference this has made for Java software such as jEdit and Eclipse. (Lobo already has a plugin API).
  • New paradigms.- With the help of Java we can implement new powerful cross-platform and secure mechanisms to represent web content. We would like to make it easy to integrate arbitrary UI languages into Lobo. We would also like to support JavaFX by default as a first-class citizen. But we also plan to allow, for example, representation of web content merely as Java source code.
  • Portability.- This is the obvious advantage of a pure Java application.

Fabrizio Giudici replied on Wed, 2008/02/06 - 7:38pm

It's not really easy to have a sound opinion on it. I personally like Lobo, that I've started using when it was called Cobra, at the time for a plugin of my application that should be able to display some web pages embedded in it, taken from real external websites (otherwise, if you are the producer of the HTML, you could better go for XHTML and use Flying Saucer). While at the beginnings I remember there were lot of problems in the rendering, Cobra/Lobo improved a lot. I've not tested it for some months now, since I've temporarily put the focus on other things to do. Is it better pure Java or a native Gecko integration? At the moment I can't answer. I'd prefer pure Java for the reason Geertjan talked of, mainly for the Security + Reliability (I still see some crashes in my Safari and Firefox browsers in certain cases, and I wouldn't like them to crash my application too). OTOH surely Gecko is a better option for rendering precision. But since there's no reason for which a Java browser can't become competitive, but for the fact of having a committed team of people working on it, in the end I think that it's a good thing that the Lobo guys are there. I'd wait more or less another year before understanding if a compliant Java browser is an option or not. 

 

--Fabrizio Giudici

Mark N replied on Wed, 2008/02/06 - 9:05pm in response to: Jacek

Jacek wrote:
Java needs to get out of its "everything must be in Java" mindset and instead integrate better with whatever higher quality native components are availabe on each platform.

If they exist and are integratable. I've done plenty of what you are suggesting. It usually doesn't work that well.

Jacek wrote:
I'd rather see full official support for embedded Gecko with a Java-friendly API. This would be way more useful in the long run.
There is a project like this. It is dead.

 

Jacek wrote:
J

Swing could definitely learn a few tricks from SWT. I still wince every time I see all the rendering issues with Netbeans under Ubuntu (from fonts to control rendering).

Maybe. But SWT could learn some from Swing. Like making custom components easy to do.

 

James replied on Thu, 2008/02/07 - 10:59am

I think that this is a very interesting project ... a very hard one. People immediately compare to the alternatives (IE or FF) and if your renderer is not as good as these, no one wants to use your software.

Stephen Bannasch replied on Thu, 2008/02/07 - 11:37am

FWIW: We've started a project called MozSwing:
* http://confluence.concord.org/display/MZSW/Home
that integrates v1.8.1.4 the Mozilla rendering framework XUL with the Java Swing GUI framework.

We've got working code on sourceforge:
* http://sf.net/projects/mozswing

MozSwing is triple-licensed: MPL 1.1, GPL 2.0, LGPL 2.1.

You can see it work by running this web start jnlp: http://jnlp.concord.org/dev/mozswing/mozswing.jnlp

Running that jnlp will also run an extension-installer jnlp that will install platform and os-specific XUL libraries in your web start cache.

There are obvious disadvantages to relying on a native libraries that have to be installed.

Some of the advantages to using the mozswing approach is that we have both rendering and scripting access from a Swing application to almost any XPCOM components (browser plugins) like Flash that can be embedded in a Mozilla browser.

We're planning on porting the mozswing code to v1.9 of XUL and XPCOM (same codebase that's used in Firefox 3).

kardelen133 replied on Thu, 2008/07/03 - 4:17am

thanks articke.

evden eve nakliyat 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.