murphee's Rant

Thoughts'n stuff by murphee. Slightly more about me at murpheeOnline
Maintainer of EclipseShell , scripting for Eclipse made easy.

All | General | Java | Music | CPUs | /proc/murphee | VMs/GC/Compilation | Operating Systems | EclipseShell | Books | Eclipse | Ruby

20060413 Thursday April 13, 2006

JRuby on Rails inching closer

The JRuby team is getting closer to having RubyOnRails running on JRuby Seems like the RoRoJ (RubyOnRailsOnJRuby, my personal acronym which I expect to become just as ubiquitous as AJAX in about 12 months) answered its first request. There‘s of course much more work (I think yaml is still a problem, and a JDBC connector for ActiveRecord is also needed), but the JRuby guys are determined to get there.

Have I mentioned that you can use JRuby to script Eclipse using EclipseShell

(2006-04-13 10:08:09.0) Permalink Comments [2]

20060330 Thursday March 30, 2006

Blogs of JRuby team

If you‘re following the JRubyproject, you should subscribe to the blogs of the JRuby team members:

  • Charles O. Nutters blog
  • Thomas E. Enebo blog
(2006-03-30 10:42:28.0) Permalink Comments [0]

20060328 Tuesday March 28, 2006

JRuby 0.8.3 released (Update)

