Appeals Court Sides With Microsoft On Java

burgburgburg writes "Reuters reports that the three-member federal appeals court in Virginia ruled today the U.S. District Judge J. Frederick Motz erred when he ordered Microsoft to include Java with the Windows operating system. Fortunately, Dell and HP, the top 2 PC makers, have already decided to ship Java on the PCs that they sell. Apple, Red Hat and Lindows have also agreed to include Sun's Java." The ruling is available.

Comments

actually,

[Anonymous Coward]

i think Red Hat includes IBM's implementation, and Apple uses their own impl.

Re:actually,

[leifm]

Yeah, I thought that was the case as well. Doesn't Apple have the only Java implementation that doesn't spawn a new VM for each new app? I can't remember what the terminology for it was.

Re:actually,

[Anonymous Coward]

Not anymore. RedHat will now bundle Sun's Java implementation. I believe there's a link to this on Sun's website somewhere.
At my client's site, they had a symposium with the chief technologist from Sun, Brian Wilson, a couple of weeks ago and he announced the agreement between RH and Sun.

Re:actually,

[Steveftoth]

No, they still spawn a new VM for each new app, you can't get around that limitation. Too many of the core classes are coded in such a way that you cannot get around that. (it's because of the static member variables)

However, Apple's vm is basically sun's VM with some enhancements. First of all there's the Java-Cocoa(Objc) bridge that lets a developer write a java backend with a Obj-C native Cocoa front end. Secondly, the feature you may have heard about that saves much time and reuses code is that the VM caches on disk the HotSpot compliation of the Java byte code. The way it works is that Java code is compiled to JAva byte code by the developer. The VM then compiles byte code to it's own internal representation for eventual compiliation to native code. This code is normally intrepreted, but when a section of code is 'hotspotted' it is then compiled to native code. Apple modified the vm to save the internal representation of the bytecode to disk and use this in the VM. This is automatically done for all core classes at install time and on the fly for other Java code.

Sun is supposedly looking into a way to extend it to other applications. Though only in client application does this make much difference because in server applications classes don't get loaded a lot. (except for JSPs but you really shouldn't be doing cpu intensive stuff in the JSP code, but in a library function)

Re:actually,

[shawnce]

Apple's implementation does start up a new JVM instance for every applet/application but the JVM's all use shared code and loaded jar instances. So it is like starting up a new task which links against the same set of shared libraries/frameworks as other tasks.

Additionally Apple provides, by default, installations of 1.3.1 and 1.4.1 in a fixed and standardized location, generally following the deployment style other the frameworks provided on the system. They are also updated automatically as needed via the normal Apple Software Update process, just like any other framework/application/etc...

They go out of their way to discourage application developers from installing their own JRE's, it is not needed, it wastes space, and actually could lead to compatibility issues (the JRE they install could be in compatible with the OS version installed, etc.)

Apple tests and maintains correct versions of their JREs for you, they are considered as part of the OS. This is very nice. Why should Java be different then any other OS framework?

I do find it funny that it is worded as saying that Apple has "also agreed to include Sun's Java". Apple goes out of their way to provide Java on Mac OS X, its Apple's JVM/etc. implementation not Sun's.