The cloudy future of relational databases

Cloud computing is the big new thing. The fate of the formerly ubiquitous relational database, on the other hand, is uncertain. There are many ways for a developer to deploy his application to the "cloud", whatever that might mean. On the other hand, the various cloud vendors do not necessarily have a database story to tell, or if they do that story isn't necessarily a good one. As a result, deploying a traditional database-backed application to the cloud may be difficult.

One story I have heard is to simply opt out of using a relational database. You would use some "NoSQL" persistence technology, such as SimpleDB on Amazon or Google's datastore. Such solutions have their advantages in terms of performance, scalability and ease of mapping to objects. If you just want to store dumb data objects, that may be all you need. But there are situations where the traditional RDBMS is more appropriate. If you have a data-centric view of your problem domain, where the data is ontologically independent of the application and can outlive the application, where you want the database to guarantee certain transactional and integrity rules, where you want to do lots of ad-hoc querying ... you might just want an RDBMS. My worry is that for many cloud platforms, you may not have that option.

For the platform as a service (PaaS) sort of cloud, where you may not even have filesystem access, setting up your own database server will not be an option. Even where the vendor provides a database service, your choice remains limited to that one service. For example, if you use Azure you can only use SQL Server. The infrastructure as a service (IaaS) sort of cloud will generally give you that freedom, but it may have limitations. Generally, IaaS vendors like Amazon offer:

• a compute service: a virtual machine with local filesystem storage. Small, fast storage.
• a storage service: an API to read/write data on the cloud. Big, slow storage. 

So you have a choice of small, fast storage (EC2) or big, slow storage (S3). Trouble is, a database server really wants big and fast storage.

At this point, I think the reader of this blog may want to slap me on the head and point out that yes, Amazon tells a perfectly good database story. In fact, it must have at least half a dozen stories to tell. You can use their MySQL service, put up an Oracle AMI or stand up your own database server: there are lots of choices both from Amazon and third parties. There are choices partly because Amazon's EC2 can use elastic block storage (EBS). This is a filesystem which is both big and fast, especially if you set up several EBS volumes in a RAID configuration. I noticed that my former colleague Chip recently blogged about his success deploying database-backed applications to Amazon's cloud.

OK, so you have lots of database choices if you go with the Amazon cloud. But only Amazon. I have been talking to another cloud IaaS vendor without a database story, being stuck with the fast/small vs slow/big dichotomy. With other vendors, it seems, you either have just one choice of RDBMS or you simply cannot get a production-ready RDBMS in the cloud. Did I miss an another option or two? You tell me.

Hibernate formulas do not like subselects

Hibernate formulas and the subselect fetch strategy are currently incompatible. There is already a bug associated with it: HHH-1400. I am linking the bug at the beginning because blog posts like this have a limited shelf life. If you came across this post from Google, it is possible that this note is already obsoleted by a bug fix. I have little hope of this happening very soon right now, though, seeing that HHH-1400 was opened almost 4 years ago.

What's a formula? A formula is a Hibernate feature that lets you map a property to an SQL expression rather than a table column. Hibernate would automatically compute the value of the property for you each time you load an entity. A formula in annotation form looks like the following:

@Formula("(select count(*) from foo where ...)")
public Integer getFooCount() { return fooCount; }

I think it is an elegant feature. Unfortunately,  this feature seems to interfere with the subselect fetch strategy.

Why do subselects matter? The subselect fetch mode is an important tool to deal with the n+1 select problem when loading entities with one-to-many relations. Suppose we had an entity called Parent with a collection of Child entities. Suppose also we load n Parents and eventually want to iterate over each element in Parent.children. The typical Hibernate-generated SQL with a lazy-loaded collection would look something like:

select * from Parent where ...;
select * from Child c where c.parent_id=?;
select * from Child c where c.parent_id=?;
select * from Child c where c.parent_id=?;
...

In other words, we would have n+1 select statements, which is bad if n is large. We could do a join between Parent and Child to eagerly load the collection, but this only works with one collection. If Parent has multiple collections, a join-fetch of multiple collections would lead to a Cartesian product, retrieving a prohibitively large number of rows. This is where the subselect fetch strategy comes in. If mapped to use the SUBSELECT fetch strategy, we would only need two select statements, with the first one's where clause reused in the second:

