Desktop Development with Java

In my ongoing quest to find a long-term replacement for RealBasic (and preferably as many other random development tools and languages as possible) I’ve been investigating Python + wxPython (which seems to work pretty well but produces remarkably large, sluggish applications), Java + SWING (which, as you might expect of anything developed by Sun and built on top of AWT produces sluggish, ugly apps — on the Mac at any rate), and Java + SWT + JFace (which actually seems like it might not suck, but for which precious little documentation seems to be available outside of an insanely expensive — and somewhat outdated — book).

One of the big downsides of anything involving Eclipse is that there seems to be an “easy 35 step installation process”. WTF? It’s like Lotus Notes all over again. Aside from that, Eclipse is a remarkably fine piece of software, and since it’s built on top of SWT, indeed SWT’s raison d’être, this seems to me to give it front-runner status. Indeed, given Netbeans as an exemplar of SWING development, this is one more reason to avoid SWING like the plague.)

Eclipse’s features make Java’s horribleness tolerable… indeed almost not horrible at all. Hover over a classname and there’s its documentation (in useful form). Declare an object of a class you haven’t imported and it will offer to insert the appropriate line of code for you.  Seriously good autocomplete. Seriously good compiler feedback (errors are flagged inline like spelling mistakes in a word-processor). You still need to look at the resulting code, but really not bad at all. For all of Python’s virtues, it cannot offer anything like that kind of programming experience right now.

Realbasic Alternatives

So, you want to develop apps quickly and easily but you are sick of Realbasic’s subscription model, or are annoyed by the forced switch to “Studio”. What to do? The latest news from Real Software has me thinking (again) about what I should do rather than continue to use Realbasic, and here are the alternatives I’ve come up with.

XCode — Free (Mac). On the downside, you can’t deploy on Windows (or Linux, if you care). On the upside, actually supports all Mac UI widgets properly, has far fewer stupid bugs, can actually load images with alpha channels, produces apps which you don’t need to be ashamed were created with Realbasic, allows you to deploy on the iPhone, and actually has pretty good tools for building web apps.

Cocotron looks to offer the Holy Grail of cross-platform development. Develop your apps in XCode and Cocoa and simply compile to Windows. I haven’t tried it yet, but it certainly seems intriguing and it appears to be under pretty active development.

