• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Sun's own engineers find Java "impractical"

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Calling the original piece an "article" is way too forgiving. =)

XZeroII's rubber-stamp commentary to the article demonstrates he's just trolling, and nothing more.

As for the resulting debate once this thread was moved from OT, the Java platform (including the language) itself is very well suited for client application development, bar two crucial problems:
  • The Swing UI is still not on par with native toolkits. Roughly speaking, it suffers from the same problems as Mozilla's XUL.
  • Sun's JVM startup time is too long. But apparently, MacOS X has fixed this problem with a shared memory architecture, and the solution just need to be backported to other architectures.
The MS VM demonstrates you can write a JVM that starts up fairly quickly. Or you could at least cheat the way IE or Office DLLs are preloaded; I'm sure the .NET Framework is no different. =)

I also wonder why there isn't a spec for a single JVM to run compartmentalized client apps in the same veign as web apps. The main rationale I've read is that discrete JVMs simply provide better reliability and protection. And believe it or not, UNIX boxes supposedly achieve better per-system scalability when running multiple JVMs, one per required service.
 
Originally posted by: Shazam
Yea, I program quite a bit in C++. If you need cross-platform & cross-compiler compatibility, you should pic your libraries with more care. If you do, C++ can be very cross-platform, but with a recompile of course. If I statically link on my platform, I don't have to worry what libraries somebody has when I give it to them
Well, it seems just a little funny that you'd rag on Java's supposed lack of portability (which is untrue) when with C++ you have much larger problems.

One difference in particular, is that for compiled languages, portability is the developers problem, while for Java, in my limited experience, it is the end-users problem.

But then, in my 'niche' the developers are often the end-users as well, and we generally have no problem writing portable apps. One notable project I work on runs on multi-processor SGI & sun boxes (using both gcc & native compilers), linux on x86 & alpha, mac, windows (gcc & VisualC++), and beowulf clusters. If it will compile with gcc -pedantic -ansi, it will probably compile anywhere.
 
One difference in particular, is that for compiled languages, portability is the developers problem, while for Java, in my limited experience, it is the end-users problem.
I honestly don't see this. Then again, I'm mostly in the J2EE world. I do have some GUI stuff written in Java (NetBeans, Forte, SmartCVS) that are quite nice that I have never had problems with in relation to the JRE version I am using.
 
But apparently, MacOS X has fixed this problem with a shared memory architecture, and the solution just need to be backported to other architectures

manly, could you explain this or provide a link? I'm interested in knowing what Apple has done to accomplish this.
 
Back
Top