Java culture rant

As some of you may know, over the last year or so I’ve been spending more time with larger and larger Java-based server-side projects (including Quick Bit Notes, Twitmart, Litetext, and iSpykee). In this process, I’ve had to “catch up” to the Java state-of-the-art and get reacquainted with the Java culture.

Much of this has come with the great patience of my friend Mark Petrovic who has helped me immensely in this endeavor. It has been an overall very positive experience, to the point that Java is now my first choice starting point for server-side and web-app projects.

So here’s the rant:

What is it with Java tool developers that they like to “improve” their APIs in non-backwards compatible ways on a semi-regular basis?

Perhaps I’ve just been “lucky” but I’ve experienced this with many of the key packages I’m using, such as Jetty, Twitter4J, and Lucene.  It’s almost like it’s part of the culture to break things, just to shake things up.  Maybe it’s a “purity” thing and they always think their API needs to be cleaner and the only way to get there is to break it (again).

One of the biggest hassles that come with this culture is that it makes it really hard to come up to speed on a tool because you have to also study the full history of it, scattered across countless message boards, blogs, and websites (oh my!).  When you run across examples showing use of the package, they often only work with the specific version of the package/tool from some point in the past. Of course these examples seldom state which version they were written for nor are they updated to bring them current to the latest version. Coming out of the blue, being new to one of these packages, it’s really hard to tell when the package diverged and in what way the rules changed.

It seems like every Java tool developer thinks their users are, or should be, spending every waking minute on their specific development-talk forum.

Is it just me? Am I really the only one who struggles with this?

Subscribe to the comments for this post

Introducing Quick Bit Notes

I’ve released Quick Bit Notes (QBN) as an experiment in an unconventional method of person-to-person asynchronous communication. One person drops off a personal note for another person. That note is stored and presented in image form to the recipient. The actual text is never stored on QBN and never transferred over the wire when the recipient views the message.

QBN offers an alternative to complicated software, shared keys, and so on. All one needs to use the service is a browser and Gmail email account.

The service is running on Google App Engine for Java and is available as open-source on Google code: http://code.google.com/p/quickbitnotes. It should be relatively easy to deploy in your own App Engine appspot “slot” (refer to the README in the source archive).  If you want to be an SVN contributor to the code, just let me know.

In the process of developing Quick Bit Notes, I also created a small Java text-rendering library, based on NETpbm, that operates within the constraints of the Google App Engine JRE “white list”. This is a stand-alone JAR that can be used with other App Engine projects and is also available as open source on Google Code: http://code.google.com/p/litetext/

If you’ve followed along, by now you may see some applications of QBN for your own personal communications. If you’re not seeing it yet, QBN is probably not for you, so please don’t waste your time or mine spending time on it. And, please, dear god, don’t ask me questions like “what’s the distribution strategy” or tell me all the reasons why this service will never take off and how Twitter is so much better.

Subscribe to the comments for this post

Google App Engine adds Cron and Java

Google today announced that they will be supporting Java on their GAE cloud computing platform.  I signed up for the beta, but don’t know when/if I’ll be approved.

I also saw that the platform also now includes a cron mechanism to run scheduled “jobs”, see: http://code.google.com/appengine/docs/python/config/cron.html

This could change things.  It will be interesting to see how (if?) Amazon responds.

Subscribe to the comments for this post