Archive for August, 2007

Eclipse class loading

Wednesday, August 29th, 2007

Most people who ever touch Java come to hate the CLASSPATH environment variable. It always needs tweaking to enable Java to load the desired classes. Eclipse, therefore, totally ignores it. One of the features of Java is that you can replace the standard class loader with your own. Eclipse does so; and in fact each Eclipse plug-in has its own class loader.

You then just specify which other plug-ins yours depends on, and it all works beautifully, 99% of the time. It really does.

The only problem is in the very rare circumstances when a plug-in is dependent on classes from some other plug-in which it can’t predict in advance. One such situation applies to Macrobug tools: I have lots of plug-ins which contain events relating to what’s happening on the device. One feature of the tools is to save that stream of events so that it can later be replayed. I’m doing this using Java Serialization, which is an easy way to convert an arbitrary network of Java objects into a stream of bytes which can be written to file – and back again.

The problem lies with that ‘back again’ bit. The plug-in responsible for reading this event stream (com.macrobug.eventrecorder) needs to be able to load classes from myriad other plug-ins which have events that got recorded.

That’s usually impossible, and for that reason I massively constrained the original class structure so that my recordings only contain very basic generic types from plug-ins which the event recorder can safely rely on.

But today I’ve come across this article, most of which I already knew – but not the bit about registering ‘buddy’ class loaders. So, all I have to do is ensure that all my event-providing plug-ins register themselves as a buddy of the event recorder plug-in: and in future, the event recorder plug-in will be able to load classes from those plug-ins!

Hooray. I only wish I had known this months ago.

Licensing

Tuesday, August 21st, 2007

Appears to be spelled that way, even in British English. Ah well.

Licencing

Tuesday, August 21st, 2007

This may not be a very structured post, because I am thinking out loud into the blog. Sorry about that in advance.

Back in January I was pondering what sort of software licence to use. I linked to an article by Dan Bricklin which reflected most of my views about the licence choices available to small independent software vendors like Macrobug.

I keep a fairly close eye on developments with software licences. Yet I still haven’t made up my mind about what to use for Macrobug products!

The options are:

  1. Fully closed proprietary licence. The user has no access to source code, and no rights to distribute binaries. There are probably two licences; one for a time-limited evaluation version and one for the paid-for version.
  2. Shareware-type licence. The user can distribute the binaries, but must pay me if they use them for more than, say, 30 days. The user gets no access to source code.
  3. Dan Bricklin-type licence. The user gets source code and binaries, can distribute and modify them, but any recipient of any version has to pay Macrobug as if they had received the software directly from us.
  4. Fully open-source licence. The user gets the source code, and is free to do what they want with it. Macrobug gets an income from supporting the code and being the best in the marketplace at working with that code, customising it etc.

Obviously there’s a spectrum here between restrictive and open licences. Open licences, which give the users more rights, will be more popular with those users. But they also present more risk for Macrobug.

I am fairly certain that option 4 is a no-go at the moment. My personal view (and therefore that of Macrobug!) is that open source is usually the right business decision for commodity products: things which will be used by many, many people. In that case, the economically correct course of action is to share efforts by contributing to a common codebase rather than spending lots of money creating/paying for competing products. But there’s no role in that model for anyone to make a living providing such software; the whole point is that the users of the software co-operate to create it. And for more specialised products, where there aren’t enough users to co-operate to produce the software, having a single commercial software provider remains the sensible model. I feel Macrobug’s debugging tools fit into that category… which is fortunate because, as I say, I don’t see a role for anyone to make a living producing open source software. I almost believe I could make a living out of supporting/customising/developing the software if it were open source, but not quite. I’d like to move to this model in the future, though, if I start to believe it could work.

Concerning options 1 and 2, are there really many differences these days? I’ll be making a time-limited evaluation version freely downloadable from the Macrobug website (of that much I am certain). So, does the user gain anything by being able to distribute the binaries as opposed to get them from the Macrobug website? Probably not. The advantages of option 1 are that I have marginally more visibility over who gets the software, and maybe I stand a better chance of being able easily to lock down the evaluation version to the time limit. And I suspect people are less likely to feel they should pay for something with the word or concept ‘shareware’ attached. So, I’d argue that options 1 and 2 are basically the same, and I’d be best off treating it as option 1 rather than a shareware product I want people to distribute themselves.