Oh boy, a new JRuby release! JRuby 0.8.3 has just been released Many improvements, among it a working version of irb for JRuby (although you're surely using EclipseShell with the JRuby language support for all your JRuby scripting needs).

What are you still doing here? Get JRuby 0.8.3 from SourceForge
Update: Curious… I post a link to the new JRuby release and 3 folks feel compelled inform me that I shouldn‘t use it (see the comments to this entry).
@Bob: I don‘t see keeping up with native Ruby as a problem, Ruby‘s syntax doesn‘t seem to change too often, as far as I can tell; the next bigger syntax change will be Ruby 2.0. As for using the proposed other JVM languages: I haven‘t tried Pnuts and haven‘t heard much about it, which can only mean that documentation is scarce. Ruby, on the other hand, has lots of documentation available; it‘s not just syntax docs or tutorials, it‘s also about learning common idioms, best practices, or AntiPatterns. Coming from a Java background, I find it useful to hear of experiences with various features and idioms so I know which ones to try and which ones to avoid. (The Java world has the samt thing in books like Joshua Blochs “Effective Java”). On Groovy: it sounded nice a couple of years ago, but the constant changes got a bit boring, not to mention that it has the same issue with lack of experience and documentation as Pnuts. I‘m not trying to start another language flamewar: if Groovy gets it‘s act together and manages to communicate it‘s benefits to the world, then I‘ll take another look. As for Beanshell: it‘s great, but it‘s aim up until now has been to be a dynamic Java (REPL and all)... which means you can easily prototype Java code, but it‘s just not as nice to write as Ruby code, not by far. I think Beanshell should have been included in Java 6 instead of Javascript, exactly for its closeness to Java syntax, but if you want to experiment with code on a command line, Ruby ist much nicer.

@Slava: I‘ll be curious to see what the invokedynamic bytecode will do, and if (and how) HotSpot will make use of it. If there‘s any chance of caching method lookups, I guess there might be potential for speed improvments. And if real hotswap of classes (ie. including updating it‘s signatures) is included in Java 7, that might help too. Let‘s see where this goes. Not to mention that there‘s also the option of just compiling the code down to Java bytecode, which will also be able to improve performance. And even if that still isn‘t fast enough, then JRuby has a nice option: prototype the code in JRuby, then rewrite the performance critical parts in Java to take advantage of some Java language specific Hotspot optimization. As for continuations: again, let‘s see where this goes. The JRuby guys have ideas on how to make that work and work fast; I‘ll have to allocate some time to look into that some more.

@tomatsu: Dynamic dispatch isn‘t the only problem, but improving its speed will certainly help. Having the Ruby code JITed to bytecode, instead of executing the instructions on the AST, should also improve matters.

(2006-03-28 10:22:58.0) Permalink Comments [3]

20060323 Thursday March 23, 2006

Java for Interplanetary Navigation...

Artima posts the controversial statements that James Gosling made recently about Java vs. dynamic languages
Don‘t worry, I‘m not going to get my panties boxers in a twist over the statements... but one thing James Gosling said tickled my memory. The words "Java" and "interplanetary navigation" in the same context... hadn't I seen that before? ... Ah... no need to actually think, just tappetytap the words into Google's search box... et voila: Java Technology and the Mission to MarsWow... the name NASA has always been used to make engineers, geeks and nerds stop in amazement. “NASA uses $FOO” has been used for decades to give $FOO a credibility boost… no matter what NASA actually used $FOO for.
In the case of the Mars mission, read the provided article closely. You‘ll see that Java wasn‘t actually used to raise shields, control the warp core or make realtime adjustments to the wormhole transmogrifier, or whatever else. You‘ll neither find multiple J2ME VMs on the actual space vehicles or anything else. Nope, Java is used to access the databases and visualization (ie handling, displaying and analyzing images).
BTW: this project has been using Eclipse RCP for this GUI application in the Maestro project, see this paper on Eclipse and Maestro
So… let‘s see… what‘s can dynamic languages offer for these tasks:

  • Database access: hmm… a process mostly limited by I/O and a task that has been in the hands dynamic languages for ages; just consider that in the 90s, web development was synonymous with Perl, and later PHP. The speed of these tasks is limited by the RDBMS system anyway, so all arguments of “not scaling, not performing well” are bullcrap.
  • Visualization/ImageAnalysis: Lots of libraries for this are available in the open source space (ImageMagick, VTK,...), not to mention the bindings to various languages like Ruby, Python,... Actually, if you want to do anything fancy in that area, you‘ll have to use tools like Mathematica, Matlab, etc anyway. Good to mention that these are dynamic languages.
  • Navigation/CelestialCalculations: Well, talking about Mathematica, Matlab, and friends: I doubt that any engineer trying to plot or plan space trips would use Java for anything mathematically sophisticated, unless forced to do so at gunpoint.
  • HardwareControl: well, considering that projects like these usually think in geological time frames, ie. Java has barely even appeared, not to mention that JSR-001 (Java Realtime Specs) has only recently become real, after 5+ years of … incubation (or whatever that could be called). So, I‘m not sure where Java is in this place… however, last years RubyConf had a talk on using Ruby in Marine Robotics (listen to the podcast version of the talk on marine robotics and Ruby ). Feel free to provide examples for either Java or dynamic languages in this area in the comments.

So… I wonder: where is the place for Java in the big interplanetary navigation business? Well, exactly where it has been for half a decade now, in the niche it has carved out for itself: websites, database access, and Eclipse RCP) GUI tools. Gee… considering that the first 2 are strengths of dynamic languages (at least according to James Gosling), that brings us (Java community) under a bit of competitive pressure, doesn‘t it? Not to mention that any kind of interesting code is written in high level languages, not low/system level languages like Java. No I'm not talking about code shuffling data around, but code actually doing analysis and calculations. There's a reason why, for instance, Google's using their own language "Sawzall" for many of their algorithms that do the really heavy lifting. Here we have a rather simple, high level language that still wields the power of the huge Google cluster to mine huge datasets. See the paper Interpreting the Data: Parallel Analysis with Sawzallfor details.
(BTW: just to piss off both statical typing and dynamic typing aficionados in one single post, I‘d like to point out that Sawzall is a statically typed scripting language.)

So… before anybody here complains about my nasty, nasty comments about good, old Java: shove it. Instead, try to be constructive and point to niches for Java that I‘ve missed.
I‘ll give a headstart:

  • Luceneis pretty cool, but starting to get copied to other systems
  • Eclipse RCP, but seeing the big interest in scripting at this years EclipseCon, I‘d say that Eclipse will use dynamic languages (JRuby, Javascript, ...) to go full circle and become more and more like Smalltalk (the system that had/has a major influence on the design of Eclipse).
(2006-03-23 10:29:27.0) Permalink Comments [0]

20060321 Tuesday March 21, 2006

OpenSparc Verilog code released

Seems like Sun followed up on their promise to open source the verilog code for OpenSparc The Verilog code (and more) for the OpenSparc CPU is available for download at the OpenSparc website