select * from Parent where ...;
select * from Child c where c.parent_id in 
   (select id from Parent where ...);

Unfortunately, if you had annotated a property with a @Formula, Hibernate will mangle the SQL, leading to an SQL parse error:

select * from Parent where ...;
select * from Child c where c.parent_id in 
   (select ...) as formula0_1_, ...;

If you really need to use subselect fetches, you'll have to find an alternative to @Formula for all its elegance. Possible solutions:

• Compute the properties with separate queries only as needed. This is tricky if you frequently need those computed properties.
• Sort of "denormalize" (I'm sure I'm misusing that term here) by persisting the computed values in the table. This works if the computed values rarely change, but is a problem otherwise.
• Have the DB manage the computed values using views. Eyal Lupu has a great blog entry on how to do this. Obviously, this only works if your database supports views, and requires DB-specific SQL.
  

BlackBerry development: big things happening

The buzz in mobile development seems to be on other platforms. People outside of the BlackBerry community probably haven't been paying much attention, but there has been some major announcements in the area of BlackBerry development. These announcements, coinciding with the recently concluded BlackBerry Developer Conference, show that RIM is actively responding to its competition on several fronts. RIM's BlackBerry Developer's Blog has been covering these developments faithfully, so go there if you want to read from the official source. Here, I will go over what seem the most significant announcements to me as a developer.

XDepend (now JArchitect): managing code complexity

At a NEJUG presentation I attended a while back, the presenter used a vivid metaphor of taming the "complexity dragon", meaning the tendency of a code base to become brittle and complex as it grows in size. This dragon can cripple even competent development teams: productivity plunges because each code change triggers bugs in other obscure parts of the program. That said, the presenter hastened to clarify that he meant European dragons, since apparently dragons aren't necessarily evil creatures in other cultures.

A major contributor to large code bases becoming brittle is the dependencies between pieces of code. If class A uses class B, then A depends on B and a change in B may cause A to malfunction. That's not too bad if there are only 2 classes, but becomes impossible to track manually as code bulks up. The difficulty is that complexity, as measured by the number of dependencies between units of code, does not merely increase linearly with the quantity of code. In fact, the function is quadratic and the curve is parabolic.

This is why architecture-minded folks try to impose certain code architectures: to tame -- though never quite slay -- the dreaded complexity dragon. When architectural layers are enforced, code in certain layers cannot directly use -- and depend on -- code in certain layers, and generally dependencies only go in one direction. These boundaries break up the n^2 function. Or they may try to eliminate cyclic dependencies: cycles couple code units together, preventing them from being tested or used in isolation. Or they may use various code metrics to discover potential trouble spots.

This may sound admirable, but for any code base big enough for such architectural enforcement to be worthwhile, I can't imagine doing this exploration by hand. I'd need a tool. Fortunately, there seems to be quite a number of tools out there. The folks responsible for XDepend (now called JArchitect) were kind enough to give me a copy to review. I don't pretend to be any kind of authority on this topic, nor even come close to mastering this tool. But I think this tool is cool enough for me to share a few of its features.

Dependency matrix

On conciseness

I meant to write this thought for a while, but a recent blog post about implementing the Quicksort algorithm in Scala finally prompted me to write this. As a refresher, here is pseudocode from the Wikipedia entry on quicksort that illustrates a simple version of the algorithm.

function sort(array) // pseudocode from Wikipedia
    var list less, greater
    if length(array) ≤ 1 return array  
    select a pivot value pivot from array
    for each x in array
        if x < pivot then append x to less
        if x > pivot then append x to greater
    return concatenate(sort(less), pivot, sort(greater))

From the Groovy in Action book, here is a Groovy implementation. It works on a List of objects that implement the compareTo() method. The findAll method returns elements from the list that satisfy the given expression, with "it" representing the object in the list.

def sort(list) { 
    if (!list) return list
    def pivot = list[0]
    def less    = list.findAll {it < pivot}
    def same    = list.findAll {it == pivot}
    def greater = list.findAll {it > pivot}
    sort(less) + same + sort(greater)
}

