Daniel Eran Dilger
Random header image... Refresh for more!

iPhone 2.0 SDK: Java on the iPhone?

Daniel Eran Dilger
Shortly after Apple announced the iPhone SDK, Sun announced the intention to bring its Java Micro Edition platform to the iPhone. Questions remain about whether Sun will be able to deliver, if Apple will allow it, and what purpose this would serve for iPhone users. Even more interesting is where Java came from, and where it’s subsequently going in the mobile arena.

A Window into Sun’s Java.
After liberating the graphical desktop from the confines of Xerox PARC to deliver the Macintosh, Steve Jobs left Apple and began managing a project at NeXT that planned to do the same thing for various other concepts pioneered at Xerox. Among them were:

  • device independent graphics, which had left Xerox with John Warnock to become PostScript and later PDF at Adobe;
  • standard networking, which had followed Bob Metcalf out of Xerox and into 3Com commercialization as Ethernet;
  • object oriented coding, which left Xerox as Smalltalk, to be fused with C by Brad Cox to become Objective-C.

NeXT’s use of Objective-C became one of the unique features of the system, as most other desktop development environments of the 90s continued to use Pascal, like Apple’s Mac, or C/C++, like Microsoft’s DOS and Windows users.

Objective-C, particularly when tightly integrated with the development frameworks of NeXTSTEP in 1988, offered a far more powerful and easier to use development environment than Microsoft’s 1992 MFC for Windows, which only provided a thin wrapper of C++ functionality on top of the C Windows API. Microsoft wouldn’t offer anything comparable to NeXT’s development frameworks until .Net in 2000.

Ten years after its cloning of the Mac, the role of Microsoft in partnering with and then copying the technology Jobs was developing would fall to Sun Microsystems. Sun and NeXT joined efforts in 1993 to bring the NeXT development environment to Sun Solaris. After porting the system and developing the OpenStep specification to allow any vendor to host NeXT apps on its own operating system in 1994, Sun backed out to turn its attention toward a different project in 1996: Java.

Why OS X is on the iPhone, but not the PC: The History of OpenStep
Cocoa and the Death of Yellow Box and Rhapsody

Sun Brews a Familiar Tasting Platform.
Java includes:

  • the Java language and compiler;
  • the Java Virtual Machine for running platform independent bytecode;
  • the Java API frameworks of class libraries.

The Java language syntax is based upon C++, but its object model comes straight from Objective-C. The Java API also borrows heavily from the NeXTSTEP frameworks. In addition to Sun’s work on Java, Apple and IBM (and later HP) also worked frantically to copy NeXT’s frameworks as part of Taligent, while Microsoft only promised to catch up with the state of the art (as delivered by NeXT years prior) in Bill Gate’s 1991 Cairo project. After a half decade of efforts, only Sun ever delivered anything comparable to the NeXTSTEP frameworks; it shipped Java 1.0 in 1995. Portions of Taligent also ended up in the Java API.

Through the second half of the 90s, the tech world exploded in hype over Java. Despite initially being slow, immature, and incomplete, lots of people saw potential in a system that could offer developers the ability to “write once, run anywhere.” Microsoft uniquely saw this as a threat to Windows, and worked diligently to destroy the cross platform features of Java and simply turn it into another way to build Windows apps.

After buying NeXT, Apple saw Java as a bandwagon vehicle for launching its plans for the newly acquired NeXT software. It considered changing the Objective-C syntax to be more familiar to Java developers, delivered a Java bridge to let developers use the Java language instead of Objective-C, and gave its new NeXT-derived frameworks the fashionable coffee pun name of Cocoa in an ironic nod to the darling Java environment Sun had patterned after those same frameworks itself.

1990-1995: Microsoft's Yellow Road to Cairo

The Secrets of Pink, Taligent and Copland
1990-1995: Microsoft’s Yellow Road to Cairo

The Caffeine Buzz Wears Off.
Sun’s original mission with Java was to become the platform of all platforms. By developing a Java Runtime Environment for various different systems, Sun hoped to create a market where everyone would write Java apps in Java code to the Java API instead of writing Windows apps in whatever language Microsoft was supporting using the Win32 API. Sun also hoped to make Java the lingua franca of the web, so that all interactive applets in webpages would be done in Java.