(2006-03-21 10:17:33.0) Permalink Comments [0]

RadRails Eclipse Best Developer Tool Award

Congratulations go out to the RadRails who just won Eclipse Best Developer Tool Award!.

Oh, this reminds me of a post on one of the RadRails developers blogs. In People are spoiled by open source he refers to some of the annoying behavior that they encountered while developing RadRails. In this case, some anonymous waste of air told them "to stop dragging our feet". There isn't really much to say about that kind of bastard, except to wish that a rabid pack of squirrels bite off his todg... ears and slap him around the block with it.

I hope this Best Developer Tool Award makes RadRails guys forget this nonsense, and keep up their spirits.

(2006-03-21 09:42:17.0) Permalink Comments [0]

20060315 Wednesday March 15, 2006

Fossill not a fossill yet? Jackpot seems to be alive

Wow… blast from the past: seems like the Jackpot Projecthas finally released an Early Access release. Quite a surprise, I hadn't expected something not consisting of hot air from that area again. I think I first heard about it in this Artima interviews like this one with James Gosling Looking at the Sun Research page for Jackpot is quite odd too, as they mostly talk about other aspects, and not what the now released Jackpot contains. Not to mention that the research page says the project started sometime around 2000.

Considering what Jackpot actually is, this big ramp up seems a bit odd. What was released now, can basically be broken into two parts:

  • A pattern language for describing code patterns. This uses an AST of the language (seems like it‘s the one or similar to the one provided in Java 6), so the pattern language doesn‘t act on source text but on more meaningful structures.
  • The 2nd part allows to transform the found items/nodes into something else. It‘ll take the AST nodes, apply the transformation to the tree, and serialize the result into source again.

All talk and no show make Falula a dull h… er, I mean, let‘s see an example:
new java.lang.Boolean($b) => java.lang.Boolean.valueOf($b);
This is a very simple one, that looks for the Boolean constructor call. The actual expression evaluating to the parameter is captured in the $b. The part after the => is describes the transformation, ie after it was applied, the code will have been changed to call valueOf instead of using the constructor instead. Look for more samples at the Jackpot Rule File Examples page
That‘s basically it for now. There are some other aspects to the language, but you can glean that from the Jackpot documentation
Generally, I‘ll say I‘m a bit underwhelmed about the analysis part. 5 years back, this would have been pretty cool, but now it‘s mostly just another static analysis tool. Tools like PMD are out there and have tons of already defined libraries describing bad code patterns. PMD is a good example, as it also facilitates writing these rules, by allowing to use XPath to describe patterns. I don‘t know whether those tools also support the type inferencing that Jackpot seems to use (to check what type an expression returns); I‘m not sure about this one (commenting is free and gratis here @ Jroller.. HintHint…).

The transformation part is a different matter; I‘m (again) not sure if this is supported by static analysis tools. Of course, all major IDEs have had the infrastructure to do these kinds of transformations with their Java Project models for years, all of the refactoring depends on it. It‘d be possible to create simple DSLs to make their functionality available in script form as well, so it‘s not necessary to write Java code for that.

I‘m not entirely sure where Jackpot is supposed to fit in; it could be a part of a refactoring tool, but it‘s definitly not one in it‘s own right… at least not if you‘re looking at what Refactorings IDEs nowadays support. (A simple example is a class rename, which involves checking a whole project model for references, and not just a single file). These involve more than just simple matched patterns and transformations.
However, I suppose Jackpot (or similar languages) could play a part in those, ie. describe some analysis with it and use its results for further processing of the refactorings. Think of it as the difference between analyzing with an XML file using only DOM or an XPath interface. The former often needs lots of loops and ifs to walk the tree, the latter can use little XPath snippets to find parts of the tree. Of course, having lots of little XPath snippets stored as Strings in your code isn‘t really nice either, as you‘ll get neither tool support or even syntax highlighting. If it‘s a small snippet, it‘ll seem like overkill to read it from a resource, especially as it‘ll make it more tedious to understand what‘s going on in the code.

Generally: I‘ll be interested to see where this goes.

