Footnotes to the OP: * It might seem like you need to eliminate java.lang.Runtime itself from guaranteed "java", because it contains "exec" which involves invoking child processes, which should clearly be a separate module not in the requirements list for calling yourself "java". But that's not actually necessary; exec() can simply be javadocced to state that it is a wrapper around the stuff in the child processes module, and that it'll fail with a specific exception when this module isn't available at runtime. This change is spec-wise backwards incompatible (because before this, the spec didn't say this could happen), but real- world-wise, nothing changed. When you can't invoke child processes, you can't invoke child processes. The spec can claim that you should be able to do so, but that can't very well affect reality. It would also be nice if java introduced an official @Obsolete annotation which can then be applied to Runtime.exec, Vector, Hashtable, and many other methods which currently will never be marked as @Deprecated due to various reasons unrelated to the notion that these classes and methods are indeed obsoleted.
* While jigsaw allows split packages, Oracle should separate out any code that currently resides in java.awt and javax.swing which doesn't actually require a GUI into separate packages, and then make existing methods in java.awt and javax.swing wrapper calls. This way i.e. painting a bunch of pixels into a byte array and then calling on a standard part of java to turn this into a jpg or png can be done without having to know exactly which bits of java.awt and javax.swing are available in a module named "graphics manipulation" without having access to the "swing" or "awt" module. Easier that way. * A third issue between Oracle and Android is that android uses harmony, which is a re-implementation of many things in core. They are spec-compatible, in that the re-implementation passes the TCK, or so I hear, but you might run into different behaviours especially if you write buggy code. At any rate, the core libraries should, as much as possible, be stated in the form of interfaces. Fortunately a lot of java already works that way. * It's not really google that made the decision to deviate from standard java so much. Android was developed by a separate company which google later bought. On Sep 12, 6:11 pm, Reinier Zwitserloot <[email protected]> wrote: > 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 [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.
