Thursday, August 28, 2008

Java on the iPhone? Introducing jaiPhon

We're decided to push the boundaries.

It's plain dumb to have a potential market of 5 million people worldwide wanting to develop for the damn thing, and not have a legal, viable way of doing so if they will, if they've accepted Apple's terms in the iPhone Developer Program.

So, in good ol' fashioned "if it ain't there, build it", we started building it, and we're on our way to finish it. I'm today introducing what will be a complete toolset for Java developers to write Apple-compliant, AppStore-ready applications.

Meet jaiPhon, the "Java on iPhone" development kit.

Our goals while building jaiPhon included:
  • Using the familiar Java programming language
  • Using a familiar IDE like Eclipse or Netbeans
  • Generating 100% valid and compliant iPhone applications
  • Explicitly avoiding software black boxes and developer lock-in
  • Allowing for Xcode Instruments tuneups if needed
We just started walking, and we see a long road ahead of interesting innovations before we can run. A first, functional version, will be made publicly available in late September, begginning October at most. It will be a commercial product, but will be affordable to most pockets.

It will open the amazingly new iPhone world to the Java community.

Just imagine the possibilities developing in Java for the iPhone. Imagine jaiPhon.

An updated site will come up in the next few weeks in Keep in touch!



Sunday, July 27, 2008

Special Post - a new Java apprentice?

Hello all,

This is not my usual Java-related, post, but is still a mandatory one. On the 22nd July, a new member has joined the family, making me officially a father. Here he is:

This will be the beginning of a whole new kind of adventure, and almost certainly a non-Java-centric one.

Or will it? :) Cheers,


Monday, July 21, 2008

What if you want Java on a jailbroken iPhone?

Then that's easy:

There's an example of using JamVM ( on the iPhone, bridging the Objective-C classes with JocStrap ( and writing nice Java code like:

public Object preferencesTable$cellForRow$inGroup$

(UIPreferencesTable table, int row, int group) {
return cells[group][row];

...instead of:

- (id)preferencesTable:(id)preferencesTable cellForRow:(int)row inGroup:(int)group

While this works nicely, it's still cumbersome, and (obviously) not oficially supported.

Jost for the (few) of you who didn't know about it. Of course, good luck in trying to publish that on the AppStore.



Sunday, July 20, 2008

You know you've got a Java geekiness problem when... convince your wife to cross stitch a Duke bib for your soon-to-be-born son:

And I can already envision a whole set of these... :)


And again, Java on the iPhone...


We've been doing some software development work on Apple's iPhone using the legit toolset. And of course, most of the guys working with me have their C skills as rusty as old wild west nail - leave alone their Objective-C ones...

We opted for Objective-C because of the all-too-known reason that Java simply isn't there. Sun and Apple have been struggling for ages regarding Java implementations on the Mac - figures - the iPhone didn't turn out different.

Quite a while ago, Steve Jobs went very vocal regarding a possible Java implementation on the 412Mhz, 128Mb RAM device: "Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain." This made it sound like a technicality, a business decision made upon imposition by the heavy restrictions Java puts on the hardware platform. Not so - many mobile phone platforms are way way slower than the iPhone, and still run snappy (ok, and sometimes not-so-snappy) Java apps.

After joining Apple Developer Program, and doing our first developments, I now believe that NOT implementing Java on the iPhone is, these days, CRITICAL for Apple's business model, regardless of any technology decision.

Still, there are two distinctions to be made. When people talk about Java on the iPhone, they usually mean either a) Java support on Mobile Safari, in order to run and render Java applets on the device and b) native JVM support for developing mobile Applications such as those that appear on the phone's Home screen.

In the first case, I dont really think it would me a major issue to allow java to run as part of Safari. As a matter of fact, if there is to be ANY Java support for the iPhone, I believe this will be the only way - in a heavily sandboxed environment, where Java will be used mostly as a runtime for browser-embedded snippets or Java-FX sites. I believe Sun really needs (and is already leaning) to showcase that Flash/Flex can have a serious contender in the battle for interaction-rich, non-AJAX RIA applications.

As for the second case, it gets a bit more complicated. It is now pretty much public domain that even if one wanted to write a JVM for the iPhone, we couldn't, at least with the agreement leaked many weeks ago, and that anyone can find over the internet with a Google search. In it, Apple specifically prohibits interpreted code, plug-in architectures and the such, in a way that makes it pretty clear that a JVM cannot be easily written under such agreement. And even if it could, even if one could write a JVM as a native application, it would still not be enought to provide end users the same experience as native phone apps would have: Cora Animation, Coccoa Touch and the other nifty API's that make up so much of the UI experience would have to be bridged/reimplemented, many times in ways that would certainly breach the developer agreement once more.

So, why? Why is Apple allowing users to publish free applications in the App Store, but yet explicitly forbidding them to write code as they want, in any language or environment they feel most comfortable in?

Obviously, control. If one could write downloadable, boundless interpreted code, there would be no way to effectively limit "dangerous" applications such as VoIP, Navigation, or even Porn, all forbidden under the Developer Agreement. Now, don't get me wrong - this is legitimate corporate policy. Even understandable, in fact. But it may have consequences, both for Apple and Sun.