Update: Thanks to Tom Ball for a short overview of the origins of Jackpot in the comments to this entry. He also points to the Jackpot API which allows access to the Jackpot engine and would make it possible to write more sophisticated tasks with it. I skipped over that when first checking the Jackpot docs, thinking it was just the engine docs, but I'll have a look again. I'm currently looking into getting similar information from project models of Eclipse JDT (Java) or RDT (Ruby, from the RubyDevelopmentTools) and other languages, so that's definitly an area of interest for me. BTW: the best way to do this is to mess with a live project model using EclipseShell and one of the supported dynamic languages (JRuby, Beanshell or Javascript).

(2006-03-15 08:20:55.0) Permalink Comments [1]

20060312 Sunday March 12, 2006

Ruby and KDE

Seems like Ruby is increasingly used for automation of desktop applications, as seen on this blog entry about Ruby One example is that amaroK now depends on Rubyand the amaroK developers actually ripped out some C++ code and rewrote that functionality with Ruby code. This is made possible by KDE's wise investment in DCOP, which allows automation of KDE applications.

(2006-03-12 14:18:43.0) Permalink Comments [0]

20060311 Saturday March 11, 2006

Scone of Stone...

Hehehe… if you want to understand references in Terry Pratchett‘s books, you just need to look into the past. In his book “The fifth Elephant“, the “Scone of Stone” makes it‘s appearance as a very important piece of royal, dwarfish pastry. I used to think that this was just another mad idea, until I stumbled over this Wikipedia entry on the Stone of Scone I‘m not sure if the whole Dwarf bread idea in Discworld came from that, or if they have a different source, but now I understand the origin of the “Scone of Stone”.

BTW this is just another of Terry Pratchetts many references to UK history… another one are the Nac Mac Feegle, which are pictsies I used to think that that was just their fancy way of spelling pixies (like Vampyre vs. Vampire)... until I found out about the Picts... and of course that explains the NacMacFeegle‘s fancy for tattoos and pseudo scottish lingo…

It‘s quite incredible how many of these things Terry Pratchett manages to include in his book… another one I recently learned about, was the origin of the Clacks system in Discworld (a semaphore based communication network). While I thought it an ingenious idea of Terry Pratchett, it turns out that this was actually a kind of ancestor of the telegraph. If you want to know about this (and about the creation of the telegraph), you‘ll need to read this stunning book: The Victorian Internet Perfect in length for a mid-range plane flight, and extremely englightening.

Oh… and if you really want to explore the depths of Terry Pratchett‘s books, you‘ll need to have the Annotated Pratchett with you at all times. And while you're over at L-Space , check out their Terry Pratchett Interviewspage.

You know, seeing the products of a mind like Terry Pratchett‘s is really inspiring (oh boy, I don‘t think I‘ve ever used that word before), but also a motivation to read around and have an open mind about many topics. Oh… and his scathing humor is also something to be aspired… one of my favorite quotes (paraphrased): “I can‘t be a politician, MY parents were married…”.

(2006-03-11 13:34:48.0) Permalink Comments [0]

20060310 Friday March 10, 2006

