A colleague recently detailed the trials and tribulations of a piece of infrastructure he is building in Java, and it seems that after beating his head against the wall, he won, but not without a few scars.

The thing that I have always loved about Java is its productiveness and expressiveness. I could write scads of code that worked well and correctly very quickly.

But Hal has indirectly pointed out a failure of Java that I think has been true since since its earliest days when I started using it in mid-1995:

Java is a lousy language for building infrastructure.

All of the techniques that Java exposes to operate on software itself are complex, slow, or bloaty, including reflection, proxies, class loading, weak references, bytecode manipulation, and compiler APIs. Since many of the pieces of WebLogic software I wrote had to deal with other user’s users’ code (Servlets, plug-ins, etc.), I spent a fair bit of time arm wrestling with Java, either trying to find the right technique, implementing a workaround, doing code generation, or chasing performance problems. When I transitioned to the chief architect role, the WebLogic team members experienced many of the same problems while writing EJB and RMI in Java (Sun’s RMI was in C). I also think much of the excitement over AOP was a result of people being fed up with using Java for system programming; AOP cut across these problems by bypassing or augmenting the language itself. Hal’s post tells me that the problem is still not solved.

This is not to say that I don’t think Java is a good language for server-side programming – after all, WebLogic pioneered Java on the server – but rather that the focus on “enterprise edition” has been on server-side application code, rather than infrastructure code.

IBM had a variant of PL/I called PL/S that they used internally for writing writing system software. We have editions of Java for the client, for enterprise apps, for mobile, and for real-time. Perhaps we need an edition of Java for infrastructure software.

Java Platform, Infrastructure Edition anyone?

Update: Here’s Hal’s response.

Please read: The Twitter Problem(s), too.

I’ve been arguing – again – that we need a SaaS universal messaging hub that can send and receive messages among a variety of different synchronous and asynchronous message services, such email, instant messaging, SMS, RSS, and Comet.

I say “again,” because the company I co-founded in 1999, Kenamea, was originally conceived as “big message switch in the cloud,” which, among other things, solved a problem that is finally being recognized: the enormous and unproductive polling that takes place in HTTP and Ajax.

At the time, nay-sayers claimed that HTTP servers would have no problem scaling with all the zillions of Ajax requests, and of course, they didn’t, not without tweaking. No lesser a publication than WebLogic Developer’s Journal [WEG], featured a “how-to” article, My friend, colleague, and Scala/Lift maven extraordinaire David Pollak even showed us how to do it “right,” using actors. So, yes, maybe the existing httpd’s scale, but not without serious architectural work. I suspect even more work will be forthcoming, as amount of Ajax traffic continues to increase.

The place where much of the unproductive polling is taking place right now is on social networking status feeds, and the web is aflame dealing with issues.

The answer to these kinds of problems is to reverse the protocol: instead of web services, applications, and RIAs polling web sites and web services for changed information, there needs to be a big message hub in the cloud that takes in all the updates from around the web and republishes it to all the other services that are interested in those updates.

Kenamea certain had capability to do this. Using the Kenamea message switch, server applications, such as Twitter, could send messages to client applications (e.g., IM, email, web browser) without the client having to continuously ask Twitter if there were any new Tweets (which is how it works today).

If I were going to do this right now, I would base the technology on the Tervela Tervela TMX Message Switch, which, out of the box, has the ability to switch 1.5 million messages per second, with the predictability and reliability necessary to run the trading system for the largest banking institutions out there. [Note: I am an Advisor to Tervela].

In conjunction with complex-event processing systems, message switching will have a revolutionary impact on the efficiency of distribution and delivery of real-time data around the web. You heard it hear first. Again.

I’m following up to my post of earlier today because I want to flush out another level of detail on what GAE, AWS, and competitors will eventually require. I’m tentatively calling these kinds of systems Widget Application Servers, because they will first and foremost be used as the back-end for widget-style applications that can be embedded on a page or on your desktop built for various platforms, such Facebook and OpenSocial apps; Google Gadgets, Yahoo! Widgets, and AOL’s Your Minis.

There are three key pieces to the Widget Application Server puzzle: application development, application management, and business management. Right now, one could cobble together all of the pieces from a variety of different Saas platforms, but I think the major players will emerge with an implementation of the whole thing.