I really like option 3. The main problem here is the complexity/expense/risk involved in creating such a licence. All the other types are available for download. I could try to throw together such a licence myself (= mistakes, risk) or pay a lawyer to do it for me (= enormous expense). I’m also not sure it’ll be that appealing to customers: even though they should be happy about receiving the source code, the fact that it’s an unusual approach would in itself put them off. So I think I am going to rule out option 3.

So where does that leave me? As far as I can tell, it leaves me – for now – releasing under a proprietary commercial licence. Bummer!

I must admit I haven’t entirely convinced myself of that decision. I was hoping that by the end of this blog post I’d have properly made up my mind. Ah well, it seems – sadly – to be the logical thing to do, for now at least.

PS In addition, when talking about software licencing we almost always read and see American licences, e.g. the GPL. So much so, that I almost always type ‘license’ not ‘licence’ and keep having to correct myself to British English…

What’s happening with Macrobug?

Tuesday, August 21st, 2007

We’re still vapourware. Still negotiating with Symbian to get the relevant access to bits of Symbian OS required. It’s a bit of a rollercoaster…

Deeclipsification

Monday, August 20th, 2007

A while ago I posted that I was going to try to de-eclipsify my software. That involves removing the reliance on fundamental Eclipse facilities – for example, the standard Eclipse classes for paths or memory addresses, or plugin loading – so that the code can be used with standard Java, and no Eclipse present.

I’m doing this partly because I may wish to produce tools which do not depend on Eclipse, but mostly because there are areas for which I don’t currently have a test suite because of these Eclipse dependencies. It will be much easier to test many bits without having Eclipse in the mix.

On the way, though, I experimented with producing standalone Eclipse applications (called RCP – Rich Client Platform – applications). It was very easy, and the resulting application can be used as a standalone GUI application or from the command-line. I could, therefore, have retained my Eclipse dependence if I’d produced everything this way. Unfortunately, though, even the tiniest RCP application seems to weigh in at many megabytes so this didn’t seem the right thing to do for simple command-line tools.

Having said that, I’m still planning on producing tools which use Eclipse’s Draw2D API for graphics – which can then be exported to PDF and/or SVG. So, it’s a bit odd, but I might be producing command-line Eclipse applications which utilise these Eclipse drawing APIs to create graphics.

Miscellaneous Bits of Japanese Culture 3/3

Monday, August 20th, 2007

The strange little tunes the trains play whenever they’re coming into a station, so that you subconsciously recognise you’re on the correct line. I’ve noticed this is starting to happen on UK trains too now: three years ago it would have been weird but now you get strange little tinkles on some of the modern privatised trains and it doesn’t even sound odd. I think this is probably more related to the omnipresence of computers and sound effects rather than a globally spreading Japanese culture.

Miscellaneous Bits of Japanese Culture 2/3

Friday, August 17th, 2007

One of the brands of truck you see on the road is called a “Super Great”. Imagine if, say, BMW called its 7-series the “Really Good”? I don’t think European consumers would go for it.

Miscellaneous Bits of Japanese Culture 1/3

Wednesday, August 15th, 2007

Putting scallops and sea snails on barbeques.

Gosh, I hate Facebook

Wednesday, August 8th, 2007

It’s all so Web 2.0 and fashionable. I have been trying to resist it for months now.

However, it does have a nice photo exporter from iPhoto and appears to accept an unlimited number of photos, so I’m going to use it to store my photos. Sorry for any suckers that therefore get sucked into Facebook because they want to look at them.

Business relevance? None really, but I’m going to pretend it does by mentioning that this tiny simple iPhoto exporter has made me want to use the whole Facebook ecosystem. Perhaps a tiny simple Symbian OS debugging tool will make lots of phone makers use Symbian OS in more of their phones?!!

Answer to my Eclipse native plug-in debugging prayers?

Tuesday, August 7th, 2007

This should allow me to step between Java code and native code when producing JNI Eclipse plug-ins. In theory. It’ll be really interesting to see if it works, next time I need to actually do that.