Quake @ 10240x3072 (yes, that's tenthousandtwohundredforty)

Bloody. Hell. ! With all the frames of the screens, walking through the Quake world with this must be how Shelob experiences it‘s environment (segmented eyes, huge, ... er… you‘ll get it). Good thing it‘s just Quake 3… I‘m not sure I want to explore the Doom 3 world like this (Doom 3 is great, but with my usual caffeine intake, I already jump sky high whenever some noise startles me. And that‘s just while looking at my laptop screen… I‘d rather not be immersed in that world…).

(2006-03-10 13:16:12.0) Permalink Comments [0]

20060307 Tuesday March 07, 2006

EclipseMonkey scripts with EclipseShell

The Eclipse Dash has publically released their EclipseMonkey plugin, which is an effort to facilitate Eclipse scripting. The main concept is that of the DOM or Domain Object Model (read about the basic idea behind DOMs). Basically, a DOM is a simplified adapter of some Eclipse (sub)system; it‘s simplified to make it easy to script and so you don‘t have to worry about all the details. You can still get the systems behind the DOM, if you need the full power, but they should suffice for most uses.

Writing a DOM is simple, it just consists of contributing to an extension point and provide a variable name that the users get to see (see this document for details on writing DOMs).

What does this have to do with EclipseShell? A lot, because it‘s simple to make use of EclipseMonkey DOMs from EclipseShell. You simply query the contributors to the “org.eclipse.eclipsemonkey.dom” extension point and use their DOM objects. If you don‘t know how to do that, don‘t worry, I already provide scripts that do that for you, so you simply have to call a method and get a Map that maps from the standard DOM variable name. See the EclipseShell Scripts page for JRuby and Javascript util libs for accessing EclipseMonkey scripts. Eg. in JRuby you just download the util script to a location on your $LOAD_PATH (you see that value when JRuby starts in EclipseShell), and simply to require 'monkeyDoms', and 'monkeyDoms() will give you a Hash (mapping from the DOM variable name to the DOM object).

The default EclipseMonkey installations comes with a 2-3 DOMs focussed on resources (ie. accessing files in the Workspace). Eg. in JRuby, this code will give all the files ending with “.rb” in your Workspace:

res = monkeyDoms["resources"]

All this is already pretty useful, and it‘s only getting better. Eg. it‘s possible to easily publish EclipseMonkey scripts that need nonstandard DOMs; the script simply refers to the update site of the DOM plugin in its metadata section (see information on writing Eclipse Monkey scripts, including metadata etc). The final versions of EclipseMonkey will also provide simple ways of hooking into notification systems in Eclipse (ie. reacting to events like resource changes, etc).

(2006-03-07 10:19:00.0) Permalink Comments [0]

20060302 Thursday March 02, 2006

JSR 292: Supporting Dynamically Typed Languages on the Java Platform

The road to better support for dynamic languages on the JVM is about to be paved with the just proposed JSR 292 This seems to be the JSR for the addition of the invokedynamic to the JVM in Java 7 (Dolphin).
I wrote about invokedynamic before, including links to Gilad Bracha's blog on the topic
Reading the overview of JSR 292 brings up another interesting planned feature: updating class structures at runtime. It‘s already possible to use HotSwap to update the contents of method bodies of loaded classes, but structural change of the class definition is impossible (causing the dreaded debugger dialog “Hot code replace failed”). One annoying restriction here is the it‘s not even possible to change method signatures or just add/remove methods from a class. These changes have two implications:

  • What happens if a method (used by other classes) is removed? Would an error be reported after the class structure update or when the method is used again?
  • What happens with added fields?

The latter is an interesting problem: Adding a field to a class would, first off, mean that every existing object in the Heap would have to be updated with the new object layout, ie copying the old data into the new object. Problem: how do you initialize newly added fields? Sure, they‘d be initialized with the JVM defaults for their types, but what about fields that are initialized in constructors?
There are several ideas for this:

  • One would be a design solution of the class: always use an accessor to get the value of the field, even internally. This would allow you to write an intermediate accessor, that would check use a guard (ie. an if)to see if the field has been initialized; if it isn‘t, then it‘ll initialize it before it returns the value. While this causes the accesses to be a bit more expensive (additional if check), this could be solved by making sure that all objects with that field are updated (ie. the accessor is accessed at least once), and after that, the accessor is replaced with a cheaper version (ie. without the guard). This is a lazy way of updating objects as they‘re needed; the benefit is that it‘ll update the objects just in time, without any long pauses. It does, however, require a certain discipline from the programmers to make sure that all field accesses really happen via that accessor.
  • Another idea, that possible in environments like Ruby or Smalltalk, would be to have some code that initializes the field values of all affected objects. This is not (yet?) possible in Java, because there‘s no way to iterate over all objects in the heap. In Ruby, for instance, this is extremly easy. Want to see all objects of type Numeric? ObjectSpace.each_object(Numeric) {|x| p x } will do the trick. With this you could update all objects of a type in one go. This approach has the upside, that all objects will be in a usable state after the update operation. One of the downsides is that it can take a while to reach all the objects (depending on how expensive it is to find objects of a kind and on the size of the heap), which would cause the application to pause.

While I don‘t suppose that the latter solution would be available in Java (at least I haven‘t seen an indication in the JSR), I suppose the first solution would be a great way to allow dynamic, runtime software upgrades. This‘d mean that you could update the code of an application while it‘s running without requiring downtime the application‘s data would simply be updated as described and no restart would be required.

If both changes (invokedynamic and hot class structure updates) make it into Java 7, it‘ll be a great release for dynamic languages, but also for plain Java code.

(2006-03-02 10:40:41.0) Permalink Comments [0]

EclipseShell: Scribbling with the ScratchPadView

EclipseShell allows your scripts to build GUIs or just draw something on a canvas using Draw2D. For this, it packs the “ScratchPadView“; this is a View that allows multiple instances to be created. Use it as a way to “scribble” onto a GUI with your shell, using SWT/JFace or some of the graphics APIs for Eclipse (Draw2D, GEF, OpenGL,...).

You can see a demo of this in the Interactive GUI building with JRuby and EclipseShell screencast (Warning: link goes to aFlash movie). In this I interactively build a basic Class Browser (using SWT) using JRuby. (Consider the fact that this is using Ruby to build a Ruby Class Browser…).

You can use the ScratchPadView from all of the supported JVM based languages. I mostly use JRuby, because it's just the most concise language for use on a shell. This is the reason why the current list of util scripts I provideconsists of 2 JRuby libraries (one for JMX access, one for Eclipse scripting).

The eclipse.rb util library contains a method for the ScratchPadView called createScratchPadView(nameAsString), which takes a name for the View (more precisely: the secondary View ID it's supposed to use) and returns an object of type net.sf.eclipseshell.views.ScratchPadView. This has a method called getComponent() that'll give you an SWT composite that you'll use for your GUI components. With that, you can start messing with GUI components, or just add a Draw2D FigureCanvas and use this to create display figures.

A little side note: if you manipulate GUI components, in EclipseShell code, you‘ll run into a problem: the EclipseShell editor executes all commands in a background thread (ie. not the Event Dispatching Thread or EDT). The reason is obvious (long running commands must not block the GUI), but it means that all code that accesses the GUI code will fail with an exception, because SWT (like many other GUI TKs) only allows GUI modifications on the EDT.
But don‘t despair, SWT has it‘s utility methods to allow this, and the JRuby eclipse.rb util library has some code that makes this even easier. Executing code on the EDT with JRuby looks like this:
syncExec{ yourCode } or
syncExec do

Yep, thanks to Ruby‘s flexibilty (and the blocks feature), it‘s quite easy to issue commands on the EDT by simply wrapping them in the syncExec construct.

(2006-03-02 08:48:43.0) Permalink Comments [0]

20060301 Wednesday March 01, 2006

EclipseShell: Scripting for your IDE

So you want to use dynamic languages to script your Java classes? Use JVM based languages like JRuby, Beanshell or Javascript (Rhino)? Interactively explore or prototye Eclipse plugins?

Yep, then EclipseShell is for you. It's my latest project that comes out of the need to make exploratory programming easier in Java. The basic premise was: "Make it trivial to get an interpreter shell and fire of some commands" With many JVM based languages, this isn‘t easy. Many ship with some types of shells, but they‘re usually either just loops that read from stdin on your terminal or some basic textfield based GUI that isn‘t really usable for anything but the most basic commands.

What do I want:

  • Make it easy to write and edit multiline statements, like method or class definitions. I don't know of any shell that makes this easy. Sure, I guess there are ways to do it in Ruby's irb or others, but I haven‘t figured them out, and frankly I don‘t want to. The most natural interface (for me) is an editor where I can move around and edit with the usual keys.
  • The command history should be easily accessible. After long shell sessions, I usually remember that I issued some call some time ago… which usually ends in frantic KeyUpKeyUpKeyUp...KeyUpKeyUp orgies only to find the damn statement. (Don‘t bother commenting that tools like zsh, etc have more sophisticated completions; the language based shells don‘t have them, so that‘s no use).
  • AutoComplete. ‘nuff said. Dynamic languages might not allow the exact same level of AutoComplete as Java while editing source files, however: they are perfectly accurate at AutoComplete at runtime. If you want to know what methods an object provides, simply ask it using reflection. (with languages like Ruby or Javascript, it‘s actually necessary to ask a specific object considering that the former supports open classes, and the latter doesn't really have classes). (J)Ruby makes reflection dead easy ("I'm a string".methods gives you a list of all the methods of this String object), but for an old Eclipse user, it‘s even nicer to have the old familiar AutoComplete popup, which also allows to narrow down the list through simply typing prefixes.
  • Script from my Eclipse Workbench. I don‘t want to have to go out, find where I set up the language, remember what I have to call to start the shell, start the shell, curse because I forgot to add libraries of interest to the CLASSPATH of the language, restart, etc.
  • Prototype Eclipse Plugin code or Plugin tests inside the IDE. The PDE has support for writing and running JUnit tests for testing Eclipse plugins, but writing them can be a bit of a mind bender, as you have to remember where to hook in or which handles to get.
  • Simply ‘reach in and twiddle some knobs or peek in some dark corners‘ if there‘s a problem with a plugin. It‘s possible to get pretty far with the Debugger and HotSwap, but it‘s just very tedious to constantly suspend the app, change code in some method, continue, glare at the stack frame contents,... Sometimes it‘d much easier to just say: “Give me the damn Editor object so I can kick it in the right places… err call the right methods, to make it work”.

All of that is basically addressed in EclipseShell.

EclipseShell integrates dynamic languages into the Eclipse IDE, making it easy to

  • pop open a shell for the dynamic language of your choice (it doesn‘t need to be JVM based, the Ruby language provider comes with a Ruby irb mode)
  • quickly fire of a few commands in the language of your choice without having to leave your comfy IDE
  • discover APIs and the Eclipse plugin space by providing AutoComplete
  • save your execution history for later reference or to allow others to follow your steps exploring an API
  • prototype Eclipse plugins or GUI code interactively

Checkout the EclipseShell website and use use the UpdateManager to install EclipseShell
If you want a quick introduction of what you can do, see the EclipseShell Screencastspage.

Oh… and if you‘re annoyed that your favorite language isn‘t supported, head over to the Developers section to read about creating a new language provider for EclipseShell.
Just a little note: this first public release is “0.1.2”; this means this won‘t be perfect, but I‘ve been dogfooding it for 2+ months now, and it‘s very useful and stable. There‘s a MailingList at Sourceforge for discussions and also the best place to start for developers who want to add language providers for their favorite language.

(2006-03-01 11:45:49.0) Permalink Comments [2]

20060215 Wednesday February 15, 2006

Spot the bug - Sneaky edition

Let‘s have a bit of fun and chase some bugs… or at least one, that just had me cursing like three sailors with Tourette‘s syndrome.
The following code always executes the line in the block, even if the if condition is false (you can replace the condition with false and it‘ll still work). Yep, that‘s a real bug I just stumbled over.


// this will always get executed
exts = point.getExtensions();

You know, I curse the day when some language designer thought: “Wouldn‘t it be nice if I didn‘t have to put those nasty braces around a single line code block?”. Thanks to that b…recious (or was that precious person, it's now possible to write if(foo) bar();.

Hint 2:
Yes the code you see pasted here is exactly the one I used, nothing added/nothing lost.

Of course, the solution is simple: the little semicolon is the problem, as it terminates a statement… whether it‘s an empty statement or not.
Dave Brosius pointed out (in the comments) that PMD & friends would have found that. Yep, and even better: Eclipse already has this particular analysis included. Look in the Preferences under Java > Compiler > Errors/Warnings and on that page look in Section “Potential programming problems“ for “Empty Statement”.

(2006-02-15 13:52:44.0) Permalink Comments [5]


« April 2006

RSS Feeds

All [excerpts]
/General [excerpts]
/Java [excerpts]
/Music [excerpts]
/CPUs [excerpts]
//proc/murphee [excerpts]
/VMs/GC/Compilation [excerpts]
/Operating Systems [excerpts]
/EclipseShell [excerpts]
/Books [excerpts]
/Eclipse [excerpts]
/Ruby [excerpts]



  • Creating Passionate Users
  • Headius (JRuby Team)
  • Joel On Software
  • Manageability
  • Mika
  • Planet Classpath
  • Planet Sun
  • Schneier on Security
  • Squawks of the Parrot
  • Tim Bray: Ongoing
  • Tom's Ruminations (JRuby Team)

  • My Bookmarks


Front Page

Hits today:

Today's page hits: 73