Teasing through a Twitter Web Archeology: XML Binding Language (XBL)
Apr 07

Web Archeology: Java Pluglet API

Ajax, Java, Tech, Web Browsing with tags: , Add comments

Stone Henge-esque

Even since Ben and I looked at the notes for the first version of Mozilla that supported XMLHttpRequest, which suddenly took the technology from “Some ActiveX for IE” to “Ajax”, I have been interested in hidden technologies that maybe never made it. In those notes for that release we saw no mention of XMLHttpRelease, but technology such as FIXptr was prominently mentioned.

Also, something interesting about Ajax is exactly the fact that the technology was available since 1997, but didn’t make it big until many more Dilbert calendars later.

This points to the fact that there may be some hidden gems in the past that could also be resurrected in the now! As I look back in time, I thought I would talk about any that interest me in some way. Hence, the Web Archeology set of postings. If there is a technology that I am missing, please let me know!

Today I am going to talk about the Java Pluglet API. This technology is part of the Blackwood project at Mozilla, where it was created in 1999 by Igor Kushnirskiy & Akhil Arora.

Let’s walk back to 1999 for a second. Imagine working on Mozilla in a world where you had to futz with a lot of XPCOM and C++ to build things. XUL came about a way to reach out via more Web-y technology to get work done (XML, JavaScript, CSS, etc). In 1999, Java was a sexy language, and everyone was getting ready for fantastic server side Java with great technology like EJB ;)

What if the Java developers could get in on the browser action and develop rich plugins for Mozilla? This is where the Java Pluglet API comes in. It allows you to do just that, mimicking the C++ side of the house:

It was a conscious design decision to have the Pluglet API resemble its C++ counterpart as much as possible, while being able to reflect all of its functionality to Java, so that Plug-in writers will not have to learn yet another API. This concern, in our opinion, outweighed other alternatives which offered a cleaner, more Java-like look. Support for other Plug-in APIs can be easily added by contributing adaptors.

How you register the pluglet is via mime types. You could create application/wicked-cool and when that comes back from the server, Mozilla will say “hmm, I don’t understand this mime type, Pluglet Engine do you?”

At a high level the idea of writing extensions in Java makes total sense to me. It is obviously cross platform, but still low level enough, with a huge library set to get a lot done.

Isn’t this dead?

Probably? Ed Burns did step up to the plate though and reenergized the project recently. As part of the resurrection you can now interface directly between the Java side and JavaScript itself.

If you squint a little, you see an interesting plugin path for the browser. I often say that I would love for Gears to be made using Java instead of C++!

3 Responses to “Web Archeology: Java Pluglet API”

  1. Dimitri Glazkov Says:

    Take a look here:

    http://www.whatwg.org/specs/web-apps/current-work/multipage/section-browser.html#custom-handlers

  2. Ray Cromwell Says:

    What I like about Google’s Android Platform is that is already supports this, see:
    http://timepedia.blogspot.com/2008/03/gwt-road-to-15-linkers.html

    The entire platform is Java, but Webkit is native, and WebKit’s Javascript engine can be extended with Java classes extremely easily (easier than Blackwood)

    -Ray

  3. Brad Neuberg Says:

    Great idea for a blog post series ;)

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: What is the number before 3? (just put in the digit)