Application Development support includes all of tools necessary for building and testing the application itself, including:

• multi-language support: py, php, ruby, js, maybe even Java
• libraries of reusable functionality
  • Social networking libraries for OpenSocial and Facebook
  • IMAP4/POP3/SMTP access libraries
  • parsers and generators for microformats (vCard/hCard, vCalendar, KML, etc.)
  • parsers and generators for interchange formats (XML, JSOn, Atom/RSS)
  • graph and chart generators, etc
  • bound controls for MVC-style design
    

• testing tools — unit, system, performance
• source code control/versioning — Git, svn
• authentication and user management — OpenID, X409
• data access — key/value indexes, tuplestores, relational systems, queueing systems
• internationalization
• session management

Application Management

• application life cycle management
• content management
• load balancing
• backup and recovery
• migration
• storage management
• DNS management
• logging, tracking
• localization
• issue/bug/support tracking
  

Business Management

• ad management
  
• revenue optimization
  
• multivariate testing
  
• eCommerce
  
• accounting and billing
  
• payments
  

With all of these pieces in place, the application developer would be free to build the application and load it up into the cloud, and not have to worry about many of the time-consuming and tedious management and operational issues.

A month ago, I put together the following slides for a new service, which I called “Fountain.” It has similarities to Google App Engine in that it is a scalable, hosted system for running back-end apps, but Fountain has a number of unique features, which perhaps we’ll eventually see in GAE.

Among these additional features are:

• support for languages beyond Python, including server-side Javascript using Rhino (which we first saw circa 1995 in Netscape SuiteSpot), PHP, and Ruby.
• A Business Management Workbench, for monetizing the apps. I am keeping this under wraps, as I may still choose to develop it.
• Social Networking support, which includes all the libraries necessary to write social networking and widget apps, such as for OpenSocial, Facebook, PageFlakes, NetVibes, iGoogle, etc.
• a community, so that people can share code and pre-built libraries with others. One could argue that Google Code provides this functionality, but it is not yet tightly integrated.
  

So, here are the slides. Feedback is appreciated.

In Goodbye, New York Times, Jimmy Guterman writes that he is no longer going to read The Times in hardcopy. I can appreciate that. Its expensive (relative to the online version), wasteful (pace recycling), and gets your fingers dirty.

But instead of looking forward to why The Times hasn’t joined up with Amazon to deliver the news on Kindle, or with Apple to produce an offline iPhone/iTouch news reader, this O’Reilly writer, ostensibly a leader in new media, shows himself to be stuck in the last century’s thinking about the newspaper business.

First of all, Guterman writes:

For all the pleasure of holding and print, the Times on paper is just too late. In 2008, today’s paper is yesterday’s news.

The reason people read the New York Times is not for the late breaking news, but rather for its news analysis, which has expanded in recent years. Years ago, The Times realized that it had stiff competition from the web and cable news, especially on the west coast, when deadlines are 3 hours later. New analysis, however, is reflective, and competes on insight rather than timeliness. By Guterman’s logic, print weekly and monthly news magazines would also be worthless.

Guterman also writes:

In this era of advertising-is-the-only-business-model, management at the Times Company has decided that I’ve decided that the value of what it sends to me is zero.

Actually, The Times Company has decided that the value of what it sends him is quite high, but the paywall revenue was growing much slower than the advertising supported revenue.

“The business model for advertising revenue, versus subscriber revenue, is so much more attractive,” he said. “The hybrid model has some potential, but in the long run, the advertising side will dominate.”

I’m not saying everyone has to read The Times in print. I certainly scan the Times’ RSS feed for headlines once during the day. But if you’re going to dump the print version, its should be because of cost, wastefulness, and cleanliness. A hardcopy paper won’t easily be able to keep up with the web, but the print version (or a physical facsimile thereof, like the Kindle or iPhone), read in repose, is more conducive to thoughtful reflection and analysis than sitting at ones desk flipping through links.

Dear Documentation Author:

Thank for putting out a 150 page document on your new product. I really appreciate it when a company puts the time and effort into producing a voluminous manual, rather than just letting people figure it out for themselves.