What I find significant about this example is that the real-code, working implementation of an algorithm is every bit as concise and readable as the pseudocode used to explain the algorithm.

From the same book, here is a Java implementation:

    public static void qsort(Comparable[] c,int start,int end){
        if(end <= start) return;
        Comparable comp = c[start];
        int i = start,j = end + 1;
        for(;;){
            do i++; while(i<end && c[i].compareTo(comp)<0);
            do j--; while(j>start && c[j].compareTo(comp)>0);
            if(j <= i)   break;
            Comparable tmp = c[i];
            c[i] = c[j];
            c[j] = tmp;
        }
        c[start] = c[j];
        c[j] = comp;
        qsort(c,start,j-1);
        qsort(c,j+1,end);
    }

    public static void qsort(Comparable[] c){
        qsort(c,0,c.length-1);
    }

This contrast is not completely fair to Java, since this Java version does an in-place sort of the array. Nevertheless, I think it illustrates the look of typical Java code.

Clearly, the newer JVM languages like Groovy allow for concise code. But I suggest that the real value of such conciseness comes not from reduced typing, but from the improved readability of the resulting code. You will read a piece of source code far more often than you will write it. It helps enormously -- whether you are enhancing or debugging code -- if you can comprehend meaning of the code immediately. In this example, the Groovy code's meaning comes through as clearly as the pseudocode. By contrast, the Java code is cluttered with the tedious mechanics of achieving the desired result. Here, the Groovy code emphasizes the what -- the meaning -- while the Java code emphasizes the how -- the process.

Of course, if performance is the primary consideration then it makes sense to write less concise code. See, for example, the various implementations of Quicksort in java.util.Arrays. And I am glad that we have performance-tuned libraries. But most application code has little impact on overall application performance, and for such code I suggest that the readability and conciseness that comes from the expressiveness of languages like Groovy is a big win.

Polymorphic one to many relationships in Hibernate

These are some notes on mapping a polymorphic one-to-many relationship in Hibernate. I want to give credit to Clark Updike's blog for providing most of the answers. These notes reflect my own particular bias and needs. I wrote the code samples below in Groovy for ease of prototyping (they actually work). They should be close enough to Java to serve as concise pseudo code, even if you don't know Groovy. They aren't my real production entity classes, of course, but these simple classes are sufficient to illustrate the issues I grappled with.

NESS 2009: Remembering Java platform security

Java platform security is something we normally don't worry about when doing enterprise Java development. Originally designed as a sandbox for applets, Java platform security has evolved into a fine-grained access control architecture for all Java programs. Even so, it remains focused on protecting the host system from the Java application. The Java developer is more concerned about protecting the Java application from malicious users, or protecting users from each other.

So if Java platform security secures the host system, and we are concerned with securing our application, is the former useless? At the New England Software Symposium, I attended Ted Nugent's two presentations on Java platform security, and he argues that it is indeed useful. On the other hand, it is disabled by default, for ordinary Java applications as well as webapps running on Tomcat. This blog entry is based on Ted's presentation.

NESS 2009: multithreading and the Java memory model

At the New England Software Symposium, I attended Brian Goetz's session called "The Java Memory Model". When I saw the phrase "memory model" in the title I thought it would be about garbage collection, memory allocation and memory types. Instead, it is really about multithreading. The difference is that this presentation focuses on visibility, not locking or atomicity. This is my attempt to summarize his talk.

On the lightness of Spring

Shortly after I blogged about the direction of Spring, I came across a blog entry asking "Is Spring still lightweight?" The resulting DZone discussion is spirited, but last I checked it nobody actually defined what it means to be lightweight. That seems unfortunate. If the Spring folks are no longer right in their claim to be lightweight, we should at least have a falsifiable proposition. Way back in 2004, Rod Johnson in his book "J2EE Development without EJB" defined the characteristics of a lightweight container (summary of chapter 6):

• Non-invasiveness: imposing minimal special requirements on application objects run within it
• Quick start up
• Lack of any special deployment steps
• Light footprint, enabling it to run in any architectural tier
• Ability to manage objects of any granularity, including fine-grained objects that cannot be modelled as EJBs.

