VM-less Java? That would be, compiled to native code? Not that that wouldn't make sense in Windows world, but I don't think that's the current line from Bill & co. either. Not yet, anyway. The line has always been portable bytecodes with native OS calls, which always has me scratching my head.
Actually, VM-less Java makes sense in more than just Windows world, assuming your not passing classes over a network. A just-in-time compiler kinda does that already. IBM has a high-performance compiler for windows and OS/2 (maybe other platforms as well) which compiles a set of java classes into a binary executable that calls a special DLL.
I am writing a large project in Java and am using none of the dynamic loading, RMI, internet etc.. stuff. I'm just using it because it's a fantastic language to program in. I'd love for the damn thing to be compiled directly into machine code.
As far as Bill's portable bytecodes with native OS calls, well, the portable bytecodes slow you down and the native OS calls break the security model. The worst of both worlds. Of course, much of the current Java implementation is portable bytecodes with native OS calls underneath (that's how the windows get drawn, the connections get made, the files get loaded..). So it's not that Bill's doing something different, it's just that their goal is going to be to create so many new API's for Java on Windows that nobody will be able to mimic them on other OS's. Perfectly legal, as opposed to their subtle changes of the standard class files, which seems to be very illegal. |