Unity — $199 and up (Mac/Win as of 2.5, also iPhone/Wii). On the downside, doesn’t produce standard desktop apps. On the upside, very good for game and multimedia development (far better than Realbasic); generally superior performance to Realbasic; your programs can run in web browsers, the iPhone, and even the Wii; one license allows you to code on both Mac and Windows; actually has a superior GUI for OO development than Realbasic (once you get your head around it); supports three languages (Boo, C#, and JavaScript), each of which is an easy move for RB coders; no subscription model.

BlitzMax — $80 (Mac/Win/Linux). Very fast, modern BASIC with full cross-platform GUI support (available as a $30 add-on). Designed with 2D game development in mind, but perfectly capable of being used for app development. Downside: bare-bones IDE which does not include visual GUI tools or handle bindings between UI elements, events, properties, and code. Visual GUI tools (which do do these things) are available from third parties.

Python — Free (Mac/Win/Linux). Python is not only a ridiculously nice language, it’s also hip and cool and highly marketable. It’s kind of like JavaScript without the negative associations (but also without the ability to run in Web browsers). For GUI development, Tkinter looks interesting and PythonCard actually seems pretty compelling.

Java — Mostly Free (Mac/Win/Linux). Well, Eclipse is pretty nice, and I assume that by now it’s probably possible to produce vaguely decent UIs. I’ll need to look into this. Java is definitely not my favorite language, but it’s very marketable.

Netbeans — Free (Mac/Win/Linux). Free and open source IDE and runtime that lets you code in Java, JavaScript, Ruby, PHP, C/C++, and (shortly) Python. OK that sounds too good to be true. (I downloaded 6.5 and messed with it a bit. It falls under the category “I guess it probably seems pretty neat if you think Solaris is pleasant to use”, so — yeah — too good to be true.)

Web-based — Mostly Free, and some amazingly good, cheap stuff (e.g. Coda). On the downside, you can’t deploy standalone desktop apps via the web. Oh wait, you can. And you are living with whatever functionality you get from browsers (i.e. JavaScript, canvas, Flash, etc.). On the upside, web apps are where the action is. And there’s always Cappuccino and Atlas.

Adobe AIR — Free? (Mac/Win/Linux). Essentially a runtime that bundles Webkit, Flash, and other functionality, allowing you to build web apps that run like applications (including being able to avoid the usual sandbox restrictions). Of course, you’re essentially trapped inside the functionality provided by Webkit (and Flash, if you choose to use it).

Flex Builder Standard 3 — $249 (Mac/Win). On the downside, produces non-standard (Flash-like) UIs. On the upside, your software runs inside browsers (OK, not on iPhones, but neither does Realbasic); you don’t pay a subscription, and Adobe will provide free bug-fixes even for outdated versions of its software. Also, Flash-like UIs are all the rage anyway, and at least you’ll have a consistent user experience on all platforms. Oh, and ActionScript 3 is not going to be hard to learn for Realbasic developers.

Runtime Revolution — $49/$249/$499 (Mac/Win/Linux). On the downside, produces non-standard (sometimes ugly) UIs, and the language is a bit outmoded (although nice in many ways). On the upside, there’s no subscription model.

Qt SDK — Free or Expensive (Mac/Win/Linux). Built on top of the well-known Qt UI library. On the down side, requires you to code in C++. On the upside, produces robust, cross-platform apps. Builds skills that get you better paid jobs than RB experience. The free version is only useful for producing free apps, but that’s a lot of what I do with Realbasic. Correction: the free Qt version can be used for proprietary apps. (And frankly, no-one cares if you open-source a RB Project.)

Lazarus — Free (Mac/Win/Linux). Very interesting looking open source recreation of Delphi. If it works it could be fabulous — I love Object Pascal (although it’s hardly a popular language these days). It appears to let you compile both native Cocoa and X11 apps on OS X.

It’s worth noting that it’s not easy to replace Realbasic for cross-platform development. I can whip up a cross-platform utility with a native UI in Realbasic with almost ridiculous ease, and that’s simply not true for any of these options.

I’ll probably end up keeping an active Realbasic license for as long as I make money from contract programming with it. But, I’ll be moving all the projects I can move, along with any new projects, away from Realbasic ASAP. RiddleMeThis, for example, may well be rewritten using web technology, with desktop deployment via Adobe AIR or something similar.

Other Useful Links

Wikipedia’s compilation of RAD tools

Microsoft’s “Express” (i.e. free) development tools

Unity 2.0

Unity 2 has been out for a month or so now, and I’ve gotten my head around most of the additions (everything except multiplayer, basically). It’s a bit of a mixed bag (I’ll probably write a more thorough review for MacApper) but the nutshell version is this:

The new UI support is at once great (in that it lets you do all the stuff you really need to do fairly easily) and disappointing (in that the architecture is pretty much a horrible kludge). In essence the UI code is all stateless procedural drawing code versus a library of widgets. There’s no proper event support, widgets don’t have an independent existence or retain state. (E.g. you can’t ask a button if the mouse is currently over it.)

The new UI code works, is pretty, and is fairly easy to use, but it’s kind of architecturally lame and the code to support a UI is unnecessarily complex and high maintenance, or you need to write your own state-ful abstraction layer. By comparison, Director offered two UI options — a clunky looking, incomplete, but otherwise functional set of widgets for basic interaction which could be dragged onto the timeline, and a platform-native plugin that let you build “proper” windows with standard controls, but which was completely un-integrated with the rest of your app.

So, on the good side, the new UI code works, looks good, and is integrated fairly well with everything else (cosmetically) … i.e. your UI widgets don’t look 10 years out of date or live in their own Window. On the bad side, writing UI code is unnecessarily tedious and you’ll end up reinventing all kinds of wheels… But it does seem like you could write a bunch of wrapper code for all this that could make it not suck (whereas there was simply no way to fix Director’s UI issues).

Enough on that topic.

The terrain engine is similarly great (the terrain drawing tools are simply awesome, the results look fabulous, and it’s all very easy to use) and incomplete (terrain doesn’t work with blob shadows, the terrain shader is kind of limited, and the lightmapper won’t take into account trees or other geometry in the scene, so while your terrain can cast shadows onto itself, it can’t receive shadows from objects, such as buildings, placed on it.

Several notable deficiencies in Unity remain: undo is still unreliable at best; UnityScript is still not JavaScript (which would be OK if the differences from JavaScript were properly documented, but they’re not); and there’s still no set-breakpoint-and-step-style debugger.

Note: Unity 2.1 addresses all the concerns discussed here except for the architecture of the UI system.