Now when we look at SpringSource's mission statement today concerning the Spring framework, we see pretty much the same ideas. They no longer talk about a light footprint, though the spring.jar super-bundle in the 2.5.6 release is still under 3 MB. While you can get the footprint much smaller by using the individual Spring modules (spring-core.jar, spring-context.jar etc), I don't think the footprint is an issue.

What Spring really stands for is the non-invasiveness: the framework helped make POJO development trendy. We have Spring to thank for the new status quo in enterprise Java, where we don't have to inherit from mandatory classes, write unnecessary boilerplate or otherwise deal with much accidental complexity. Spring's idea of lightweight containers --along with Hibernate -- gave us dependency injection, AOP, declarative transactions and POJO object persistence. When we think of Spring as being lightweight, we really mean its adherence to the principles I quoted above.

There are some aspects of Spring that I find unnecessarily tedious, verbose and complex. Sometimes, I am tempted to apply the word "heavyweight" to Spring. And it is true that SpringSource has become a big company with a confusing proliferation of commercial products. But I would not deny the title of "lightweight" to the core Spring framework according to principles defined by Spring, nor would I begrudge a measure of gratitude to a programming paradigm that transformed an industry.

KBLauncher for BlackBerry has launched

I released my latest BlackBerry app, KBLauncher, last week. So far, the major BlackBerry blogs that have mentioned KBLauncher are CrackBerry, BerryReview and BlackBerryItalia. I also partnered with BerryReview for a giveaway program. All 50 copies of KBLauncher were snapped up within the half hour. People do love their freebies.

KBLauncher is an app that I have been wanting to write for a long time. I have a personal policy of writing only apps that I would want on my own BlackBerry. KBLauncher is an app launcher/switcher that gets its inspiration from a number of familiar desktop applications, such as Bash, ENSO and the IDEA/Eclipse class name lookup. It addresses the too-many-apps problem in a way that I find both efficient and intuitive.

NESS 2009: The Coming Spring

One of the sessions I attended at the recent New England Software Symposium is the one on new features in Spring 3. This covers Spring Core functionality. This session got my attention because the presenter was Craig Walls, who wrote Spring in Action. The main features he covered were:

• Spring Expression Language (SpEL)
• Spring MVC annotations (@PathVariable, @RequestHeader, @CookieValue, @RequestParam defaults), some to support REST.
• jsp tag to generate context-sensitive URL
• Declarative validation of some sort that may or may not make it
• Etag support
• HiddenHttpMethodFilter (more Spring MVC REST support)
• ContentNegotiatingViewResolver
• RestTemplate
• JavaConfig (Java-based alternative to XML wiring). This has been around for a while, but is being bundled in Spring 3. 
• Object-to-XML mapping from Spring-WS
• Java 5 support

New BlackBerry app in beta: KBLauncher

My latest BlackBerry app KBLauncher is finally undergoing beta testing. KBLauncher is an application launcher and switcher. My idea is that a keyboard-intensive device like a BlackBerry would have users that prefer to use the keyboard rather than scroll endlessly with the trackball to find an app to launch. Oh, and I think the UI is pretty slick too.

This has taken longer than I expected. Part of this of course is the nature of a hobby: I can -- and did -- put the project aside when more important issues came up. But the problem is also technical: the vast BlackBerry installed base comes at a cost, and that cost is the large number of models and operating system releases out in the field. The API for launching apps does not behave consistently across releases. Something that was possible in OS 4.2 stopped working in 4.5, and the workaround in 4.5 does not work in OS 4.6. And a bug in 4.6.0 was fixed in 4.6.1. You get the idea. I spent a lot of quality time with various simulators, and while they are a great development tool, they have their limits. Unfortunately, as a hobbyist I don't have full time QA staff nor a stockpile of test equipment.

This is why this beta period is critical for me. It's not a marketing exercise. I am hoping to find a sufficient number of beta testers who care enough that KBLauncher works to report bugs and collaborate with me.  KBLauncher will likely not be perfect, but I hope to make it work fine in the most common cases.

Going to the New England Software Symposium

