Thursday, May 08, 2008

Plugins In Java

I wanted to implement plugin mechanism in my applications. But the thing is, that the plugins should could be also a standalone applications with main() static function inside. This is not very that difficult in principle, just have nice way to do that. Another thing I really want to have, is a call-back mechanism that can get all the arbitrary things, implemented in the parent application. They can be a printing and reporting stuff, authentication, authorization and so on. Finally, I want to have some shared space, where all the plugins can store their arbitrary data and interoperate between each other. What I really do not want to have is a typical bloatware, built on top of some fat framework that does lots of workarounds for specific needs. The thing should be as simple as possible. 

But the challenge is, that if it would be a, let's say, Groovy or Python, then it is pretty easy to implement is: just pass a class instance. Since it is all dynamic — stuff just works. However, Java is a static language that has lots of goodness over dynamic languages, but also this is the place, where ugly shapes appears too.

I am not sure I got it completely right, but at least I could shrink entire http://jpf.sourceforge.net just up to few methods and thus throw away all the framework with no harm to the functionality.

Here above "Plugin Application" is a standalone application that is also a plugin and could be fully acquired by "Base Application". You can run your plugin app, but also you can get it's functionality in the "Base Application" by simply dropping entire JAR file into specified subfolder. That's all it is: just move the JAR and you're done.

Plugin Application has a file plugin.properties that is an XML (can not believe for the shame that there are no support for UTF-8 in plain-text properties!!!) and these props just simply describes what class is main to acquire and how. There also some additional information, like application title, some specific config paths and a menu icon to use. :-)

Base Application simply reads the folder with all the plugins that are subfolders with required libraries and properties file, finds a properties file, parses and registers the plugins. Then once user needs one, launcher actually loads it.

The most worse part of the whole story is a call-back mechanism. This should be a third external package, that is available for both main application and all the plugins. There are two things: an interface and dummy class that implements basically nothing. Real implementation is inside the main application that inherits that dummy class and implements the interface of the call-back. Base Application passes the type of the dummy class something like this:
Class paramType [] = {third.external.package.DummyCallback.class};
Class remoteObject = Class.forName("your.remote.object");
Method meth = remoteObject.getMethod("remoteMethod", paramType);
Above is how you prepare things. Now, call them, where RealCallback class is actually an instance of implemented call-back. In this example I create new one on the fly, but probably in your application it is commonly accessed field that has better constructor and does some real things:
Object params [] = {new ReallCallback()};
meth.invoke(remoteObject.newInstance(), params);

That's it. Base Application has been found remote object, a method and invoked it. Now, on the other side of the whole chain, the following thing is done:

import third.external.package.DummyCallback;
public void remoteMethod(DummyCallback callback) {
callback.dosomething();
}

This is probably the whole idea that already works for me pretty fine.

Wednesday, May 07, 2008

NetBeans 6.1 on OSX

Decided to try NetBeans 6.1 Final.
Shortly: everything fine, except one very disturbing thing that makes entire IDE dead. Right after default installation, IDE runs fine. But I've decided to put all required extensions and after restart IDE refused to run, saying that some buggy Xalan version appeared in IDE's class path, sending me to the Wiki, where I've got very strange suggestion to cripple my entire JRE by removing a Xalan from there.

Since this problem appeared after modules installation, obviously, some module brought it to me in addition. Real "Bad Guy ©" appeared in my ~/.netbeans/6.1/ext/ directory. After removing it away, everything runs fine. But ugly crap remains: after this one removed, IDE's class path overall still contains few xalan.jar files, that are just different versions.

No idea where it belonged to, but was too lazy to figure out. :-)

Thursday, May 01, 2008

Hacker Key

We do all remember Geek Code, that is somewhat now not updated for a long time. More neat toy for geeks appeared: a Hacker Key that looks kinda interesting. You can take a walk through generator of the Hacker Key or decrypt someone's.

Here is my hacker key:
v4sw7JUYhw4ln3pr7AOck4ma3u7BLMNOSw2m7l5ADEFRUVi63Ce4t3b4Len9a3Xs0r5g3