Microsoft hoped to kill both efforts dead; Sun helped: Java didn’t deliver great performance for web or desktop applets, and while Sun focused on making Java work on Windows, the JRE on the Mac and other platforms were poor, and web plugins didn’t work great. Sun also provided third rate user interface tools, so Java applets all looked bad. Once it gained a reputation for being slow, ugly, and unusable, Microsoft’s disruptive efforts made quick work of the remains.

In contrast, the much weaker Apple of the same period faced similar pressures from Microsoft to kill QuickTime, but the environment survived the assault. In part, this was because Apple didn’t partner with Microsoft or delegate it control of the QuickTime implementation on Windows in the way Sun foolishly did with Java.

Java is still extremely valuable in other areas, particularly on the server side. Sun successfully pushed web server development to Java, where the initial performance problems could be solved with heavy hardware and the user interface didn’t matter. Sun pushed this hard because it also resulted in giving the company a way to sell its SPARC servers at a time when Microsoft was trying to make everything Windows PC-only; Java could run everywhere the JVM was ported. Many web application servers have been ported to Java for this reason, including Apple’s WebObjects.

Microsoft's Plot to Kill QuickTime

Microsoft’s Plot to Kill QuickTime

Jittery Handheld Desperation.
Outside of its server space success, Sun has pushed Java as an ideal platform for mobile devices using a stripped down micro edition called Java ME (formerly J2ME, and distinguished from the desktop Java SE standard edition and server Java EE enterprise edition). Sun even calls Java ME “the Most Ubiquitous Application Platform for Mobile Devices,” due to the huge scale of phone makers including a version of Java ME on their phones.

The problem is that mobiles are even less consistent than desktop PCs, where Java largely failed. There are only a handful of notable Java apps on the desktop, including file sharing apps Limewire and Azureus, despite Apple’s efforts to court 100% Pure Java development on the Mac.

That’s because developers interested in delivering their software across platforms are more likely to use either their own in house development tools to code cross platform or port their interface code to Apple’s native Cocoa frameworks rather than to use Java to bridge the Windows/Mac/Linux divide.

Java ME in the Mobile World.
Among handheld devices, Java faces an even tougher task, as there are far more limitations to mitigate, less money can be asked for applications, and different devices all range dramatically in terms of capacity. Like Microsoft in the PC world, Sun has worked to reign in some standardization among mobiles by publishing a specifications called the Connected Limited Device Configuration and Mobile Information Device Profile, which outline minimum requirements for phones running a Java ME user interface.

Sun leaves the work of implementing a JRE to the phone makers. This results in every Java ME phone having slightly different features that make targeting a variety of models with the same applet a frustrating experience, often expressed as “write once, debug everywhere.” Imagine if Microsoft gave every Windows PC maker a specification for writing Windows themselves, and then trying to roll out Windows apps for all those slightly different Windows PC variants. It wouldn’t be pretty.

Java ME also has significant limitations based on the legacy of smartphone development dating back into the beginning of the decade, and due to the mobile service industry’s stranglehold over the design and use of phones, and their control over the mobile networks commonly used to deploy them. Java ME apps are commonly limited in size to less than 1MB, and the networks practically limit things further to 300KB. That results in making the largest volume of Java ME software simple games and other lowest common denominator titles that fail to take any real advantage of any particular phone’s features.

Here’s how a J2ME version of Texas Holdem (below top) stacks up against the Palm OS version, the iPod version, and the Verizon BREW version (below bottom; click to enlarge). It’s certainly nothing special. One might expect an iPhone version to look better than the iPod edition.


Palm iPod Brew

Why Would Anyone Want Java ME on the iPhone?
Putting a Java ME (J2ME) environment on the iPhone would be a lot like putting a CP/M environment on the Mac. Anyone who bought the iPhone expecting a slick handheld with a clear and easy to use interface would be befuddled by Sun attempting to get them to install the clunky Java ME runtime.

