Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> and are blessed by Sun/Oracle. I don't follow your argument

I don't have anything more to add than to quote you (the keyword is blessed) and also point to my previous posts. As long as you're forced to get the blessing before you introduce the interface to your own platform (or be forced to leave something out because you know it won't be blessed) why should it be in your interest to maintain the technology of others if you have your own technologies and a platform that's attractive even by itself?



From my own experience with it:

- .class files compiled on Apple's JVM work fine on other JVMs

- Source code written for Apple's version of javac will compile fine on other Java compilers.

To my knowledge, Microsoft's JVM violated both of these requirements, which was Sun's bone of contention. (Android's Dalvik is in similar violation, but doesn't pretend to be "Java" - they're being sued based on patents IIRC)


> .class files compiled on Apple's JVM work fine on other JVMs

Technically, you don't need to compile "on JVM" but "for JVM." And it doesn't seem to be as you describe for most of the cases (in Sun's words, 98%).

> Microsoft's JVM violated both of these requirements

AFAI understand it was far more subtle: the language (the source form representation) was extended with the features which functioned only on Microsoft's implementation, and only such classes were affected. See

http://download.oracle.com/javase/1.4.2/docs/guide/deploymen...

for a list of issues of switching from Microsoft VM based upon Java 1.1 to Sun's 1.4.2. The list appears to be very unimpressive.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: