On 8 abr, 11:47, robogeek <[email protected]> wrote: > Java on cell phones seems to me to be an failure at the moment. The > hope for a single language & programming model for all cell phones is > destroyed, at the moment. This is partly due to iphone/android/html5/ > etc efforts, and partly due to the bad quality of incumbent JavaME. > > Evidence: > a) All the attention is on Android and/or iPhone, neither of whom are > Java compatible, > b) Cellphone Java had been compelling enough it would be a leading > contender. If cellphone java had been compelling, decision makers in > the android or iPhone camps would have taken steps to ensure it was > there. They didn't. > c) Why isn't there angst over Java missing from android and/or iPhone > as there is about Flash missing from them? Again, testament to lack > of compellingness of cellphone Java.
Android _is_ Java. It's not compatible with any of the JCP-standard Java platforms (ME/SE/EE), and Google cannot use the Java(tm) branding. But it's the same language, the same execution model, and highly compatible with "standard" Java code. They have a very different VM (Dalvik) and even bytecode, but this is irrelevant -- there are many other JVMs, and while changing the distribution binary format is new, changing the execution binary format is not (most JVMs "quicken" classes into a proprietary variant of the bytecode format; some JVMs use ahead-of-time compilation / JIT caching and other techniques even farther from the purism of the standard Java bytecode). The most significant departure from Android wrt std Java is the frameworks; they have different APIs for many things, although they also share many JavaSE APIs. (In fact one of the most irritating aspects of Android IMHO, is the apparently random approach to JavaSE API support... I wish they would give us a simple subsetting model like, "we are 100% compatible with J2SE5 except for AWT/J2D/Swing/RMI/ CORBA". Instead, we have a chaothic mix of APIs, including several fragmented packages. But I digress...) So we cannot say that "mobile Java failed", although we can say that both JavaME and JavaSE failed in the mobile space. When JavaME has insufficient power to build great apps in modern smartphones, we should blame the APIs. When JavaSE is for other reasons inadequate for mobile devices (e.g. the Swing monster), we must blame the APIs once again. Even Sun recognizes this - so their plan to patch/evolve JavaME into a great mobile platform is, just like Android, replacing frameworks. This resulted in LWUIT and most remarkably, JavaFX Mobile. I don't know if these initiatives will deliver great results - we can only judge if/when reasonably mature releases are widely distributed in modern devices. But the main point is that, it's exactly the same plan as Android: keep the core of Java, replace some outdated APIs with better ones. It has worked for Android, it may or may not for JavaFX Mobile depending on several factors, including some important factors that have little to do with the Java platform - like Sun/Oracle's ability to implement what is promised, then succeed to win enough hardware partners etc.; or the qualities of the whole OS outside (the fact that JavaFX Mobile is still just an application container that lives inside Symbian or WinMob or other OS, can be both an advantage and a liability). A+ Osvaldo -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
