crossedstreams.com

Quick Version

If, after ‘installing’ a plugin for Eclipse 3.4 it’s not visible in Preferences or in context menus, check that your user account has permissions to write into the appropriate Eclipse directories – because Eclipse doesn’t warn you.

Preamble

For those who don’t know, Eclipse is an IDE heavily used for Java development. Like anything else, it’s a delicate balance of awesome and suckage, and today I got caught out by a pinch of suckage.

It’s a plugin-based platform, which means that anyone can write a piece of software that ‘plugs-in’ to Eclipse to extend or enhance the functionality. It’s a great approach, allowing me to tailor my own installation to my needs. Having recently re-installed Ubuntu Linux, earlier today I was trying to set up my plugins without success.

The Problem

I set up the m2eclipse update site as described in the documentation (pretty standard fare… Help > Install New Software…, paste in the update site URL and choose components to install) but after ‘installation’ was completed there was no sign of the plugin. There should have been new options appearing all over Eclipse, but no. Tumbleweed.

Tried installing the next plugin on my list… Subclipse. Same story. So not a problem with a plugin…

The Solution

…and then it dawned on me. I’d installed Eclipse into /opt, which is all locked down to root, with administrative privileges. Schoolboy error – no permissions for the plugin files to actually be installed under the authority of my user account, which is the context that Eclipse normally runs.

A quick chown to root:admin for the /opt/eclipse directory (rather heavy handed – I should probably have worked out which directories I needed write access to, but I was out of patience), ‘uninstalled’ the plugin in the Eclipse, tried the install again and then I was back in business.

I’m really surprised that Eclipse doesn’t complain when it’s ‘installing’ a plugin in directories to which it has no access. I may not be the sharpest tool in the box, but I’m fairly sure that permissions problems happen to other people too. I might go so far as to find out where you feed back to the Eclipse development community for once. Anyways, this post will help remind me next time I get this wrong, it might help someone out, and if nothing else you might be mildly entertained by my ineptitude.

Paul Brabban Development, Java

Bit of a random one coming up…

I needed to get an measure of the difference in performance between Perl and Java for a simple client application, so I wrote the traditional ‘Hello World’ app in both and ran a bunch of executions averaging over the time from start to end of execution. The net result:

Perl is around 34 times faster than Java.

Really? I thought Java was supposed to be fast? In fact, Dhananjay Nene talked about how comparatively fast a selection of languages – including Java – were on his blog, and cwilbur ’s comments suggest that in that experiment:

Java is around 100 times faster than Perl.

So how can these two conflicting results both be true? I’m sure you’ve already figured it out, but I’m going to tell you anyway.

Java code takes hundreds of milliseconds to start up, because Java code runs in the Java Virtual Machine which needs a little time to get itself ready before your code can run. Once it’s up, however, you can get performance close to (or even better than, in reality) that of typical C++.

On the other hand, Perl doesn’t need that environment and so can start faster but trades off more overhead at runtime, meaning slower running performance.

Just goes to show, application performance is another area where there’s no one right answer – it’s about choosing the right tool for the job – I don’t think there’s any way round these performance characteristics without cheating.

Paul Brabban Development, Java, PERL

Back in September, I blogged about how I’ve become a podcast addict. I said I’d follow up with short posts on the podcasts I listen to and why I give some of the precious little time I have to listen to them. I look forward to the stackoverflow blog podcast each week, so here’s why.

blog.stackoverflow.com – The Feed

Joel Spolsky (joelonsoftware.com, Fog Creek) and Jeff Atwood (codinghorror.com) started up the stackoverflow.com programmer’s Question and Answer site in 2008 and they’ve been running a podcast in which they talk about the site, the community that’s built up around it, software development and whatever else they feel like talking about.

Topics and Focus

The Stackoverflow.com Site

The design of the site and the decisions that the team made back then, and how those decisions have played out from the private beta to a site with over a million pageviews per day. I’ve not seen anywhere else you can get this kind of insight into a real project.

The Stackoverflow Community

From the initial programmer’s site, there’s now serverfault.com (sysadmin Q and A), superuser.com (for the family’s computer expert), meta.stackoverflow.com (Q and A about Q and A), careers.stackoverflow.com (jobs and careers stuff), and stackexchange.com (hosted stackoverflow engine providing Q and A site hosting on a paid-for basis), so there’s a lot of discussion about building and serving communities online.

Interviews

Over the past few months, there have been more episodes with software luminaries from outside the stackoverflow team, talking about what they do and their views on the sites.

The Transcript Wiki

Pretty much every word in every episode has been transcribed by listeners (there’s that community thing in action again), which means that the content can be accessed by search engines and people with impaired hearing.

Frequency

Weekly, only a couple of missed weeks over the life of the podcast.

Audio Quality

Always excellent, very clear and easy to listen to.

What’s Not So Good

Might be tricky to get into if you haven’t been following it, as I think there are a few recurring topics and in-jokes. I don’t think there’s much of that though, so I’d listen to a couple of episodes to give it a go if you’re interested in the topics.

Well, I think that about sums it up, cheers!

Paul Brabban Development, blogging