Can Someone Tell Steve Jobs About OSGi?
2007-01-23
Steve Jobs in an interview with Jon Markoff: “Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain.”. Mr. Jobs is known to use the hyperbole, but I am afraid he has a point. I remember having a fiery discussion with Mr. Smalltalk, Ralph Johnson, in ’97 about how nice Java was. One of my key arguments was that Java was so lean and mean in comparison to Smalltalk. He shook his wise head and told me to wait and see. Oh boy, how right he was. Since then Java’s library growth has consistently beaten the growth of even the best hedge fund. Time to reflect and refactor are words one can not easily associate with the Java world. The JCP has given us a hodgepodge of inconsistent APIs split between worlds that seem to diverge farther every day.
Yes, I know. Four billion phones or more run Java, generating billions of dollars of revenue. However, everybody in family has a Java phone and non uses Java applications. When you look at what people run on their telephone then it is mostly games. Where are the killer apps? These apps would appear in the market when the operators and manufacturers would allow third parties to access all the resources. Of course, JSR 232 provides a very interesting architecture for interesting applications that will enable these types of applications, but phones are only just now appearing in the market.
Sadly, Java largely failed on the desktop. How many pleasant applications do you use that are written in Java? Eclipse is still the exception. Java seems promise so much for the embedded market but it is still a hard to sell Java in a consumer device due to the extra cost of the VM and increase in resource consumption. Java only shines in the server market, where resources are plenty and inefficiency is a minor inconvenience.
Why is the situation so bleak? The “Write Once, Run Anywhere” mantra (WORA) of Java is highly attractive. The software industry spends countless billions every year porting applications from one environment to the other. Application developers limit themselves to fewer markets because the cost to develop for additional platforms is just not worth it. There have been significant problems in the past with the WORA (write once, debug anywhere israther tired joked repeated ad nauseum by Microsoft) the joke), but today it works amazingly well across platforms, note again the Eclipse success story.
Personally, I think the biggest problem is that the Java architecture is not suited to what it desires to be: a ubiquitous computing environment. A key aspect of a ubiquitous computing environment is that it should be lean and mean at the core. Few want to carry the dead weight of someone else’s requirements. The key mistake Java/JCP made was splitting Java up in different domains: JavaCard, J2ME, JSE, and JEE. Then in different configurations: CLDC and CDC. Then further refined with profiles like Foundation, Personal, Basic, etc. The intentions were good; the result is a disastrous fragmentation.
Lean and mean means you need to be able to mix and match. One of the most interesting Java projects at this moment is therefore Apache Harmony. Harmony is an open source implementation of the Java SE VM and class library. Instead of taking a short-cut, cloning the Sun VM, they use a novel architecture of modularizing the Java class library. With Apache Harmony, you can start really small and add what is needed. Such an architecture permits the use of the same basic environment across industry and platforms. Developers no longer target a specific pre-defined profile but only express their requirements on the platform. When the application gets deployed and certain packages are missing, the platform can be dynamically extend the platform by adding the missing packages.
Modularization creates a market for solutions. It is no longer required to come up with a catch-all API in the JCP, which is too often designed under political pressure. For example, J2EE would never have been a success in a free market. It received its life because it was the “ordained” API for enterprise applications by virtue of its JCP origin. It was not until an external party like Interface21 showed with Spring that Enterprise applications can actually be lean and mean as well.
I think that Java is too big and too important to our industry to be shepherded by a single company like Sun. By trying to shield the environment from fragmenting they sadly have achieved the opposite. By exerting too much control they have enabled some pretty bad APIs. Why not set firm ground rules, that is a small VM and rules for modularization, then let different parties compete with solutions. The market will quickly pick the best practices and create de-facto as well as de-jura standards.
Time to reflect. What do Eclipse, Apache Harmony, and Spring, actually have in common? Hmm, maybe Steve Jobs should invite an OSGi evangelist to give a presentation?
Peter Kriens
P.S. You did register for EclipseCon I hope?
Yes, I know. Four billion phones or more run Java, generating billions of dollars of revenue. However, everybody in family has a Java phone and non uses Java applications. When you look at what people run on their telephone then it is mostly games. Where are the killer apps? These apps would appear in the market when the operators and manufacturers would allow third parties to access all the resources. Of course, JSR 232 provides a very interesting architecture for interesting applications that will enable these types of applications, but phones are only just now appearing in the market.
Sadly, Java largely failed on the desktop. How many pleasant applications do you use that are written in Java? Eclipse is still the exception. Java seems promise so much for the embedded market but it is still a hard to sell Java in a consumer device due to the extra cost of the VM and increase in resource consumption. Java only shines in the server market, where resources are plenty and inefficiency is a minor inconvenience.
Why is the situation so bleak? The “Write Once, Run Anywhere” mantra (WORA) of Java is highly attractive. The software industry spends countless billions every year porting applications from one environment to the other. Application developers limit themselves to fewer markets because the cost to develop for additional platforms is just not worth it. There have been significant problems in the past with the WORA (write once, debug anywhere israther tired joked repeated ad nauseum by Microsoft) the joke), but today it works amazingly well across platforms, note again the Eclipse success story.
Personally, I think the biggest problem is that the Java architecture is not suited to what it desires to be: a ubiquitous computing environment. A key aspect of a ubiquitous computing environment is that it should be lean and mean at the core. Few want to carry the dead weight of someone else’s requirements. The key mistake Java/JCP made was splitting Java up in different domains: JavaCard, J2ME, JSE, and JEE. Then in different configurations: CLDC and CDC. Then further refined with profiles like Foundation, Personal, Basic, etc. The intentions were good; the result is a disastrous fragmentation.
Lean and mean means you need to be able to mix and match. One of the most interesting Java projects at this moment is therefore Apache Harmony. Harmony is an open source implementation of the Java SE VM and class library. Instead of taking a short-cut, cloning the Sun VM, they use a novel architecture of modularizing the Java class library. With Apache Harmony, you can start really small and add what is needed. Such an architecture permits the use of the same basic environment across industry and platforms. Developers no longer target a specific pre-defined profile but only express their requirements on the platform. When the application gets deployed and certain packages are missing, the platform can be dynamically extend the platform by adding the missing packages.
Modularization creates a market for solutions. It is no longer required to come up with a catch-all API in the JCP, which is too often designed under political pressure. For example, J2EE would never have been a success in a free market. It received its life because it was the “ordained” API for enterprise applications by virtue of its JCP origin. It was not until an external party like Interface21 showed with Spring that Enterprise applications can actually be lean and mean as well.
I think that Java is too big and too important to our industry to be shepherded by a single company like Sun. By trying to shield the environment from fragmenting they sadly have achieved the opposite. By exerting too much control they have enabled some pretty bad APIs. Why not set firm ground rules, that is a small VM and rules for modularization, then let different parties compete with solutions. The market will quickly pick the best practices and create de-facto as well as de-jura standards.
Time to reflect. What do Eclipse, Apache Harmony, and Spring, actually have in common? Hmm, maybe Steve Jobs should invite an OSGi evangelist to give a presentation?
Peter Kriens
P.S. You did register for EclipseCon I hope?
Comments
| Previous Posts | Archives |
|---|---|
You spoke my words. As from the first moment I read the OSGi specs my first thought was: Am I reading the right specs for the JVM. Isn't this the way the JVM should work like? ... and I'm still dreaming about.