Apparently, Sun hopes that someone might find it useful to install Java ME on the iPhone in order to nostalgically run software applets designed for far less capable phones, like those ABI Research had in mind a year ago, back when analyst Philip Solis was insisting that the iPhone “wasn’t a smartphone” because it couldn’t run third party software like the two-bit junk available for J2ME phones.

A big problem for Sun however, is that Apple has stated that it doesn’t want developers uploading alternative API runtimes onto the iPhone. One clause in the SDK agreement states: “An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).”

That handily rules out a Java ME JRE, which expressly loads and launches Java applets as interpreted code using its own Java API. Incidentally, it also rules out Adobe’s Flash and Microsoft’s Silverlight.

The iPhone Threat to Adobe, Microsoft, Sun, Real, BREW, Symbian
More Absurd iPhone Myths: Third Party Software Panic

Is Apple Going Too Far?
Is this an abuse of Apple’s power in selling its product? If Apple had instead exclusively licensed the iPhone software to every major hardware maker, monopolizing the market for any phone software, it might be.

Fortunately, Apple is only competing in a wide open market for mobile phones with its own unique business model. Apple doesn’t have to invite Sun to the table and offer it a chair for its competing Java ME API any more than BMW has to include a radio bundling option for Bose, Panasonic, Sony, and everyone else with every car it sells. If Apple pursued a Microsoft model for owning the software layer of every phone sold, blocking access to competitors would be a different matter.

That’s the big difference between Apple’s business as an integrated hardware maker and Microsoft’s business as a software licensing middleman that seeks to establish itself as a robber baron pirate to extort fees from every passing ship on the river. Apple isn’t doing anything to stop or restrict Sun from bringing its own jPhone to market, nor is it interfering with Sun’s existing efforts to push Java ME on the majority of phones in use.

Sun Tries to Jump on iPhone Bandwagon with jPhone

Sun Tries to Jump on iPhone Bandwagon with jPhone

A Reversal of Fortune for Sun and Microsoft.
Ironically, Sun already claims to have the middleman position Microsoft aspired to achieve with WinCE/Windows Mobile; J2ME is installed on most phones. However, this is largely irrelevant, as few users bother to install software because the selection is poor, the titles are weak, compatibility is shaky, and mobile operators are all in the way at various points of the game. That means Sun, like Microsoft on the desktop, has nothing but everything to lose from Apple’s expansion in mobiles.

Java is on nearly every phone except the one people are talking about, paying a premium to own overseas, and excitedly planning out serious applications for. It’s no surprise why Sun wants to join the party, but there’s no way it’s getting in dressed as it is. Java ME is a joke.

Sun’s history of partnering with, then abandoning NeXT–but not before buying up Lighthouse Design and locking up its NeXT apps and throwing away the key–has come back to haunt the company in a big way. If it had realized the limited amount of tread it was about to get from the concepts it lifted from NeXT, and the game changing mobile NeXT’s software would empower a decade later, perhaps it would have made different decisions. Instead, Sun’s mobile efforts are about to become as irrelevant as Microsoft’s Windows Mobile aspirations in the wake of Apple’s iPhone submarine.

More on the iPhone 2.0 SDK

iPhone 2.0 SDK: The No Multitasking Myth
iPhone 2.0 SDK: Java on the iPhone?
iPhone 2.0 SDK: How Signed Certificates Work
iPhone 2.0 SDK: Video Games to Rival Nintendo DS, Sony PSP
iPhone 2.0 SDK: Readers Write on Certificate Signing

I really like to hear from readers. Comment in the Forum or email me with your ideas.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!