I will be attending the New England Software Symposium this weekend, and I am really looking forward to it. Unlike most tech conferences I've been to, this one is actually held over a weekend. The advantage to this is that it allows participants -- both attendees and speakers -- to participate without sacrificing productive time. I suspect this made it easier for me to get approval from my boss. I sacrifice family and personal time, but the sessions look really valuable. I hope to blog a bit about the topics discussed there.

The App World torture continues

I have a handful of BlackBerry apps published on RIM's BlackBerry App World, the "official" app store for BlackBerry phones. Recently, I have been getting emails daily from users who have trouble downloading my applications. The problem is actually with the on-phone App World application, which can get stuck trying to download an application. App World does not make it easy to figure out who to contact for help with the store, so its users click on the tech support link for the individual apps instead. Those tech support requests, of course, go to the app publishers such as myself, who are in no position to fix App World problems.

It has been a rough ride for many publishers of apps on RIM's store. In their rush to match Apple's App Store, RIM released App World store software that remains buggy and immature. When it first opened in April, App World 1.0 had a glaring bug: for software that sold as try&buy, the store would either deliver paid versions to people who downloaded the free trial version, or delivered the free trial version to people who paid for the full version. This bug was only fixed in App World 1.1, released months later at the end of July.

App World is not the only option for publishers of BlackBerry software. Stores like Mobihand and Handango have been around for years, and you can publish for free. It is a bit of a shame, really: these older stores are in many ways more mature. For example, Mobihand's vendor portal lets you issue coupon codes, set promotional pricing, set prices as low as $0.99 and issue refunds. None of this is possible with App World. So why do I publish on App World? The reality is that for all its problems, App World still has the highest sales volume among the 3 BlackBerry app stores I am publishing on. It probably works fine for most people most of the time. Unfortunately, I have to deal with the exceptions.

Logging: should I wrap?

Once upon a time, there was a de facto logging standard, log4j. Then Sun decided to confuse matters by introducing another -- and many say inferior -- logging API in JDK 1.4. Some people responded with Jakarta Commons Logging (JCL), a wrapper that abstracts away these two APIs. Some other people decided that JCL was awful, and wrote SLF4J, a wrapper that abstracts away the first two APIs and JCL. There are also other logging implementations like Logback and x4juli, but fortunately these natively implement the existing APIs so they don't multiply the confusion.

If you start work on an existing project, I suppose you'd use whatever logging API is already in use. If on the other hand you are lucky enough to start a brand new project, you have to choose from a number of logging APIs:

• log4j
• JDK Logging
• JCL
• SLF4J

The conventional wisdom is that if you are writing a component or library, you'd likely choose one of the wrapper APIs (JCL or SLF4J) since you won't have control over what logging implementation the actual app will use. On the other hand, the conventional wisdom continues, if you are working on a standalone application you might as well code directly to the native APIs since you can pick the logging engine and are unlikely to switch. Even SLF4J's docs say that you needn't bother with SLF4J for standalone applications.

I have joined projects that build J2EE applications almost from scratch, so we got to pick the logging API. My initial inclination was the direct approach: we'd code directly to log4j. After all, why add an unnecessary abstraction? In one project, we ended up using SLF4J, even though we had no intention of switching logging engines. Why? Well, it turns out that SLF4J has a useful feature that log4j does not: parameterized logging. Ordinary logging messages incur the overhead of building the log message even if the message will not be logged at the current log level:

logger.debug("Value of obj#" + i + " = " + obj.toString());

All that work will be wasted if you are logging at the INFO level. The performance penalty could be significant if obj.toString() is particularly heavy. You could wrap that line in an "if (logger.isDebugEnabled()) {...}" block, but that adds clutter. SLF4J lets you defer evaluation of any String conversions until the line is actually written:

logger.debug("Value of obj#{} = {}", i, obj);

Does this minor convenience justify throwing in yet another 3rd party library? We did not need to answer that question. In a substantial app, there is no extra overhead. Quite likely, as in our case, the third party libraries you use will require JCL (e.g., Spring) and SLF4J (e.g., Hibernate) anyway. It's up to you to choose the API for your own logging. For us, SLF4J came along for the ride, gave us the parameterized expressions and still exposed powerful features like Mapped Diagnostic Context (MDC). Where is the downside?

