Here's a little observation that's important to keep in mind before I get to the main gist of my point:
j2me is a fork of the "real" java (j2se), in much the same way android is a fork of the real java. Stuff written for j2me will not run on j2se, and vice versa, though if your code is simple and universal enough, then you can use the exact same source file and it'll be accepted by both compiler/packager systems. Nevertheless, j2me does call itself java, whereas android never did, which makes perfect sense, as Oracle owns the trademark "java". It does, however, put into question exactly how serious oracle/sun is about this whole "write once, run anywhere" thing, if that doesn't even technically hold for all devices with "java" in the name. Android is more like java than j2me is in all the ways that count. Joe Nuxoll is not wrong when he says that if you program java, you know how to program android. On to how android and oracle could have gotten along, at least, if the idea is that oracle is protecting the "write once run anywhere" nature of java: There are no incompatibilities between android and java except for two areas: (A) there are a couple of libraries that are guaranteed by java (as in, they are in rt.jar) which aren't available on android, and (B) the runtime packing is different; java uses class files, android runs dalvik executables. The dalvik executable part is a red herring, in that it would have been trivial for Google to ship the android compiler, which can compile class files into dalvik, on android phones. Which leaves A: The library issue. Let's look at which libraries aren't available on android. The vast majority of these are situational and are anti-thetical to the idea that java is supposed to run anywhere. How, exactly, would swing even work on a phone? Maybe you can use some of the primitives, but there's no way the same app is going to run sensibly on both a big desktop and a small feature phone (which android was designed to run on, too) without you basically coding in two versions of the GUI. The remainder are stuff that would just needlessly clog up the phones, such as CORBA. The point of bashing corba in rt.jar isn't that corba is a bad library, the point is that it never should have been shipped as a standard part of the java libraries. It should have shipped as a separate dependency. Put differently, if corba is standard, but for mailing you have to download a bunch of jars, something isn't right. So what should Oracle have done: They should have embraced the idea that not all systems are equal. Modularize the JVM (already happening; jigsaw isn't just a module system, it started out as, and still has as primary goal, chopping up the JVM into a hierarchical collection of modules), take a one-time-only backwards incompatible step of declaring the meaning of "java" to be limited to a set of modules that is smaller than what's on offer by rt.jar right now, taking out a bunch of fluff like corba, but also core stuff like swing and awt, and, yes, reflection, invoking child processes (ProcessBuilder and friends), because it requires the host platform to have certain capabilities that not all host platforms in the world have. Then, modules which aren't part of the core set are nevertheless organized in a hierarchical tree with generic platform capabilities as requirements. So, not so much one module to do windows file system management, and another to do linux file system management, but one module for file system management that should aim to work on any host platform that has file system management that works roughly like PCs do file management, and then modules on top of that specifically for windows and for posix. One could argue even threading and networking should be taken out, especially if you want to arrive in a world where "core java" means: This will run on a $5 arduino-like system. That doesn't have networking and threading and probably never will, certainly not with complete support of everything in java.net and java.lang.Thread*. Android could then simply be standard java with the extra modules related to networking, threading, and perhaps gfx manipulation, with the option to ship directly as dalvik executables just for efficiency's sake. The community could then legitimately attack google for deviating from the standard and needless forks, though I doubt they wouldn't have done that. Its obvious to me google did what they did because vanilla j2se is not or was not feasible when android was developed. They did it out of need, not for other reasons. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