Technorati Tags: , , , , , , ,

  • Jon T

    I continue to be dumfounded by your straightforward and concise analyses. They to strip away all the fluff and nonsense, leaving just the bare skeleton as clear as day.

    Thanks Daniel!

  • PerGrenerfors

    Another great article. I like how you draw parallels between NeXT of ’90s and today’s Apple. It makes for a great historical background.

  • Pingback: Cell Phones » Blog Archive » iPhone 2.0 SDK: Java on the iPhone?()

  • addicted44

    @ PerGrenerfors

    The Apple of today is largely a continuation of NeXT of yesteryear. In fact, all Cocoa objects have the NS prefix, reminding us about their NextStep origins!

    I agree with Daniel here, however, I would like to point out, that 1 out of the 3 java components is heads and shoulders above the rest. The API’s. The language is about average, and the JVM falls FAR short. If Sun had indeed able to improve the JVM (and stopped insisting on the write once, debug everywhere model) I think Java could have made a lot of headway, especially on the desktop. Alternatively, if they had focussed more on the JVM on Mac OS X, and Linux (both of which would have been happy partners) Java would be doing a lot better than it does now.

  • David Dennis

    Most of these interpreters are pretty big and pretty hoggy on performance, no?

    That seems like a pretty straightforward reason for banning them.

    I have a question for the audience here.

    I am writing an application for iPhone that has a complex model. I would like to reuse that model code to build a web version of the app.

    Is there any web server system that would let me efficiently code in Objective C?

    I know I could use CGI and an Objective C executable but my impression is that is pretty sluggish.

    I researched WebObjects but it seems to be in Java, not Objective C.

    Am I missing something?

    Thanks for any help!


  • gesso


    I know nothing of writing web apps, but it is common for objective C to only be used for the view and controller, where as the model be in another language (I use C and C++). The reason for this may be old libraries, speed, or portability.

    You likely know this and I am not sure how relevant this is for web apps ( I have never done any ), but just in case.

  • gus2000

    The last non-Apple phone I owned was a simple feature-phone, but I did download a game or two so I could entertain myself when forced to wait somewhere. I certainly couldn’t use the integrated browser for anything other than eyestrain and elevated hypertension.

    The phone would actually run hot when I played a simple blackjack game. If I made the mistake of pocketing the phone with the app running, it would happily drain my battery to empty within an hour. I really don’t miss that phone. I almost stomped it to pieces in front of the Apple store on 29 June 07.

    Java, schmava. Let them port it to iPhone so that we can all see what a miserable failure it is compared to the native apps.

    I am curious about alternate browers on the iPhone. The “pundits” seem to think it impossible due to the same clauses that prohibit Java, but that seems silly. If the license prohibits me from rendering text and images with my own engine, then doesn’t that rule out word processors too?

  • Jonasf


    Ironically, “NS” stands for “*N*eXT and *S*un”

  • David Dennis

    Gus, I think the issue would be the JavaScript interpreter, which is rather obviously a programming language environment.


  • wordwarrior

    Sun makes a lot of money from Java ME, so their attempt to port it to the iPhone is logical, as well as futile. You can’t blame them for trying.

    Still, Schwartz and Sun have enough irons in the fire, and rapidly expanding systems integration businesses and partnerships that losing JEE won’t matter. Java itself is poised to be installed on most Linux distros once it’s 100% open source. Java FX still has an excellent chance at beating Flash and Silverlight as the platform of choice for Rich Internet Applications.

    Also, Sun is doing some exciting things with OpenSolaris with Project Indiana.

    The future looks interesting for Sun.


  • solipsism

    I’d be glad if someone could explain it to me as I am apparently missing something.

    Sun can put a JVM ont he iPhone without Apple’s specific consent, but there is no need for a JVM as any Java code can be put into Cocoa and compiled to run with a few tweaks. Is that part right?

    If so, they why the need for a JVM if Cocoa’s frameworks can already full understand Java out of the box?

  • sebastianlewis

    Solipsism, no that’s not right. Java apps running on Mac OS X use Sun’s HotSpot VM. There was a Cocoa bridge that allowed Java apps to use a well, more native UI and it may have allowed them to use Cocoa frameworks (I’m a bit fuzzy on that but no doubt someone else will clear it up) but the Cocoa bridge has since been depreciated and now, Cocoa cannot understand Java apps.


  • solipsism

    Not Java apps, but Java code. You can port the code into the Cocoa and with a few tweaks get a fully working, native OS X app running.

    According to Wiki: “The Cocoa frameworks are written in Objective-C, and hence Objective-C is the preferred language for development of Cocoa applications. Java bindings for the Cocoa frameworks (known as the “Java bridge”) are also available but have not proven popular amongst Cocoa developers. Further, the need for runtime binding means many of Cocoa’s key features are not available with Java. In 2005, Apple announced that the Java bridge was to be deprecated, meaning that features added to Cocoa in Mac OS X versions later than 10.4 would not be added to the Cocoa-Java programming interface.”

    So is this functionality going away?

  • nextcube

    As a long-time Camino user, I wonder what Javascript interpreter they’re using…or if a “mobile Camino” could be made to use Webkit’s JS interpreter. Since Camino is already Cocoa-native (and even supports session saving on the desktop!), it seems like a logical choice as an alternative browser for the iPhone…

  • David Dennis

    That’s an interesting question, Nextcube. I think guess that various JavaScript interpreters have different APIs and dependencies on their parent browser’s DOM but that’s just a guess.

    I’m not sure if there’s any real benefit for consumers of having alternative web browsers on iPhone. The main reason I have them on my desktop computer is to make sure my web sites work with all browsers. I think I would personally prefer it if I would only have to worry about one browser/device combination for iPhone.


  • lehenbauer

    Agreed, the license appears to preclude Sun from porting Java to the iPhone.

    I don’t read the license as saying you can’t put an interpreter into an app, but that you can’t make your app be able to download new software for the interpreter.

  • sebastianlewis

    Solipsism, yes it’s depreciated, it certainly wouldn’t have been ported to the iPhone because there’s no JVM. Apple could make their own VM but that most likely hasn’t and won’t happen.


  • Pingback: php code and scripts » Blog Archive » iPhone 2.0 SDK: Java on the iPhone?()

  • http://www.netytan.com netytan

    … The Java language syntax is based upon C++, but its object model comes straight from Objective-C. …

    Hi Dan, this simply isn’t true. The object model employed by Objective-C is considerably different from that of the Java programming language.

    Objective-C is message based, as in Smalltalk, while the Java programming language is method based, as in Simula. Objects in Objective-C can be sent any message to them, while objects in Java may only have select methods called on them.

  • http://ephilei.blogspot.com Ephilei

    Javascript isn’t a programming language environment, it’s just an engine that runs scripts. There are no executables involved which the SDK prohibits.

    Why not get more browser options for the iPhone? Competition can only be good.

  • jdb

    netytan is correct.

    In Java, even with objects that use late binding, the methods must be part of the defined class. Java can check this at compile time in most cases. In objective-c any message can be sent to an object and if the object can’t respond, you get a run-time error.

    The Java way has many benefits. It makes getting a program up and running significantly easier. Trying to track down why a particular message is getting a run-time error in objective-c can be time consuming. Luckily Xcode will at least give you a warning in most cases.

    On the other hand, doing very late binding such as objective-c does is a significantly more flexible object model. There are some things that objective-c does that aren’t really possible in Java. That is mostly the reason that the Cocoa-Java bridges were abandoned, you can’t really get Cocoa native applications in Java so why bother.

  • sebastianlewis

    Ephilei, JavaScript is an interpreted language like Python or Ruby as opposed to a compiled language like Objective-C.


  • Pingback: iPhone 2.0 SDK: The No Multitasking Myth — RoughlyDrafted Magazine()

  • beanie

    I read uses an ARM11 CPU. So the CPU has Jazelle, Java Direct Bytecode Execution. The most common use is to speed up J2ME by executing the bytecode in hardware. ARM claims about 95% of bytecode is executed by hardware and increases performance by 40%.

  • Pingback: buzz()

  • http://www.netytan.com netytan

    Sebastianlewis: Javascript isn’t interpreted like Python and Ruby. Both Python and Ruby have a VM that executes byte code. I do agree with your general point however; Javascript is as much a programming language.

  • lmasanti

    “Jonasf on 03.14.08 at 11:47 am

    Ironically, “NS” stands for “*N*eXT and *S*un”

    Sorry. “NS” stands for NeXTStep. The joint version was called OpenStep. See the cited dates. (Quotes from Wikipedia)

    “NEXTSTEP was the original object-oriented, multitasking operating system that NeXT Computer developed to run on its proprietary NeXT computers (“black boxes”) such as the NeXTcube. NEXTSTEP 1.0 was released on September 18, 1989 after several previews starting in 1986.”

    “OpenStep is an object-oriented API specification for an object-oriented operating system that uses any modern operating system as its core, principally developed by NeXT with Sun Microsystems.”

    “The OpenStep API was created as the result of a 1993 collaboration between NeXT Computer and Sun Microsystems, allowing this cut-down version of NeXT’s NEXTSTEP operating system object layers to be run on Sun’s Solaris operating system (more specifically, Solaris on SPARC-based hardware). “

  • samkass

    A very well-written article that’s also completely wrong in its conclusion. It’s very easy to write extremely engaging, state-of-the-art user interfaces in Java, and there’s no reason why Java software running on the iPhone would look or feel any different than software written in Objective-C. In fact, because of the iPhone’s built-in support for running Java bytecode natively, it would probably run a lot faster than Objective-C.

    Since there are several orders of magnitude more developers for Java than Objective-C, and because there is a huge installed base of behind-the-scenes libraries for the platform, Apple does a huge disservice to customers by trying to keep it off their platform. There’s no technical reason for it; it’s just spite, near as I can tell.

  • duckie

    “It’s very easy to write extremely engaging, state-of-the-art user interfaces in Java” – please name me some that run on mobile phones, I would love to know what they are. I don’t wish to appear cynical, but if it really is so easy, why has the world failed to be amazed by what J2ME has produced on other platforms?

  • gus2000

    There are many adjectives that apply to Java. “Fast” is not one of them. The hardware acceleration of Java in the processor is to make up for it’s sluggishness, not to give it superior performance.

    Java is a resource hog, which is prohibitive in a portable handheld device.

  • beanie

    After looking around, Java ME seems cool to me. For some example mobile applications:


    I would disagree and say Java ME has a good future. As phones improve, Java ME improves in terms of performance and features. Java ME also went open-source in 2006. As phones improve so does Java ME performance and features.

    Didn’t RoughlyDrafted like Blu-Ray choosing Java? Now when it comes to iPhone, RoughlyDrafted is knocking Java.

  • sebastianlewis


    As far as I know, Daniel doesn’t endorse or like Blu-ray anymore than HD DVD, but Java is definitely a better alternative to the crap Microsoft produces.


  • http://www.netytan.com netytan

    Objective-C is definitely a better alternative to the crap Sun peddles… Java. I’m a bias as the next guy :).

    Samkass: Where did you get the idea that a program running on a huge clunky VM with known performance issues, is going to be faster and less memory intensive than the equivalent program running on the metal. Objective-C is no slouch.

    From a language design point of view, while Objective-C has its warts, it’s The example of how a small change in the language can lead to a big change in development.

  • addicted44


    Can you point out a few good looking java interfaces? Even good looking interfaces in the windows world will do.

    If you look at that site, the interfaces are horrible. (e.g., Vindingo) Such interfaces will look terribly out of place on the iphone. Additionally, most Java stuff will have to be rewritten anyways because Java is based on the point and click (or select, and press enter) input mechanisms, as opposed to what Apple is providing with the iphone.

    I develop with Java, and love the API’s it comes with, however, it fails in its primary purpose of being a code once, run everywhere language on the desktop. It would astonish me if that strategy succeeds on a non-general computing device like a phone.

    If anything, Android stands a much better chance of succeeding (I am not sure what language they are using. Possibly Java, but I am pretty sure its not based on Java ME) as opposed to Java ME, because in that case the phones are being tailored for the OS.

  • Robb

    Dan, I would disagree with your conclusion that Sun’s mobile efforts (as well as MS Windows Mobile) will be rendered irrelevant by the iPhone.

    The iPhone is the best smartphone on the market, but it’s not for everybody. It might be the cost or the carrier or maybe your company has a contract with someone else… the point is there will still be other smartphones on the market, even after the next iPhone comes out, some of them running Java, Windows Mobile or whatever.

    To me, that’s not a bad thing. For one thing, it makes the iPhone look really, really good by comparison and another, it bears out Apple’s approach to development and their business model which have been oft-criticized by various pundits.

  • http://www.roughlydrafted.com danieleran

    @ samkass : the premise of Java ME (and Java in general) is write once, run anywhere.

    If Apple’s efforts to court Java developers to the Mac OS hadn’t ended with a whimper, your claim that the iPhone would be much better off running Java code that only runs on the iPhone might be believable.

    However, even Sun wouldn’t like this, as it would be a lot like Microsoft’s attempts to tie Java to Windows. On the other hand, if Apple supplied a Lowest Common Denominator environment for supporting existing mobile Java apps on the iPhone (or encouraged Sun to provide this itself), then we’d have the great opportunity to run bad looking, poorly performing, UI fracturing Java ME apps on the iPhone. These already don’t work well on the phones that are supposed to run them.

    So again, why should we care about Java ME on the iPhone?

    The alternative to trying to get the iPhone to run Java ME applets is for developers to learn how to deliver full desktop-style Cocoa apps that have few of the limitations of an environment designed to run on extremely simple feature phones. New Cocoa developers will also fuel the market for Mac apps.

    So again, is Apple only being “spiteful” to recommend that developers use its own better, more appropriate and more powerful software rather than steering them toward Sun’s Java ME plans, which don’t currently do much for phones beyond earning Sun lots of licensing revenues?

  • http://www.roughlydrafted.com danieleran

    @ netytan: I didn’t mean to suggest there were no differences between the object model in Java and Obj-C. From the comp.lang.objective-c FAQ:


    What is the difference between Objective-C and Java?

    The most obvious difference is syntax: Java’s syntax is based on C++’
    whereas Objective-C employs the C syntax (and semantics) with the syntax
    of object declaration and manipulation based on Smalltalk.

    The Java object model comes straight from Objective-C. Nested classes
    do not change that since they are retrofitted, in Java 1.1, onto the
    original Java 1.0 object model for compatibility with 1.0 tools.

    Features that Java adds include mandatory typing, exception and thread
    support in the language, security managers, name spaces, predefined
    class libraries (java.lang, awt), etc.

    Features that Java misses include categories and the selector type. No
    categories means that a class can not be amended to suit your needs (a
    problem suffered by more OO languages, including C++). No selector type
    means that `forward::’ and `perform:’ methods do not exist, and that the
    possibilities of dynamic binding are limited; e.g. you can’t tell an
    array to say `@selector (hello)’ to all its elements, and the buttons in
    your GUI won’t be able to use the target/action paradigm employed by the
    OPENSTEP AppKit (and which is why inner classes were invented in Java

    Java currently enjoys a lot of `compile-once run-anywhere’ hype. Even
    though Objective-C in this respect suffers the portability problems of
    C, OPENSTEP provides a foundation that could be described as
    `compile-once-for-each-platform run-on-each-platform’: OPENSTEP enables
    application deployment on platforms ranging from MS Windows to Solaris.
    This is without modifications to the source, which is what
    `compile-once’ is all about.

  • samkass

    First of all, anyone who claims that Java is slow immediately loses credibility with me. Java code is extremely fast. Experiments like Jake2 showed that some OpenGL games like Quake2 are faster in Java than C. The reputation Java gained in the 90’s for being slow was then well-deserved, but it’s come a long way and if someone calls it slow these days it says more about the competency/currency of the speaker than of Java.

    Java is faster than Objective-C because it has runtime information available to its optimizer. It knows how many times to unroll the loop or which way a branch is likely to go based on actual runtime information. It compiles down to native code then runs the native code. It also is not quite as dynamic so can inline more aggressively. It’s a great tradeoff for embedded devices, which is what Java was invented for.

    And as for the iPhone in particular, the ARM chip in the iPhone and iTouch CAN RUN JAVA BYTECODE NATIVELY through the Jazelle engine. Java bytecode to these chips is just as “native” as the ARM ABI, and since Java bytecode is more condensed than the ARM ABI (it’s much closer to CISC), it’s likely to run faster. Apple has chosen not to promote this capability, but it’s there. So claiming Java isn’t “to the metal” is disingenuous.

    As for good UIs, I humbly submit my own company’s products:
    It’s true they’re not embedded, but isn’t that the point of the iPhone? That we’re no longer limited by what typical mobile devices are capable of? Simply through Swing out the window and the sky’s the limit– you’ve got a blank canvas to implement any UI you want.

    Besides, not only can we not bring our UI directly to the iPhone, we can’t even link in our Java libraries behind a “native” UI. In other words, if we want to create a hand-held version we’ll have to go Android. (Which, as a huge Apple and iTouch fan would bum me out.)

    In the end, though, Java is just a language. gcc can compile it to native code, javac and a modern JDK can run the bytecode fast, and there are tons of libraries and trained developers on it. It’s more secure and more mature with better tools than anything Apple’s come up with so far.

  • robd

    You have not presented sufficient evidence to support your contention that Java is the result of underhand ‘partnering and copying’ on the part of Sun. That which you do supply–‘The Java object model comes straight from Objective-C’–is unsubstantiated and, and in any case of little consequence given that one uses static typing, the other, dynamic.

  • FloydThreepwood

    The article misses the point in a big way! Instead of talking about history and politics it’s as simple as you mentioned in your first comment.

    Java simply is platform dependent when it comes to UI’s. We see how MS Office struggels to put the controlls in the Mac Experience. And remember we are talking about two mouse controlled enviroments. If you think about D-Pad, Stylus and finger controlled systems they simply haven’t enough in common to make it work.

    Without the Java prmisse it simply is not sexy enough.

    BTW: If you read the comments carefully there seems to be enough materiel for a next gen language article?

  • jimmoores

    The historical context of the analysis is interesting. However, one thing that no one has mentioned is that Sun said they’d port J2ME, not the MIDP profile (which is pretty useless). If they actually meant the MIDP profile, I couldn’t care less whether they actually do it or not: it would be completely meaningless. There is no reason why an iPhone couldn’t run the full JVM (with cut-down libraries), which is essentially what some of the J2ME profiles are. Unfortunately, most people’s experience with Java begins and ends with ugly Swing applications and crappy applets. Beyond that Java is amazingly powerful and pretty big in enterprise development right now. I would just LOVE to be able to write ‘native’ iPhone apps in Java.

  • Pingback: iPhone 2.0 SDK: Readers Write on Certificate Signing — RoughlyDrafted Magazine()

  • FloydThreepwood

    @ jimmoores:

    This is the first real pro Java I’ve read so far. But the question is, how many Enterprises are out there that use custom Software? Because software companies surely can earn money from custom Cocoa touch programms.

  • Pingback: iPhone 2.0 SDK: How Signing Certificates Work — RoughlyDrafted Magazine()

  • jimmoores

    Most enterprises write custom software to some degree. While I agree that Java’s probable lack of support for Cocoa Touch does limit it’s usefulness on the iPhone, the thing to realize about enterprise development is that the user interface is less important than the functionality. A fine user interface doesn’t significantly add value unless it’s bad to the extent of taking two or three times longer to perform a task, but I’d argue that is unusual. However it’s easier to retask existing Java J2EE/J2SE developers to knock out a quick sales app for the iPhone (or whatever) than to hire a completely new team who knows Objective-C/Cocoa. After all Mac’s aren’t exactly big in business at the moment.

    Don’t get me wrong, I think UI design is very important, and I hate badly designed applications, and I’d prefer everyone to write Cocoa Touch apps (or have a good Java/Cocoa Touch bridge), but I think that my analysis reflects the reality that Java on the iPhone would encourage uptake by business.

    Whether compromising the interface for internal applications is a good trade for increased sales for Apple is up for debate though.

  • Pingback: Podcast: Flash and Java on iPhone — RoughlyDrafted Magazine()

  • http://www.christopherdrum.com Christopher

    Does the “interpreted code” limitation also prevent things like modern text adventure interpreters, MAME, emulators, and the like.

  • Pingback: Apple approves Commodore 64 emulator for iPhone — RoughlyDrafted Magazine()

  • Pingback: Commodore 64 emulator for iPhone - Software()

  • Pingback: Why Apple can’t be too worried about Android 3.0 Honeycomb tablets taking away iPad sales: Part 2 — RoughlyDrafted Magazine()