In another project, we coded straight to the log4j API. This project was coded almost entirely in Groovy. In Groovy, we get lazy evaluation for free, so SLF4J offered no API benefits. The Groovy logging code below lazily evaluates its parameters regardless of logging implementation, and more concisely than SLF4J:

logger.debug "Value of obj#${i} = ${obj}"

The invisible applet

How about deploying a Java applet that you can't see?

It's no secret that Java has not been successful as a client-side platform. We often use HTML/Ajax or Flash/Flex on the browser and Java on the server. Maintaining 2 distinct platforms has a major disadvantage: it's hard to share code.


Imagine this scenario: you have built a beautiful UI for the browser, and like any respectable shop you maintain your business logic in Java on the server. Suppose you design a screen where your user can do what-if analysis by fiddling with sliders and watching pretty graphs and numbers change in real time. Unfortunately, the code that does all that complex computation is in Java on your server. Your options:

• Write a parallel ActionScript codebase that duplicates the Java logic. You have the burden of keeping both codebases correct and in sync, and there could be subtle inconsistencies in the resulting logic.
• Keep the logic on the server, and execute the computation there. Every time the user jiggles a slider, the Flex app bundles all the relevant data and transmits it to the server. The server in turn does the computation and sends back the results. 

My reaction to these alternatives is "yuck". I would have to pay a cost in either development burden or network traffic and performance. This would be one example where a Java "engine" on the browser might be exactly what you need, even if it does no UI duty.

Implementing an invisible Java applet to provide services to your UI code via JavaScript is surprisingly easy. Your applet tag needs a MAYSCRIPT attribute to enable the Java-to-JavaScript interface:

<applet ...="" height="0" id="myapplet" mayscript="" width="0">
...
</applet>

Note that this is a 1x1 box. If the applet is zero size or wrapped in a hidden div, the applet won't start. Once your applet is running you can call public methods in your Applet class directly from JavaScript:

document.getElementById('myapplet').myJavaMethod();

Conversely, you can call your JavaScript methods from within your applet. Since JavaScript is single-threaded, for longer operations you might want to use an asynchronous call/callback pattern where the Java code would spawn a separate thread that returns the result by way of a callback into your JavaScript code. You can do it like this:

JSObject.getWindow(applet).call("myJsMethod", new Object[] { arg });

One odd behavior I found when calling Java methods from JavaScript is that even when the applet is signed, the Java code executes in a thread with reduced privileges. Jumping onto the Swing event thread will gain you the signed privileges, but now you are tying up the event thread. If you want privileged, multithreaded execution, you could do something like this (looks bizarre, I know):

SwingUtilities.invokeLater(new Runnable() {
   public void run() {
      new Thread() {
         public void run() {
            doWhatIReallyWantToDo(); 
         } 
      }.start(); 
   } 
});

That seems easy enough, but there still aren't many situations that justify using Java on the client side. The dominance and ubiquity of Ajax and Flash on the browser means you need a really good reason to burden your users with the Java runtime. Deployment remains Java's big weakness on the client. Some possible reasons:

• To share logic on both client and server.
• To use functionality from some complex third-party library on the client side. 
• Get multithreaded, fast execution.
• Need for extensive filesystem access.
• Some combination of the above. 

Why BlackBerry?

As I said before, I write BlackBerry software. It's certainly not the most trendy platform. At a gathering of mobile developers, I saw from a show of hands that attention is going to more glamorous platforms like the iPhone and Android. So why BlackBerry? BlackBerry fans can articulate numerous reasons why they like their phones. As a developer, I have my own reasons, some of them quite subjective. I'm going to list a few of them in this post.

It's Java

The BlackBerry development platform is Java. It is the standard Java ME (or J2ME) MIDP 2.0/CLDC 1.1 plus the usual JSR extensions for multimedia, PIM, filesystem, location etc. RIM also adds additional APIs for BlackBerry-specific functionality. As an experienced Java developer looking for a hobby, Java ME seemed like the natural progression for me into mobile development. Development in Java ME reminds me of the early days of JDK 1.1 with a simple class library, before J2EE, generics and other features piled complexity into the Java ecosystem. While I certainly appreciate the richness of the Java platform, the sheer minimalism of Java on the phone is also fun in its own way.