As iPhones gain momentum in the market, a huge number of Java Developers that would be eager to write innovative applications for such an interesting platform will have to make the Java-to-Objective-C leap as we're doing. This is wasted potential for Apple, as many simply won't make this jump. This is a wasted opportunity for Sun, as it won't be able to position the technology effectively against Flex and Flash. And it is wasted knowledge and proficiency for the developers themselves, since they will have to cope with a steep learning curve that brings mostly unproductivity and frustration, and discards one of the most widely used programming languages for the device.

And finally (and this is the one that doesn't make sense) - why, oh, why, can't we at least have an Apple-supported Java cross compiler in Xcode for the iPhone?

Sorry for the rant.



Monday, July 7, 2008

Top 10 SOA Pitfalls revisited

There is a very interesting article the one at Xebia here, also pointed by TheServerSide here. The guys at Xebia have been collecting a series of common grounds for trouble while implementing a SOA programme in an organization.

They list the following as the "common pitfalls":

#10 - Not Invented Here Syndrome
#9 - Versioning
#8 - Security
#7 - Incorrect Granularity of Services
#6 - SOA does not solve complexity automatically
#5 - Big Design Upfront
#4 - Incorrectly applied Canonical Data Model
#3 - Missing skills
#2 - Unclear ownership/Project based funding
#1 - Ignoring culture when introducing SOA

...go read their article for a better insight at each.

The curious thing is that I've been lecturing a series of SOA courses over the last couple of weeks, and it is amazing how most of the problems listed above are present in the recurring questions the students ask. I believe the most interesting conclusion to be reached from analyzing the list above is how unevenly split between technical and non-technical themes it is.

In fact, from the list above,

  • Not Invented Here Syndrome
  • Security (crosscuts technology)
  • SOA does not solve complexity automatically
  • Big Design Upfront
  • Missing skills
  • Unclear ownership/Project based funding
  • Ignoring culture when introducing SOA

...7 out of 10 of the pitfalls Xebia lists are mainly related to culture and human-related problems (mostly communication, skills and awareness), and not technology-related problems.

What strikes me as odd is that SOA is being "sold" extremely agressively in the marketplace mostly by technology providers and system integrators - eager to deliver organizational change through new technology. This is plain wrong, a technolust dream, and leads mostly to frustrating project failures.

In real life, you won't get to magically change an organization to be "more into SOA" by magically stuffing new products into it - new ESB's, Registries or BPM suites won't change the fact that the people will have to want them in - and need them - there in the first place. And for that to happen, we'll have to show them why SOA is relevant for them - but, more importantly, check if they really really need it.



Saturday, July 5, 2008

Plunge and Squish?

Let's start this blog by making the title's meaning clear: what is this thing with Plunge and Squish?

Well, you see, this guy, one of Sun Microsystems' cofounders, was deeply involved in a technology named Jini, which helped me land my first paying Java job. His name is Bill Joy. In 1998, I was working as a free-lancer when I read Wired's "One Huge Computer", the article about Sun's Jini technology that pretty much changed my life. It really left my head spinning: the framework looked so lean, so fit. I was in love. It was built with the language of my dreams, and it screamed to be experienced with. I ended up writing an article about it to a conference going on at Setubal's Polytechnic Institute, ICEIS'99. I also ended up experimenting with it at the polytechnic's campus, and invited to join WhatEverNet after a speech about Jini at one of the University of Coimbra's TechDEI events.

While I was experimenting with Jini, it became clear that one of its few applications at the time, JavaSpaces, were deeply influenced by the work of a scientist named David Gelernter, which had created a concept called Linda, a coordination and communication model that operated around the idea of objects stored in and retrieved from a shared memory with very simple, yet effective semantics. Curious about it, I started reading his works.

One of his books ended up as one of the most interesting pieces I ever read: Muse in the Machine, a book discussing creative human thought, and proposing to model our creative process, once again, on very simple, but effective primitives. I fell in love with the concept. By then, I'd also read Mirror Worlds, another of his pieces, in which I believe these two primitives were first named. He named them Plunge (for diving into our memory pool and attracting relevant, related, memory constructs) and Squish (for super-imposing them and revealing resulting abstractions and inferences).

A blog, as a collection of related, supposedly creative thoughts, is naturally related to such concepts, as is any human thought. Still, any activity log has, I believe, yet another relation to the Plunge and Squish process David Gelernter describes: it comprises a set of memories, a stream of knowledge, opinions and plain data that will, in the future, once Plunged into and Squished from, reveal an emerging pattern of the true essence of one self's public (and, mined correctly, private) persona.

As I start this new blog, I have no idea what will emerge, what the ultimate Squish (summary) will reveal. I can only promise the reader my best efforts in being clear and authentic, so that my memories - which, once published, turn into everyone's collective memories - can be atracted in useful terms to other people's Plunges (memory recalls). :)

Hope you will enjoy the ride.