But I would have to say, your documentation is worse than useless.

Here is a perfect example:

It is not OK to show a screenshot of a dialog box and then just list the elements in the dialog box and tell me to fill it in!

You also don’t need to tell me how to mark a checkbox, “Click next” or “Click Finish”.

I do in fact know how to read the screen, and I do in fact know how to use a mouse and keyboard to move around the screen and fill in boxes.

What I don’t know and can’t tell from your documentation, is the definition and usage of concepts and terms in the dialog box, such as “Server Path Mapping”, “Platform Server”, and “Platform GUI”. Please either inline or hyperlink descriptions of what they are, and tell me how your application uses this information. I don’t need to know how to go about “Defining a Platform Server”. I need to know what a “Platform Server” is.

Furthermore, you documentation implicitly asks me questions (‘Do I want platform integration?’, “Do I want ‘tunneling’?”), without giving me any clue about how to make a decision or what the impact is of my decision.

It seems that some of the information on the form – URL, return host, server root, username and password – needs to be coordinated with other applications. It would be useful to know exactly where this information comes from, and how its used here.

I’m also concerned about putting a password into the dialog box. Is it stored in plain text? What are the permissions on the file in which they’re stored?

And please don’t tell me to “enter the relevant information.” If I knew the “relevant information,” I wouldn’t be reading the documentation. Its your job to tell me what the relevant information is, where it comes from, and how its used in the application.

I wish that the above was an isolated incident. But in fact, this may be one of the more informative sections of your manual.

The point of documentation is to inform and educate, not to explain how to move around the screen and how to fill in the blanks.

I’m sorry, but your manual just doesn’t cut it.

And its worse than useless because I spent way too much time hunting around for information in your manual, and not enough time getting done what I wanted to do.

Sincerely,
A former user

With the introduction of the iPhone SDK, people will be writing iPhone apps like crazy. There are a number of special features in the iPhone that make it the perfect platform for advanced mobile applications, so I’ve started brainstorming about what some of these apps might be.

There are three new technology features in the iPhone that I think will make the biggest difference in the kinds of applications people can build:

3D Accelerometers

With previous mobile devices — such as Blackberrys, Window Mobile, and Palm — users interacted with the device via the keyboard, stylus, or scrollwheel.

Using the iPhone’s 3D accelerometers, the iPhone can sense its own orientation to the earth in 3 axis and measure how fast and in what direction the iPhone is moved.

With orientation and motion detection, users will be able interact with the device by holding or moving the iPhone in a certain way. For example, when using the iPhone’s phone function, dialing and holding the phone up to one’s ear disables the touchscreen, so that the user’s cheek doesn’t accidently interact with the screen. When the user moves the phone away from his ear, the screen is again enabled.

Continuous geographic location reporting

Even without a built-in GPS, the iPhone can approximate its geographic position by using radio waves to measure its distance to surrounding cell towers. This position reporting is accurate to within a few hundred yards, and is much less accurate then GPS, which is accurate to a dozens of feet.

Using the location services, applications can change their behavior depending on where in the world they are.

The most obvious use for this feature is for location-based services, such as maps and driving directions. But location services could also for new kinds of commerce, such as distributing discount shopping coupons to consumers who are near a particular store.

Bonjour networking

This is the unsung hero of the iPhone. This technology lets Bonjour-enabled devices interact with other Bonjour-enabled devices in the immediate area without requiring a central server. Now, two iPhones can communicate with each other directly, so long as they were within WiFi range.

This feature would allow friends or family members to find each other in a crowded mall or movie theater, or send each other files and media without using email or SMS.

Other Bonjour-enabled devices include printers and webservers, so iPhones would be able to print on local printers without configuration, or browser the websites of local merchants.

New Application Designs

Rather than putting my application ideas up here on my blog, I am hosting them on Google Sites because I want to be able to add new ones and improve them. I’m Putting each application in a separate blog post so people can comment on them individually.

RideReporter is an application for pilots that measures and reports areas of turbulence.

BizCardSwapper is a little program to let you exchange business card information with your friends and colleagues, even ones that don’t have an iPhone!

FrienDar is a radar screen to help you locate your friends.