While I called it minimalist, Java on the BlackBerry remains Java. It is a "civilized" language with an ample class library and garbage collection. It lets me concentrate more on writing the app itself rather than tedious plumbing like memory management.

It fixes the signing problem

While portable MIDlet development sounds like a fine idea, the MIDlet signing problem cripples Java ME in practice. The basic problem is that the Java security model severely restricts what your Java app can do on the phone. Security is a good thing in itself, except that it's hard to get out of that security sandbox. And escape the security sandbox you must, if you want to do anything substantial like access the filesystem or the network. 

To sign a Java ME app, you need to buy a certificate from an authority like Verisign for a couple hundred bucks. Actually, you will need to buy from several signing authorities because different phones support different authorities. On top of that, the networks may apply their own layer of restrictions and certification process. This adds up to a lot of money. T-Mobile (through their testing/certification partner True North) charges $195 or $250 per build, on top of a $500 deposit. So to release a bug fix on T-Mobile alone will cost you $250, assuming it passes certification the first time. This heavy burden is likely one reason why Java ME apps seem to consist largely of games and other insubstantial apps.

The BlackBerry world is simpler. You pay just $20 to RIM to register as a developer, and that gets you unlimited code signing. You can continue to write Java ME code or use BlackBerry-specific APIs, and your signed app can now access restricted APIs. Of course, this gives you restricted API access only on BlackBerries, but with 20 to 30 million users out there, it is a big user base.

It's open

Unlike the iPhone, BlackBerries are open platforms in that you can install any software you like on your phone. Like your PC, you can install apps from a number of different web sites or straight from your PC. While RIM's App World received a lot of attention lately as the BlackBerry counterpart to Apple's App Store, it is in fact one of numerous app stores available to a BlackBerry owner. On my part, I can choose to publish my software at one of numerous app stores, or even directly from my own website. My ability to write and publish software is not limited by the whims of any one app store. 

It's cheap

This is where my role as a phone user and a developer coincide. As a phone user, I like the fact that you don't need a $20-$30 data plan to use a BlackBerry. Personally, I don't want the crackberry lifestyle where I would pounce on my phone every time it buzzes or blinks red (red LED means message waiting). I also have WiFi access most of the time, so a WiFi-equipped BlackBerry like my Curve 8320 does not really need mobile data. To sign up for an iPhone or an Android phone means that I need a data plan for the next 2 years. That adds up to hundreds of dollars: much more than the original cost of the phone.

As a developer, I appreciate that all the tools I need are free: Eclipse and RIM's plugin, phone simulators and documentation. All I really needed is $20 for the code signing privilege. It is true that RIM's App World requires $200 up front to be listed, but competing stores like MobiHand and Handango will let you publish your app for free. 

It's small

While Apple likes to boast of an enormous selection of apps, it's not always a good thing for a software publisher: it's hard to get noticed. By contrast, the number of apps available for BlackBerry is still manageable. You can still find the usual apps that make rude body noises, but you can also reasonably expect to browse the entire collection without getting lost. I met a couple of entrepreneurs at the mobile gathering I mentioned earlier, who said that they wanted to target BlackBerry as their preferred mobile platform precisely because the iPhone market is so saturated. Another software publisher mentioned that their downloads break down evenly (50:50) between iPhone and BlackBerry. The old cliche still holds that you can be a big fish in a small pond.

Reality check

I don't mean to imply that the BlackBerry platform is perfect. After all, there is a reason why so much developer attention is going to other platforms. And while I have only published a few modest applications, I have had a fair number of frustrations with the platform's limitations. All I wanted to do with this post is to point out a few reasons why I like it.

First post!

Welcome to my development blog. I am a software engineer working in the Boston area. By day, I write software based on a conventional enterprise Java stack: Spring, Hibernate, Tomcat and a typical SQL database server on Linux. My tools should be familiar to anyone who works in the Java ecosystem: Eclipse, Ant and other Apache stuff, Log4j, JUnit, Hudson etc. After hours, I toss all those things aside (except Eclipse) and write BlackBerry software. On this blog, I will cover topics pertaining to these two separate development activities.