I am pleased to announce the release of Script Monkey. It’s a Java based open-source plugin/tool/framework aimed to take Java to the next level by ahieving the power & flexibilities of interpreted/dynamic languages.
Currently, it is available as IntelliJ plugin. Hopefully in the near future, I like to bring in more flavors of this tool.
I am not going to discuss the pros & cons of compiled vs. dynamic languages. Because, you may have already came across tons of articles discussing that. The key point which I would like to highlight in this article is how Script Monkey shifts the paradigm of Java plugin architecture.
Well, we all know what plugins are. Almost, every software products whether it’s browser, IDE or consumer app that is released in the market today would have some form of plugin/addon support. Plugins help the software tool to be expandable, customizable or tailorable for a niche user.
Alright, let’s get to the real meat of this article and discuss some underlying implementation that can help make my case. In good old days, the way we write plugins, whether it’s for Eclipse, IntelliJ or Netbeans is by creating a metadata/manifest file (maybe some .xml configs) that would contain the specifics of classes(controllers,actions etc.) involved and the plugins would be coded against the Plugin API (IntelliJ has something called OpenAPI. Eclipse & Netbeans have some similar API’s as well) provided by the tool.
If you think abt it, there are lots of boiler plate code involved in running every plugin. Like, the code used to load, unload, assign or delegate actions to the plugins. The most important of all is that the plugin is kind off closed. If you want to perform a slight variation in what a plugin is doing, then you need to checkout it’s source (if it’s open-source), make changes to the code, recompile and deploy it to wherever it’s supposed to go. In my opinion, one of the key reason why dynamic languages are pretty useful is because of not needing to write these kind of boiler plate code and the ability to perform lot of things during runtime. And, that is the exact same reason why Java has Scripting API & tools like Rhino, Jython, JRuby etc. are created for.
With that introduction, what Script Monkey is trying to offer is, we don’t need to write plugins for every small feature or functionality we are looking for. We can have one plugin, which is Script Monkey at the center and for every feature we need, we can get it done with the help of “plugin-scripts”(simple Javascript, ruby or python code) at runtime. The plugin-scripts doesn’t always need to make just Plugin API call, it can also do things specific to projects we are working on, like cleaning up temp files, backing up the folder or auto checking in to CVS etc.
I am not saying Script Monkey will replace every plugin we use in a tool, there may be complex features/functionalities, which is better off to be a plugin on it’s own than to be plugin-scripts.
Another important thing I want to stress here is, the tool we are using, whether its Eclipse, IntelliJ or Netbeans, already has millions of lines of code running inside. If the API is designed well, we should be able to exploit/invoke the methods we need at runtime. Which in other words, code re-usability in steroids 
.
Obviously, I didn’t want to overload too much details on Script Monkey in one article. Hopefully in my future articles, I’ll discuss more on other aspects of this tool as well.
Like I said before, currently it is available only as IntelliJ plugin. With the help of open-source community, I have confidence that I will be able to take it to Eclipse,Netbeans etc. users as well.
Thought, comments, questions?
It’s a good idea. I’ve downloaded the plugin and checked out the demos you posted; am waiting to see more.
This is not a new idea, even for Java, though. The most successful Java tool using this approach is perhaps jEdit, where you can write “macros†using a scripting language; the default language for jEdit macros is BeanShell, but you can use others. There are dozens of macros available, many of them contributed by the community.
Upside: people can contribute with less effort, and it takes pressure off the developer of the editor for new features.
Downside: in my experience, the biggest downside at least in jEdit’s case, was that scripts are somewhat slower than compiled Java. For any script that gets executed while the UI is being used, you can get tiny pauses when a script is fired, which can make the UI feel sluggish if too much is based on scripts. Also, since scripts were so easy to write, I found people spent less time creating reusable libraries (to write scripts on top of) and there was a certain amount of duplication between them.
Looking forward to seeing what you do with it.
Patrick
Congratulations, you just discovered emacs.
Thanks for the feedback. My apologies if it sounded like I discovered a brand new idea. I agree there are other tools with the scripting support. Script Monkey does not do anything new than leveraging already existing Scripting API & trying to bring in more dynamic languages like Ruby, Python etc. into the game.
Just a small update to my last response.
I meant that the compiled scripts will be cached and that would help little bit on performance.