Doesn't sound like it's Java, per se.

Sounds like issues with Java on Solaris:

One of the problems, he claimed, is that while Java has a lot of benefits compared to C and C++, its implementation on Solaris makes it difficult to deliver reliable applications.

Sun engineers think that Solaris gets in the way of implementing many software applications. The problem is widely recognised internally.
...
The memory footprint on Solaris machines is rather large, it appears.

Now, with regards to this:

One problem is that every Java program relies on the installed Java Runtime Environment, and when packages are issued every four or five months, they destroy existing packages and can't be back-graded to the prior install.

I can only say that I've seen issues going the other way (ie. writing for 1.3 when 1.2.2 is all that's installed), but never going forward in releases. TMMV, apparently. Typically what works best is targetting a release (1.2.2, or 1.3.1, for example) and sticking with it until some compelling addition balances the ROI towards upgrading.

On the memory issues in general: it's quite easy to write a Java program that uses a lot of memory. It's not that hard to make sure it doesn't, however.

Meta: Poorly written article, IMO, the way it jumps around. The Inquirer doesn't hold a candle to The Register. They tend to post more sensationalistic stuff at the expense of credibility and quality, IMO.

Post #79,296 by admin 2/4/03 4:39:09 PM Reply	Doesn't sound like it's Java, per se. Sounds like issues with Java on Solaris: One of the problems, he claimed, is that while Java has a lot of benefits compared to C and C++, its implementation on Solaris makes it difficult to deliver reliable applications. Sun engineers think that Solaris gets in the way of implementing many software applications. The problem is widely recognised internally. ... The memory footprint on Solaris machines is rather large, it appears. Now, with regards to this: One problem is that every Java program relies on the installed Java Runtime Environment, and when packages are issued every four or five months, they destroy existing packages and can't be back-graded to the prior install. I can only say that I've seen issues going the other way (ie. writing for 1.3 when 1.2.2 is all that's installed), but never going forward in releases. TMMV, apparently. Typically what works best is targetting a release (1.2.2, or 1.3.1, for example) and sticking with it until some compelling addition balances the ROI towards upgrading. On the memory issues in general: it's quite easy to write a Java program that uses a lot of memory. It's not that hard to make sure it doesn't, however. Meta: Poorly written article, IMO, the way it jumps around. The Inquirer doesn't hold a candle to The Register. They tend to post more sensationalistic stuff at the expense of credibility and quality, IMO. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #79,772 by tablizer 2/6/03 3:45:32 AM Reply	blows with the flows "The memory footprint on Solaris machines is rather large, it appears." The stupid engineers are thinking like engineers again. It is probably to Sun's benefit for Java to be bloated on Sun boxes. Sun is mostly a hardware company. Bloated software == hardware sales. So, those naive engineers should shut up and be glad they still have a job. Sun does not make much money on Java. The biggest lesson that I have yet to fully learn: "Go with the flow, even if the flow is stupid." ________________ oop.ismad.com
Post #80,480 by Arkadiy 2/9/03 9:02:45 PM Reply	We ended up shipping entire Java dev environment, compiler and all. Our consultants used Tomcat/Jacarta to deliver a web GUI. OUCH! -- We have only 2 things to worry about: That things will never get back to normal, and that they already have.

Welcome to IWETHEY!