Hacker News Reader

Comment by cfcosta | Hacker News Reader

Because Sun (or oracle, I'm bad with time) decided to forbid MS to keep developing their own implementation.

Rightly so. They added all kinds of things that only worked on the MS JVM, which was the "extend" of their EEE strategy, right before extinguish.

Those things were almost all things that you could ignore if you weren't trying to specifically make a program for Windows, and that if you were trying to make a program specifically for Windows made it a lot easier and made the resulting program a lot better as a Windows program.

If Sun had blessed Microsoft's approach and encouraged Apple to do similar for Mac and done similar themselves for Solaris and encouraged someone to do similar for Linux then Java could have become a major language for mainstream desktop applications rivaling C/C++ or perhaps even becoming the most common language for such development.

But Sun didn't want you to be able to write for Windows or Mac or Linux using Java. They wanted you to write for the Java platform which happened to run on Windows and Mac and Linux.

And so Java desktop apps were almost always inferior to desktop apps written in C/C++/Objective C that could make better use of the native GUI and other facilities and did not stand out as some weird ugly alien thing.

They altered things in the java.* namespace [1], making it easy for developers to make things incompatible, as well as leaving out support for cross-platform enabling stuff like JNI and RMI. I can't read those actions as in good faith.

[1] https://www.infoworld.com/article/2077055/what-does-sun-s-la...

J++ was the final straw for me. I realized it’s sole purpose was to screw over Java. Not to be useful. Spent last 20 years avoiding Microsoft tech after that.

The cool thing about MS's JVM is that it made Java GUIs look exactly like native Windows Apps. I remember thinking it was a fantastic idea.

Unfortunely the new generation seems not to have any issue with Android Java being Google's J++.

> Unfortunely the new generation seems not to have any issue with Android Java being Google's J++.

Perhaps that's because it is not? Google aren't adding packages to the java.* namespace, and the language is 100% compatible with Oracle's compiler. Only the bytecode format and runtime are different, but that's no worse than how J2ME was, with SonyEricsson/Samsung/$OEM having their own custom packages (which Sun/Oracle approved of.)

edit: preempting another argument: limiting support to an old version of software/language spec is not a crime, though I'd be happy if Apple could be compelled to update the GPL software they bundle to the latest version (:

> Google aren't adding packages to the java.* namespace, and the language is 100% compatible with Oracle's compiler.

It just shows how little experience you have porting anything beyond Java 7 into Android Java.

> Only the bytecode format and runtime are different, but that's no worse than how J2ME was, with SonyEricsson/Samsung/$OEM having their own custom packages (which Sun/Oracle approved of.)

Yet that is the whole sales pitch of Android that it isn't as fragmented as J2ME was.

Also you missed the part of SavaJe OS being on the path for making SE available on mobile and Java 8 introduced Embedded Compact Profiles, whose APIs aren't fully available on Android to this day.

They lie to the public that they use OpenJDK, when the truth mirrored on Gerrit code reviews is that they cherry pick features, tracking down which Android version supports what from Standard Java is a painful detective work.

To add to it, the fellowship of Kotlin cleverly misuses their broken Android Java to sell Kotlin features, instead of comparing it with the real deal.

Reply on news.ycombinator.com