Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Even Sun Can't Use Java

CmdrTaco posted more than 11 years ago | from the frighteningly-honest dept.

Java 833

cowmix writes "It turns out that Sun does not eat its own dog food. Specifically, this internal memo from Sun strongly suggests that Java should not be used for Sun's internal projects. More interesting still, they go on to state which other languages fullfil Java's goals better than Java does itself. Finally, the memo states Sun's own Solaris is the cause of many of Java's woes. Yikes."

cancel ×

833 comments

Sorry! There are no comments related to the filter you selected.

FIRST POST (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5263777)

Please, god, let me have it!

Boom boom boom (-1)

MAKE IT STOP ARRGGHH (644754) | more than 11 years ago | (#5263819)

Those are the drums of war shitheads! Time for the U.S. to open up a can of kickass and kill 'em all! Let the bitch devil allah sort 'em out in hell!

2nd post (-1)

Anonymous Coward | more than 11 years ago | (#5263782)

so that's why they call it slowaris

It would be interesting to find... (4, Funny)

BitwizeGHC (145393) | more than 11 years ago | (#5263784)

... a memo which says that Sun has standardized on C# and Microsoft .NET.

Re:It would be interesting to find... (5, Funny)

Anonymous Coward | more than 11 years ago | (#5263818)

And equally as unlikely. You think the JRE is bad - have you seen how Microsoft's .NET runtime performs on Solaris?

(Blah... blah... Mono... Free... chasing a moving wall in order to pound your head against it...)

Re:It would be interesting to find... (0)

Anonymous Coward | more than 11 years ago | (#5263842)

That has got to be one of the funniest qutables I have heard in a long time. :)

Hypocrisy? (3, Insightful)

amigaluvr (644269) | more than 11 years ago | (#5263789)

This smells bad. Sun have been forcing the monopoly thing down microsofts throat for so long, and now there they are victim of themselves again.

What took them so long to come out with this? It seems to have stayed nicely hidden while they could cause damage to microsoft. Looks like they're a lot more relaxed now it's 'home turf'

'home run' indeed. They're now able to disassemble java like they wished to for a while it seems, but wanted to get most leverage out of it against a competitor

Commercialism stinks

Re:Hypocrisy? (2, Insightful)

frleong (241095) | more than 11 years ago | (#5263817)

This smells bad. Sun have been forcing the monopoly thing down microsofts throat for so long, and now there they are victim of themselves again.
This boils to the question: is it a good thing to force the bundling of the Sun's JRE in Windows? MS's JVM is not particularly bright, but I don't think JRE is better in terms of performance.

Anyway, regardless of the JVM, applets are only applets. Its security model prevents it from doing anything useful than pretty animation and fancy UIs. But for fancy UIs, we have Flash, which is definitely faster and easier to program.

Re:Hypocrisy? (3, Interesting)

kisrael (134664) | more than 11 years ago | (#5263845)

Anyway, regardless of the JVM, applets are only applets. Its security model prevents it from doing anything useful than pretty animation and fancy UIs. But for fancy UIs, we have Flash, which is definitely faster and easier to program.
I think the primary interest here is "server side Java", doing heavy lifting business applications. Currently Java/J2EE is in a competition with .Net ... in a race that has strong parallels with and implications for Unix/Linux vs Windows on the server side.

This memo makes me a bit nervous. Right now, I'm a Java/Perl guy professionally, and this is horrendous publicity for Java, and could pontentially tarnish Unix as well, since Java is so popular for business apps there.

(Applets seem to have kind of fallen by the wayside, though they seem to show up in more places than you'd expect...I can't do applets at work, it pops up a message about the firewall config, and I see that dialog a heck of a lot.)

Re:Hypocrisy? (0)

Anonymous Coward | more than 11 years ago | (#5263931)

I've always been surprised that Java doesn't decline on it's own. At work, I've had the problem they talk about where I've had to load 2 or 3 jvm's on a machine for the various pieces of software. That and the fact that the garbage collector in 1.3 sucks have largely turned me off of ever really learning the language.

Re:Hypocrisy? (0)

Anonymous Coward | more than 11 years ago | (#5263939)

At least they are honest and addressing it.
i dont belive ms will ever say anything bad about
c#.(their os, web server, etc)

They will continue to lie and point fingers at java.
so will other suckers.

ct

Finally. (1)

termos (634980) | more than 11 years ago | (#5263793)

Finally, the Cobol and Intercal developers have a chance on "the compiler market". ;-)

Kiss and say goodbye to Java language!! (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5263794)

No Java, no JSP man. Simply use PHP for web development.
Forget Java man and go to PHP!

PHP is 4 times faster than Java technology 'JSP' (Java server pages).
This tallies because compiled "C" program is 4 times faster than Java.

Moreover, PHP is getting the object oriented features of Java language.

The real usefulness of Java is 'Java applets' which run on client browsers but on the server side you simply use PHP.

PHP is a very lightening fast object oriented scripting language. PHP is 100% written in "C" and there is no virtual machine as in Java. Nothing can beat "C" language ("C" is a language which never dies!!)

(Java is just another language. The PHP project needs millions of Java programmers who can add the Java's language features like inner classes, static, private, protected and others to PHP. PHP already has some of java' features).
Java programmers will really "LOVE" PHP as PHP class is identical to Java's class keyword.

Read the benchmars of Java JSP and PHP. PHP tops in the speed!!

Read the doc here [linuxdoc.org] and mirrors at [1] [redhat.com] , [2] [ucla.edu] , [3] [gatech.edu] , [4] [caldera.com] .

OO PHP (0)

Anonymous Coward | more than 11 years ago | (#5263843)

Every language erver made has had OO shoehorned in at some point. Look how many are successful.

Re:OO PHP (1)

Ponty (15710) | more than 11 years ago | (#5263899)

Only the really good ones like Object COBOL [microfocus.com] .

Re:Kiss and say goodbye to Java language!! (0)

Anonymous Coward | more than 11 years ago | (#5263846)

PHP is a language for people who are too dumb to program. Most PHP programmers I know use it because the cannot program well enough to use a real language (with strong typing, etc).

Bah, BS (0)

Anonymous Coward | more than 11 years ago | (#5263934)

It may be easier to get started in PHP than java, sure, but to say it's only "a language for people who are too dumb to program" just reveals you for what you are -- nooobie.

If you really think a language is better because it's paradigms are more difficult to understand and take longer to work with, I won't be hiring you any time soon.

Java hasn't payed off on it's promises. The few minutes of time it saves by preventing an aliasing or typing error here and there aren't worth the awkwardness and verbosity.

PHP is very nice for front-ends, sure... (1)

Vengeance (46019) | more than 11 years ago | (#5263860)

But that's the least of my concerns as a Java developer. Where I'm doing most of my work is on back-end data access systems, running on J2EE servers. Access my stuff with Java, with PHP, or with a .NET client, I really don't care...

So the speed issue for PHP vs. JSP doesn't matter to me. What I care about is how big the VM gets, and whether or not I'm going to have backward compatability when my app. servers get upgraded. Give me a PHP-based application server, and yeah, I'll be happy as a clam. But I haven't got the time or the inclination (or the skill) to go and build one myself.

This is not informative. It's cheap flamebait. (0)

Anonymous Coward | more than 11 years ago | (#5263863)

see above

Re:Kiss and say goodbye to Java language!! (1)

Darth Maul (19860) | more than 11 years ago | (#5263864)

I've been using PHP for web development for three years now and I must say it is the only way to fly. I can't believe how people still wrangle with ASP and Java when PHP is so easy and fast.

Re:Kiss and say goodbye to Java language!! (0)

Anonymous Coward | more than 11 years ago | (#5263870)

There's a lot more to Java than JSP. That's like saying, "Don't use Java, Flash is much better for building applets."

My development team uses Java for large-scale web applications and web services. For that, along with several other technologies, Java is indispensable. Using a single servlet entry point, we've built our own application server framework based on XSL page templates, XML page configuration files, reflection, and JDBC.

Granted, we had to do a lot of performance optimization to get it to run on the inefficient Solaris Sun JVM, it is quite fast on servers running other OSs with IBM's JVM. And I don't need to remind you of the experiment used to show that the number of Java development positions open is still strongest out of the major languages, even given our current economic climate.

Re:Kiss and say goodbye to Java language!! (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5263885)

You're a moronic troll who knows nothing about how compilers/interpreters work. You're quoting HOWTOs as benchmarks. You can't spell. You sound like some horny 14-year-old social reject, who'll never in his life see bare breasts unless paying for them over the intarweb. You live in your parents' basement, and you're a disgrace to mankind.

"PHP TOPPZ IN TEH SPEEDZ! JAVA SI TEH pwned! I PROGRAMMEDD IN TEH "C" ONCE AND IT WAS HELLAZ L33T!"

The fact that you actually got moderated up speaks volumes about what a shithole this place has become.

death to JavaScrap (-1)

Anonymous Coward | more than 11 years ago | (#5263891)

As an end user, I have to say I absolutely despise web sites that use Java, Javascript, ActiveScrap, and all the other useless, mutant languages. And using javascript to make a link work instead of an A tag? Please, who is signing the paychecks of these morons?!

PLEASE stick with php, it works.

Re:Kiss and say goodbye to Java language!! (0)

Anonymous Coward | more than 11 years ago | (#5263897)

LOL

Can you imagine that there are people who do a little more than just generate HTML with their programs? But what does a web developer know - most of them are proud to have mastered the extensive MySQL command set anyway... there is no room left for advanced programming knowledge ;-)

Re:Kiss and say goodbye to Java language!! (1)

Timesprout (579035) | more than 11 years ago | (#5263906)

You are seriously misguided if you think the real usefulness of Java is applets. The most prevalent useage of Java is on the server for enterprise level applications and development tools. This is not something you will ever use PHP for.

The point the memo was making is that there are issues with the JRE implementation on Solaris and that due to these limitations Java is not the wonder language which solves all development issues as some of the SUN marketing drones would have us believe, or PHP as the parent would have us believe. Having come across several of the issues mentioned in the memo I think its good to see an internal drive for resolution of known problems. Hopefully SUN might actually channel resources to address them now.

This is by no means the end of Java

Re:Kiss and say goodbye to Java language!! (1)

Jugalator (259273) | more than 11 years ago | (#5263947)

"Java is not the wonder language which solves all development issues as some of the SUN marketing drones would have us believe"

No, they don't even think it should be used in commercial apps. :-P At least not in Solaris systems, depending on how you interpret the memo.

Re:Kiss and say goodbye to Java language!! (0)

Anonymous Coward | more than 11 years ago | (#5263933)

PHP is good for its ubiquity...

Many servers already run it or can be convinced to run it with no problems.

But if you have the opportunity to roll your own server then you really should be using Zope [zope.org] .

Based on Python, the functionality of zope and the elegance of its implementation, really blows PHP away.

PHP will never fill the application server market the way that JSP does and
that Zope will.

If you want to see why PHP is good for quick and dirty little sites that want to be run cheaply on commodity hardware, but why JSP really rock - then check out the article on aceshardware [aceshardware.com] about the rationale of setting up a java based sytem.

PHP is great but after you use Zope you won't want to go back to PHP ever again.

Re:Kiss and say goodbye to Java language!! (0)

Anonymous Coward | more than 11 years ago | (#5263943)

PHP is 4 times faster than Java technology 'JSP' (Java server pages).
Yeah, it crashed when they ran it at 5x Java-speed....

Sun (-1)

Anonymous Coward | more than 11 years ago | (#5263795)

Their Bloated StartOffice and OpenOffice make fun of the elegence of *nix. Bring the install size to below 300mb and make it run on my p3-450.

Not Java but the Solaris JRE (5, Insightful)

Anonymous Coward | more than 11 years ago | (#5263797)

Read the article poeple, what their saying is that the JRE on solrais has huge significant bugs that need fixing!!

Re:Not Java but the Solaris JRE (2, Insightful)

Danta (2241) | more than 11 years ago | (#5263847)

Read the memo a bit more and you will realize that many of the problems they list out are inherent to the current state of the Java platform itself and not just the Solaris JRE.

Re:Not Java but the Solaris JRE (0)

Anonymous Coward | more than 11 years ago | (#5263865)

I here you, so many poeple just jump all over a post and dont even bother to really read the thing !

Re:Not Java but the Solaris JRE (4, Interesting)

Jugalator (259273) | more than 11 years ago | (#5263869)

I don't think the "bugs" with huge memory usage and general slowness is limited to the Solaris platform since I've noticed it while running Java applications on Windows as well, while using Sun's JRE. Many of the bugs discussed in the memo is connected to the JDK itself as well, and Sun is concerned with how many bugs are closed with the "Will Not Fix" status. Since the JDK is mostly the same on all platforms due to Java's nature, I'm pretty sure this is a cross-platform problem in many ways.

Desperate measure (5, Insightful)

Knacklappen (526643) | more than 11 years ago | (#5263921)

Reads to me like a memo that has intentionally leaked out into the open, trying to force Sun Management to act. Software Development Dept is clearly unhappy with the Solaris implementation of JRE and therefore stops all use of it, until is has been fixed. While the Java Dept does not seem to have too much hurry to do that (majority of cases closed - "will not fix".
What would you do in your own line organization, when you are the boss of one department and the boss of the other department just gives you the finger? And your superior is unable/unwilling to solve the conflict? You write a flaming mail to your superior's superior, threaten to withdraw any support for the platform your company is famous for and leak the memo into the open to get public support. This, of course, has to be done nicely so that no-one can blame you directly for it.

Re:Not Java but the Solaris JRE (5, Funny)

jcr (53032) | more than 11 years ago | (#5263958)

Sure, Java doesn't suck, it's just the JRE.

And communism doesn't suck, it's just all the implementations!

-jcr

Good this is being adressed (2, Insightful)

Danta (2241) | more than 11 years ago | (#5263801)

Well it is at least a good thing to see that this is now being adressed by Sun and no longer being ignored. I hope this is the beginning of a trend to focus a bit more on fixing existing problems rather than merely enhancing a broken base.

Re:Good this is being adressed (1)

Jugalator (259273) | more than 11 years ago | (#5263834)

Yes, but I wonder at what cost it will come to enhance Java to the level they're implying in this memo. That Java is slow and use a lot of memory comes as a price of the design itself with bytecodes and Just-in-time compiling. I heard that JIT compilers have really become advanced enough to be comparable to "regular" compiling, but this memo confirms my doubts...

I wonder if it's even possible to bring Java to comparable levels to C or C++ without performing a huge redesign of the language. And would that mean dropping platform independence?

Re:Good this is being adressed (4, Insightful)

Smallpond (221300) | more than 11 years ago | (#5263884)

HA HA HA HA HA HA

Addressed! You must never have worked for a large corporation. The
memo was written out of frustration because the problem has not, is
not and will not be addressed by Sun out of their typical beaureacratic
inertia. Even worse now that Sun has had layoffs. There is little
glamor in fixing things. People who want to keep their jobs will
be the ones adding new features and new bugs and making the
problem worse.

---
Lady Mondegreen, dead at age 54.

Weird. (0)

AndrewM1 (648443) | more than 11 years ago | (#5263802)

Weird. But what language does Sun plan to use? Visual Basic? C? C++? DirectX? QBasic? Any type of Basic? This is the problem that Sun will face. There are so many good languages out there, which one do you use? Java seems like a good language to me. Why throw away somthing good for somthing else. It's like the old saying "If it aint' broke, don't fix it."

java os (1)

Simon (S2) (600188) | more than 11 years ago | (#5263803)

maybe this is why they don't go on with their plan about a java os...
the idea was cute, but they are apearently not able to do it.

a simple question (-1, Troll)

jrs 1 (536357) | more than 11 years ago | (#5263806)

is this message a troll or is this memo one?

Is it fixable? (1)

jonhuang (598538) | more than 11 years ago | (#5263808)

Several times, they assert thier belief in Java's intrinsic goodness--is it a party line? Or are they correct in that it's the (solaris) implementation and not the plan?

OMG, "Hello World!" (1)

T-Kir (597145) | more than 11 years ago | (#5263809)

Hello World 9M

Bloody hell... Hello World takes a 9MB footprint, ouch!

If they're not recommending Java anymore, do you think they'll send a memo to the canteen telling them to stop stocking Java Coffee, just to get the point across... or would that be where they're making the most money concerning anything to do with the word "Java"? ;-)

Re:OMG, "Hello World!" (0)

Anonymous Coward | more than 11 years ago | (#5263840)

Still less then it would've been in .NET

Re:OMG, "Hello World!" (1)

theguru (70699) | more than 11 years ago | (#5263898)

The .Net compact framework is about 1.5Mb and applications have about .75Mb footprint.

Re:OMG, "Hello World!" (2, Funny)

Timesprout (579035) | more than 11 years ago | (#5263944)

Yes but they say hello to the entire world

Re:OMG, "Hello World!" (0)

Anonymous Coward | more than 11 years ago | (#5263953)

Lets see... on my old TRS-80, even counting that BASIC was in ROM (16K, actually 12K, but we'll even throw in the I/O space) and 6K for the LDOS system (Disk O.S), plus maybe (we'll be generous) 4K to actually run it (counting Basic stack/variable space, etc)...
16+6+4 = 26K.

And it takes Java 9MB?? Even Python at 1.6MB seems extreme.

Not *really* big news, but interesting (3, Insightful)

Jugalator (259273) | more than 11 years ago | (#5263810)

It's no big news that Java is slow and a memory hog in many cases, but the interesting part is that Sun themselves are getting customer relation problems from it now:

Customers and Field Engineers Are Noticing the Problem

"Customer said they have something like 450+ container servers and 80+ automator server for the Vitria system. So the estimation for the hardware RAM is around 9GB for USII machine and 14-15GB for the USIII machine."


Eep. ... and I wonder what this quote will now tell their customers:

"Within Sun, Java is not viewed as a satisfactory language for the construction of commercial applications."

Ouch.

Re:Not *really* big news, but interesting (2, Insightful)

MikeApp (151816) | more than 11 years ago | (#5263908)

"Customer said they have something like 450+ container servers and 80+ automator server for the Vitria system. So the estimation for the hardware RAM is around 9GB for USII machine and 14-15GB for the USIII machine."

So they are running 530+ copies of the JVM?! That's a bit like running a copy of Apache for every web page on your site. Seems like a design issue to me.

Not too surprised (4, Interesting)

ragnar (3268) | more than 11 years ago | (#5263811)

I program in Java routinely and I'm not too surprised that Sun knows about limitations in Java. This looks like a pretty straightforward admission that Java isn't the hammer to use with every type of nail, which is a good conclusion in my opinion. I think the Sun memo is more sensible than the Microsoft memo in 1998 which declared that Java would not be used on any web site under microsoft.com. I don't have a link handy, but I clearly remember it.

case in point: Volume Manager and Netbackup (1, Informative)

frankmanowar (583879) | more than 11 years ago | (#5263886)

I've never had a worse time in my entire LIFE than when myself and a few able techs and admins got together and tried to install Veritas Volume Manager (a SUN product) and Netbackup Business Server 3.2 on our Solaris 8 system. It was like helping a cow give birth to a calf, which then died mid birth. Our contract support - which is usually brilliant - was absolutely useless. After all requisit patchtes were finally installed, they themselves could not figure out what the problem was...I wonder if java being terrible and clunky on Solaris and providing errors they can't fix had anything to do with it???

~frank

Confused... (0)

Anonymous Coward | more than 11 years ago | (#5263812)

Just because they don't practice what they preach, who cares? We raise our arms up in rejoice if we discover that a server sponsored by Microsoft is running Apache but this is a bad thing? They're in the business of selling a product, not their opinion of the product.

See what happens... (2, Funny)

Steve G Swine (49788) | more than 11 years ago | (#5263813)

... if you let security concerns influence your development?

Hand the implementation to Microsoft, they can fix the problems this has...

... nothing new under the sun (2, Troll)

imperator_mundi (527413) | more than 11 years ago | (#5263815)

people spend far more time chattering about java than using software written with it...

maybe because talking about is the only field where java and c/c++ have the same performances.

Quick version: (1)

RawDigits (456594) | more than 11 years ago | (#5263816)

While java encapsulates many features not found in standard C/C++ it is still bloated and slow.

We will remain committed to selling large Sun Enterprise servers to power these applications, however we should be more practical internally.

Sun's Internal Argument (5, Insightful)

Jrod5000 at RPI (229934) | more than 11 years ago | (#5263820)

To me, this report seems to be the manifestation of a battle going on with Sun between the Java Engineers and the folks who integrate Java with Sun's other products. They went to the Engineers initially to explain the problems, but it didn't change anything. So they wrote a damning memo to management to force them to deal with the situation.
This isn't Sun saying to the world that Java sucks, its simply two groups within Sun saying that their official implementation needs to have a few bugs worked out.
-jrod5000

From the article... (4, Informative)

Whispers_in_the_dark (560817) | more than 11 years ago | (#5263825)


A study performed by an outside team appears to indicate a rough parity in performance between Java and a common implementation of another OO language called Python (see IEEE Computing, October 2000, "An Empirical Comparison of Seven Programming Languages" by Lutz Prechelt of the University of Karlsruhe). Both platforms are Object Oriented, support web applications, serialization, internet connections and native interfaces. The key difference is that Python is a scripting language. This means there is no compilation to byte code so the Python runtime environment has to do two things in addition to what the Java runtime environment does. It has to perform syntax checks and it must parse the ascii text provided by the programmer. Both of those tasks are performed at compile time by Java and so that capability does not have to be in the JRE.


Assuming the memo is for real, this is a real boon for the Python community, even though it gets the bit about bytecode compilation wrong (Python DOES compile to bytecode and one CAN take the bytecode and ship without source). The point about Python carrying its compiler with it is true but IMHO it is a feature, not a bug. It always bugged me that Java had no good mechanism to compile simple expressions on-the-fly.

I am, however, a little leary on the performance parity bit. Don't get me wrong, I love programming in Python, but I know from experience that it still costs a good bit to create all the dictionaries that are used for frame construction, global maniuplation, and object management.

Python is, however, fast enough for a great many applications. I'm just a little skeptical about it being quite as fast in certain aspects.

Where I saw something like that? (1)

gmuslera (3436) | more than 11 years ago | (#5263826)

In personal conversations with Java engineers and managers, it appears that Solaris is not a priority

Maybe within IBM talking about OS/2? Is nice to hire people to dig our own grave.

"viva la resistance" (2, Insightful)

ajole (132756) | more than 11 years ago | (#5263828)

This damned langauge will go one of two ways:

they'll fix it,
or it'll die (phase out, dehype, become far too slow and filled with awkward design mechanisms that it cannot survive any longer).

Re:"viva la resistance" (1)

Timbo (75953) | more than 11 years ago | (#5263837)

...or it'll get replaced by C#.. like it or not.

Re:"viva la resistance" (2, Interesting)

ajole (132756) | more than 11 years ago | (#5263873)

heh. Or J#. already used it. Like all of the MS languages/implementations, its fast as balls. I used it for a project last week simply because compiling a 7 class app took
amazing how Microsoft just decides to implement a language, and it outperforms the original by logorithmic factors.

What's the point? (4, Insightful)

CoderByBirth (585951) | more than 11 years ago | (#5263830)

This memo states that Sun believes their Solaris implementation of Java to be flawed.
It states the flaws; ie. which flaws should be fixed.
So?

A REAL "shocking memo" would be one in which the company goes out of it's way to not criticize it's own product.

Hey wait a minute ! (1, Informative)

Anonymous Coward | more than 11 years ago | (#5263833)

Did you "read" this, it says the problem is
"Solaris" not java itself !.

Re:Hey wait a minute ! (1)

Jugalator (259273) | more than 11 years ago | (#5263901)

You'd also see how many of the problem might give cross-platform problems. Perhaps that's why Sun themselves call their problem as "the Java Problem" and not "the Solaris JRE Problem" in the memo.

Re:Hey wait a minute ! (0)

Anonymous Coward | more than 11 years ago | (#5263964)

Actually, its the fact that according to the memo the Java team does not consider Solaris a priority. Gee... thats interesting, they don't consider their *own* OS a priority???

shoot self in foot, then head ... (0)

HealYourChurchWebSit (615198) | more than 11 years ago | (#5263835)



I always thought Sun made a mistake by not working with Microsoft when it came to Java -- especially with regards to Sun's . Some of the weaknesses I read in the article are exactly what Microsoft aimed at with their .NET architecture.

On a lighter note, "Mean Dean's Semi-Definitive Guide to Selecting a Programming Language [healyourch...ebsite.com] " describes the process of shooting yourself in the foot with Java as "The gun fires just fine, but your foot can't figure out what the bullets are and ignores them."

Re:shoot self in foot, then head ... (0)

Anonymous Coward | more than 11 years ago | (#5263957)

I always thought Sun made a mistake by not working with Microsoft when it came to Java

I think Sun's problem had to do more with Microsoft's version of "Embrace and Extend," which would have defeated the original purpose of Java and made it a platform dependent language (remember J++?). It's no secret that there's not much good blood between the two companies, and Sun sacrificing their sacred cow, Java, to the betterment of relations wasn't likely, given Microsoft's history with both friend and foe (whom theiy often made no disticntion amongst).

Unfortunately, I am not surprised (5, Interesting)

random_me (608957) | more than 11 years ago | (#5263838)

When people ask me about using Java, I always give them a simple answer: it is much nicer to program in then any other language that I use (except for API changes over different versions), but it takes way too much memory and is too slow for programs that I would use regularly.

The memo agrees with me and lists the huge memory requirements as the number 2 problem (number 1 is that Java programs require the JVM to run).

Considering that compiling Java into a native executable would seriously improve its performance (and remove the JVM requirement), I wonder why the memo doesn't discuss that possibility?

dog fooding is a microsoft phrase (2, Interesting)

walmass (67905) | more than 11 years ago | (#5263839)

Microsoft departments have to use their own beta products. Its internally called "dog fooding."

Do you find it just a little curious that the story contributor used that particular phrase? Methinks a Microsofty at work here. Nice job, cowmix.

Re:dog fooding is a microsoft phrase (1)

tftp (111690) | more than 11 years ago | (#5263881)

Do you find it just a little curious that the story contributor used that particular phrase?

No. The expression is quite common [catb.org] .

Re:dog fooding is a microsoft phrase (2, Informative)

frleong (241095) | more than 11 years ago | (#5263922)

Microsoft departments have to use their own beta products. Its internally called "dog fooding."
This guy uses the expression "eats its own dog food.". A google search [google.com] reveals that it is quite popular. I wouldn't jump to the conclusion that the submission came from MS.

Even Sun Can't Use Java? (0)

Anonymous Coward | more than 11 years ago | (#5263853)

I disagree.. The sun could use a nice big dose of coffee, why look how hot it is? We can land on the moon, send robots to other planets, but we just observe the sun and never share any coffee with us. No wonder we have solar flares. I'd be pissed off too.

Read the Article (5, Informative)

sparkhead (589134) | more than 11 years ago | (#5263856)

In the rush to bash Java, the summary here was totally off the mark. From the article:

A review of the problem indicates that these issues are not inherent to Java but instead represent implementation oversights and inconsistencies common to projects which do not communicate effectively with partners and users.

And it goes on to mention issues with Solaris. Nothing about Java itself being inherently problematic, just issues with certain implementation.

Re:Read the Article (1)

MagPulse (316) | more than 11 years ago | (#5263948)

I think it's a little weird that people are calling this an "article". It's supposedly an internal memo posted on the same site that hosted the fake id memo [theinquirer.net] about them punishing ATI for leaking the Doom 3 alpha.

Read the memo (2, Insightful)

brw215 (601732) | more than 11 years ago | (#5263859)

It has problems ON SOLARIS. These engineers do not complain about Java being broken as a language. They have a big problem with implementation of the JRE on one platform. They mention nothing about the linux dist, or the win32 dist.

Re:Read the memo (0)

Anonymous Coward | more than 11 years ago | (#5263883)

Not correct . If you read the entire memo, slowly, you will see that there are huge complaints about the problems caused by the way sun releases new packages and upgrades for Java-in a manner that's not in compliance with Sun's on standards for patch and version releases.

Re:Read the memo (2, Insightful)

Jugalator (259273) | more than 11 years ago | (#5263930)

They often speak of the JRE as "Java", such as here:

"Java has too large a footprint (both memory and disk image) and may not be installed on the customer's host."

And regarding if the Java itself is broken, they mention this, for example:

"Bug ID 4526853 describes a bug in Core Java which used to be an external module called JSSE."

I guess it depends how you interpret it, but it's written quite sloppily if they actually only talk about the Solaris JRE.

Please Read the Article!!!! (0)

Anonymous Coward | more than 11 years ago | (#5263862)

I wish people would read articles before the start flaming. Sun is not saying that Java is flawed!

What Sun is saying is that the Java Runtime Engine, as implemented on Solaris (whether its Solaris on SPARC or Solaris on Intel) is seriously flawed. In fact they go on to point out how the memory foot print for Windows is so much smaller than for Solaris.

What they are doing is asking their engineers to fix the Solaris implementation.

If any of you want to see an implementation of Java that rocks look no further than Mac OS X or perhaps even Linux!

PHP more productive (0)

Anonymous Coward | more than 11 years ago | (#5263874)

I'll second the idea that PHP is much more productive than Java for developing web apps, at least smaller ones.

I'm a long time WebObjects developer, and I recently did a couple projects in PHP. Although I was learning the language from scratch as I was implementing the project, development still went substantially faster than it would have using Java/WebObjects. And developing in WebObjects is generally faster than developing servelet apps. I've decided that database abstraction layers are annoying and result in frustrating workarounds at least as often as they save time and bugs. So it cancels out. The cross-tab reporting I implemented in a day in php would have been very annoying to accomplish in WebObjects.

The only caveat is you have to have the experience and the discipline to impose good organization/structure with PHP, or you may get bit hard with large projects that must be maintained. But then I've seen people build unmaintainable messes with WebObjects too.

I haven't had a chance to find out how PHP performs as the first project I did only gets a half million or so hits per day. I did some load testing and was pleasantly surprised, though. And that was using MySql on the same machine, and with a search engine also running on the same machine. Using an oracle tier I think it would do very very well.

FUD (1, Funny)

Anonymous Coward | more than 11 years ago | (#5263876)

this is more microsoft FUD. . . oh wait...
ok so its more SUN FUD. Sun is trying to kill java because its open source! hacker freedom!

Java Implementation (4, Interesting)

Detritus (11846) | more than 11 years ago | (#5263880)

I'd be interested in finding out what are the causes of the problems with Java. Virtual machines don't have to be pigs. When the IBM PC was first introduced, I wrote a lot of software in Pascal using the UCSD p-System. The applications ran comfortably on machines with a 4.77 Mhz 8088, 8087 FPU and 512KB RAM. Most of the applications and operating system were compiled into p-code, which is similar to Java byte codes. The p-machine interpreter was a small resident module written in 8086 assembly language. The p-code was actually more memory efficient than the machine code produced by conventional compilers.

It's a hoax (5, Informative)

Anonymous Coward | more than 11 years ago | (#5263887)

InternalMemos is notorious for running hoax emails. This email is no exception. It includes a number of inaccuracies and curious references. The comparisons with Python are just amusing.

Doing a quick search on the names, you'll note that there's no reference to the sender anywhere in Google, let alone associated with Sun. Most of the folks in the CC list do not have Sun email addresses. They're probably friends of the hoaxer. The Sun folks in the CC list include a JavaOne and a guy who has himself on the J2ME JSR.

I wouldn't hold out for Sun switching to Python. haha

J2SE is becoming bloated (5, Insightful)

mariox19 (632969) | more than 11 years ago | (#5263888)

I was especially interested in the part of the memo that talked about extensions being rolled into the main product. But, apart from backwards compatibility, I think it just makes learning the language more difficult.

I learned the language back in 1.3, and I'm amazed at how much more has been added to the 1.4 release. Sifting through the javadocs has become a bit more of a pain, but nothing someone already familiar with the language can't handle.

My concern is people who are learning the language. I think the API is becoming more and more overwhelming to future Java developers. Look how much fatter O'Reilly's Learning Java book has become!

A smaller J2SE with standard extensions to be downloaded as necessary makes better conceptual sense.

Gotta agree with you on that one. (2, Interesting)

Vengeance (46019) | more than 11 years ago | (#5263904)

The extension mechanism works well, they should allow it to do it's job.

There are two core problems here: One is that Sun's implementation of the JRE for Solaris is an even bigger hog than Java is naturally. The second is that the JRE in general has got too damn many built-in libraries. It's very convenient for me as a developer who uses many of the extensions anyway, but it's making the language much more intimidating to approach.

Political memos (3, Informative)

panurge (573432) | more than 11 years ago | (#5263902)

Being an old cynic, I suspect there are too many long words in this memo for it to have gone very far up the food chain. Who are these people and what is their access to opinion formers in management?

Not that I'm suggesting they are wrong, I have no way of knowing either way, I just think that producing memos like this - and getting them leaked - is probably not the smartest way of getting the declared objective.

Admission: I use Java. It isn't perfect. It uses too much memory. It isn't hugely fast. But the applications work and the amount of debugging we have had to do is a tiny fraction of what I would have expected with C++. Its suitability for a given project depends on a whole host of factors not considered in the memo, and it would not surprise me if, for some internal Sun projects, it was inappropriate in its present stage of development.

Re:Political memos (1)

jcr (53032) | more than 11 years ago | (#5263945)

Admission: I use Java. It isn't perfect. It uses too much memory. It isn't hugely fast. But the applications work and the amount of debugging we have had to do is a tiny fraction of what I would have expected with C++.

Talk about damning with faint praise! So, there's much less debugging to do with Java, than there is to do with the worst language in use today.

-jcr

Java problems not limited to development (1)

nemaispuke (624303) | more than 11 years ago | (#5263905)

Sun has chosen to make graphical tools in Solaris use Java over straight X/Motif binaries. An example is Solaris Management Console, the replacement for AdminTool. If you run AdminTool on Solaris 9 you get a warning (every time you run it) that it will be replaced. So you start SMC (which requires Web Based Enterprise Management to be running) and wait, and wait. SMC is a pig in both performance and memory utilization! Unfortunately for those who prefer a GUI for managing disks (Solstice DiskSuite), it is being replaced by Solaris Volume Manager (Solaris 9), which runs under SMC! Most of Sun's enterprise level management products extensively use Java and you would think somebody would have taken a look at how slow their products perform (unless they tested them on "the latest and greatest" and found the performance OK. I would like to know what their definition of OK is! Java works for some things, but it doesn't work for everything! It almost seems like management said "We created it, let's use it!" without realizing the performance hit, or just simply ignored it.

Article Text (-1, Redundant)

Anonymous Coward | more than 11 years ago | (#5263910)

The Java Problem
Author: Julian S. Taylor
Reviewed by: Steve Talley, Mark Carlson, Henry Knapp, Willy (Waikwan) Hui, Eugene Krivopaltsev, Peter Madany, Michael Boucher

Executive Summary

While the Java language provides many advantages over C and C++, its implementation on Solaris presents barriers to the delivery of reliable applications. These barriers prevent general acceptance of Java for production software within Sun. A review of the problem indicates that these issues are not inherent to Java but instead represent implementation oversights and inconsistencies common to projects which do not communicate effectively with partners and users.

Within Sun, the institutional mechanism for promoting this sort of communication between partners is the System Architecture Council codified in the Software Development Framework (SDF). We propose that the process of releasing our Java implementation will benefit from conformance with the SDF.

Introduction

This document details the difficulties that keep our Solaris Java implementation from being practical for the development of common software applications. It represents a consensus of several senior engineers within Sun Microsystems. We believe that our Java implementation is inappropriate for a large number of categories of software application. We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation.
We all agree that the Java language offers many advantages over the alternatives. We would generally prefer to deploy our applications in Java but the implementation provided for Solaris is inadequate to the task of producing supportable and reliable products.
Our experience in filing bugs against Java has been to see them rapidly closed as "will not fix". 22% of accepted non-duplicate bugs against base Java are closed in this way as opposed to 7% for C++. Key examples include:

4246106 Large virtual memory consumption of JVM
4374713 Anonymous inner classes have incompatible serialization
4380663 Multiple bottlenecks in the JVM
4407856 RMI secure transport provider doesn't timeout SSL sessions
4460368 For jdk1.4, JTable.setCellSelectionEnabled() does not work
4460382 For Jdk1.4, the table editors for JTable do not work.
4433962 JDK1.3 HotSpot JVM crashes Sun Management Center Console
4463644 Calculation of JTable's height is different for jdk1.2 and jdk1.4
4475676 [under jdk1.3.1, new JFrame launch causes jumping]

In personal conversations with Java engineers and managers, it appears that Solaris is not a priority and the resource issues are not viewed as serious. Attempts to discuss this have not been productive and the message we hear routinely from Java engineering is that new features are key and improvements to the foundation are secondary. This is mentioned only to make it clear that other avenues for change have been explored but without success. Here we seek to briefly present the problem and recommend a solution.

Defining the Java Problem

These are the problems we have observed which we believe indicate the need for an improved implementation and a modified approach.

1. The support model seems flawed
Since Java is not a self-contained binary, every Java program depends fundamentally upon the installed Java Runtime Environment (JRE). If that JRE is broken, correction and relief is required. This sort of relief needs to happen in a timely manner and needs to fix only the problem without the likelihood of introducing additional bugs. Java Software does not provide such relief.
Java packages are released (re-released) every four or five months, introducing bug fixes and new features and new bugs with each release. These releases are upgrading packages which remove all trace of the prior installed packages and cannot be down-graded in the event of an error. The standard release taxonomy used by the Architecture Review Committees (ARCs) was developed for use by Solaris and our other mission-critical software products to help solve these and many other problems.

It is impractical for a project based on Java to correct bugs in the Java implementation. Java Software corrects bugs only by releasing an entire new version. For that reason, projects seek to deliver their own copy of Java so they can maintain it without fear of a future upgrade. Outside vendors, such as TogetherJ, specify a particular release of Java for their product. The customer must locate that release and install it. If a future product seeks to use a different version, that version has to be installed side-by-side with the prior version or TogetherJ may no longer function.
The ARCs commonly see project submittals requesting permission to ship their own version of Java. The ARCs have been routinely forbidding projects to do this even though they are aware of specific cases wherein interfaces or their underlying behaviors have changed incompatibly across minor releases.
The threat of losing the ability to directly support such a substantial part of their product has inhibited projects from choosing Java as their implementation language and caused widely-discussed problems for customers of projects that have used Java. Consider that the Java language supports rapid development, simple testing and access to a wide variety of platforms. Why are the shelves at CompUSA (a Linux friendly store) not crammed with W32/Linux/etc offerings written in Java? As it stands client-side Java remains primarily a web language partly because the Netscape platform runs Java 1.1.5 and has not changed for years. It is buggy but very stable.

This indicates that Java must strictly enforce backward compatibility across minor releases and must adhere to Sun release taxonomy for the identification of releases. Further, existing releases must support some sort of remedy akin to a patch so that existing installations can be corrected through existing methods.

2. The JRE is very large.
The JRE is significantly larger than comparable runtime environments when considering resident set size (memory dedicated to this specific program). It has been seen to grow to as much as 900M. This has a drastic effect on both performance and resource usage. It also means that multiple JREs present critical resource constraints on the servers for such thin-client systems as SunRays. Typical resident set requirements for Java2 programs include:

Hello World 9M
SMC Server 38M
SLVM GUI 60M
Component Manager 160M
TogetherJ 300 - 900M

The largest program in that list is TogetherJ. From the standpoint of resource requirements, TogetherJ does much of what Rational Rose does but Rational Rose appears to function in less than 250M. Startup time is effected as well. For example, on an Ultra10 TogetherJ requires 5 minutes to load and start. SMC, Sun's flagship system admin console, takes between one and two minutes to reach the point that it can be used.
Some of this problem appears to relate to the JRE. We do not have the time or money to conduct a serious side-by-side study of Java vs other languages and are therefore calling upon our personal experiences with Java development. The fact that these experiences are hard to quantify forces us to try to support the validity of this concern through existing research.

A study performed by an outside team appears to indicate a rough parity in performance between Java and a common implementation of another OO language called Python (see IEEE Computing, October 2000, "An Empirical Comparison of Seven Programming Languages" by Lutz Prechelt of the University of Karlsruhe). Both platforms are Object Oriented, support web applications, serialization, internet connections and native interfaces. The key difference is that Python is a scripting language. This means there is no compilation to byte code so the Python runtime environment has to do two things in addition to what the Java runtime environment does. It has to perform syntax checks and it must parse the ascii text provided by the programmer. Both of those tasks are performed at compile time by Java and so that capability does not have to be in the JRE.
Given this data, it appears that the JRE can actually be simpler than the Python RE since Java does at least some of this work at compile time. The example above of "Hello World" is a good method for getting an idea of the minimum support code required at runtime. This support code includes garbage collector, byte code interpreter, exception processor and the like. Hello World written in Java2 requires 9M for this most basic support infrastructure. By comparison, this is slightly larger than automountd on Solaris8. The Python runtime required to execute Hello World is roughly 1.6M.

Further examples of what is possible include the compiling OO languages Eiffel and Sather which fit their garbage collector, exception processor and other infrastructure into roughly 400K of resident set. While the Java VM (as demonstrated above) grows rapidly as more complex code is executed, the Python VM grows quite slowly. Indeed, an inventory control program written entirely in Python having a SQL database, a curses UI, and network connectivity requires only 1.7M of resident set. This seems to indicate that the resident set requirements of the JRE could be reduced by at least 80%.

Imagine what happens if our current implementation of Java were ubiquitous and all 150 users on a SunRay server were running one and only one Java program equivalent to Component Manager above. The twenty-four gigabytes of RAM the server would have to supply exclusively to these users is well beyond the typical configuration. RAM is cheap but performance is what we sell, all customers on that SunRay server would see significant performance degradation even with the maximum amount of RAM installed as all other processes were forced to reside on swap.
The resident set size required by the JRE makes it impractical to run Java in an initial Solaris install environment. It is impractical to run it as a non-terminating daemon. A Java daemon could be started from inetd run long enough to do its job and then quit but the rpc protocol required to pass the socket port to the daemon is very complex and not Java-friendly. Java applications cannot be executed at boot time since the loading of the VM introduces an unacceptable performance degradation. If the Java runtime were as small as that of Python, it is likely that the Java daemon would become popular and could provide basic services to applications written in any number of languages.

3. Extensions do not support modularity.

As new extensions are introduced, they are released separately under their own names and distributed generally. Each one may go through several revisions as separate modules. At some point, they are then folded into base Java, tying base Java's version to the versions of dozens of smaller yet distinct functionalities. These functionalities are then restricted to a draconian backward-compatibility rule since once folded in, they are no longer selectable modules. Examples include modules that used to be called Swing, RTI, IDL, JSSE and JAAS. These are all good things that should be part of Java. Our concern is that these are not separable modules which can evolve as requirements change.
The Java system for evolving the interface (deprecation) does not serve production software very well. Once the interface disappears, the product just breaks. If the Java base were simpler and the more advanced features (those most likely to be deprecated) were delivered as versioned modules, it would be possible for a commercial product to retain it's older modules on the system and survive a large number of Java upgrades.
Production quality programs written in Java, like TogetherJ, indicate a specific Java version which must be installed before the program is run. If another program is installed, requiring a higher Java version, the user may be forced to decide which program stays and which goes away. Alternatively, the other Java version could be installed to a different base directory but this requires considerable sophistication on the part of the user, complicates administration and violates the ARC big rule that common software must be shared.

4. It is not backward-compatible across minor releases.

Among the various incompatibilities across minor releases are:
a) In JDK 1.1 Class.fields() returns only public variables. In 1.2, protected and private variables are returned.
b) Swing table sizing calculation changed from Java 1.3 to 1.4.
c) Swing JFrame launch behavior changed significantly from Java 1.2.2 to Java 1.3.1.

Each of these examples is simple, but they demonstrate the general problem that people cannot program for a particular release of Java and expect that their programs will continue to run. This is a serious problem now, but has the potential to become a show-stopper as technology such as auto-update advances.

What is perhaps more important is that the perception of Java as an unstable platform is widespread. This perception is restated with every Java-based project to come to ARC. Within Sun, Java is not viewed as a satisfactory language for the construction of commercial applications. This perception and the record require addressing.

The Java Problem is Recognized Internally

That our Java implementation is perceived as inappropriate for many uses is supported by internal documents and policies. For example:

1. SOESC AI - 092501.2 Java Dependencies for Deployment

In this document provided to SOESC, John Perry describes the concerns regarding the Solaris "JVM dependencies for deployment". Following is an excerpt:
-------
- Large footprint of applications when run on Solaris. A simple application ("hello world" type) has a total footprint of 35-40 megs on Solaris 9 (build 48, using Java 1.4 build 82) on both Intel and Sparc machines. Sparc machines, by far, have a much higher resident footprint then Intel machines (~30 megs, compared to ~11 megs). The same program run on a Windows machine has a footprint of ~5 megs, resident footprint being ~3.5 megs

- Slow start up times prevents Java applications from being started while Solaris is booting up and during mini-root time. This requires applications which are written in Java to have some kind of mechanism to start-up after the OS has been fully started.

- Instability of Native code (JNI) which can cause the entire VM to crash.
-------

2. Teams Are Looking for Options

The CIMOM (supporting WBEM) is a Java daemon. It initially occupies around 40M of RSS but grows from there. In order to address this problem, at least one Sun Engineer, Peter Madany, has been doing research to determine Java daemon memory utilization when running on a currently unsupported J2ME VM on Solaris. In other words, we are looking into demonstrating that resource exhaustion on Solaris Servers could be avoided by using some of the techniques used in an edition of Java intended for very small systems.

3. New Projects Explain Why They Are Not Using Java

Quoting from the recently submitted Nile case (SARC/2001/617) now under review:
-------
These libraries should be commercial implementations and must be in native platform code (ie not Java or Perl). Native code is a requirement because one of the core requirements for the proxy is for minimum impact on the target host. Java has too large a footprint (both memory and disk image) and may not be installed on the customer's host.
-------

4. ARCs Include the Java Problem in Rejection Reasoning

Quoting from the recently rejected SunMC PMA case (LSARC/2000/457):
-------
The CLI interpreter is implemented in Java, and the overhead of starting a JVM for each command execution is prohibitive. At least one of the votes to reject was related to this inappropriate use of Java. The Solaris implementation of Java is slow and very large. While this project did not provide a measurement of resident set for their CLI, the minimum RSS for the JVM is known to be 9MB and the typical RSS for a similar Java program is 30 to 40MB, and takes up to 15 seconds to start. The project team admitted in the review that this CLI may be used on a daily basis. For such a CLI, the delays and resource requirements of the Solaris Java implementation are unacceptable.
-------

5. Customers and Field Engineers Are Noticing the Problem

Following is an excerpt from Kevin Tay's e-mail to three Java aliases regarding a customer installation of a third-party product written in Java called Vitria. We see typical very large RSS numbers compared to a WinNT implementation combined with increased resource usage from Solaris7 to Solaris8:
-------
Customer said they have something like 450+ container servers and 80+ automator server for the Vitria system. So the estimation for the hardware RAM is around 9GB for USII machine and 14-15GB for the USIII machine. Questions:

1. Why is Sun systems using so much more memory?
2. Why is the UltraSPARC III/Solaris 8 system using a lot more memory than a UltraSPARC II/Solaris 7 system (with every other thing being equal)?
3. How can I reduce the memory utilization of the UltraSPARC III system?
-------
NOTE: The response to this e-mail was to suggest moving to a different build of Java 1.2.2 since the indicated build on Solaris 8 had a known bug; it should be noted, however, that the 9GB memory footprint for Solaris7 is still unusually large.

6. Close Call in Solaris9
Bug ID 4526853 describes a bug in Core Java which used to be an external module called JSSE. Among other products, PatchPro and PatchManager depend on the JSSE. As long as the module could be used, the JSSE interface could be trusted to remain stable despite extensive changes in core Java. Now the Java architecture makes it impossible to use the module. This bug in core Java completely disables PatchPro and PatchManager. It was introduced in build 83 of Java 1.4. It was detected and corrected before the final build of Solaris9. If it had not been detected before the final build, it would have shipped with Solaris9 FCS.

For those products that depend upon JSSE and operate on multiple OSs, there would have been no recourse except to deliver with their product an entire new Java distribution. This distribution would have to upgrade the existing Java installation. The fact that various products depend upon specific versions would mean that such an upgrade would carry the risk of breaking other Java-based software on the target system.

Correcting the Java Problem

We strongly recommend that management require Java to conform to the Software Development Framework especially from the standpoint of ARCreview. We believe that the next release of the Sun Java implementation should be brought to ARC while still in the prototype phase. Both PSARC and LSARC have dealt with the Java issues peripherally, recognizing numerous problems but unable to effect change in the underlying source of the difficulties - namely Java. By bringing the Sun Java implementation through ARC, these issues can be resolved.

Java defense... (1)

FlydinSlip (531842) | more than 11 years ago | (#5263915)

While some of their points are somewhat valid (ie, the Class.getFields() returning first all the public and then later the public, protoected and private fields), but I tend to think that changes to other classes are done not to make the developers' life more difficult, but to enhance flexibility or act as work-arounds for other either very subtle or very infrequent issues. No language is perfect, and Java is still a relatively young langauge.. Once Java has aged as long as languages like C has, I'd be one to bet most of these "incoveniences" will have been resolved.. As far as Sun developers not using it, that seems highly defeatist.. If you make a product that the world has practically adopted unconditionally, and it's activly used the world around, the only way to make it better is to use it, and find and fix the issues. 'Ya can't fix what you don't know is broken... Much of Java's bloat is due to the fact that at VM statrtup, it has no idea what you're going to do with your program, either Hello World or TogetherJ, so it needs to be ready for the worst-case. There's really no avoiding this. As mentioned, Java is interpreted bytecode. The threads are tied to the system to be real system threads -- this takes some time and resources to do and do right. True, a new version of the JRE over-writes the previous versions upon install. But isn't having a backup version on the system just good sys-admining? It's just a symlink, for petes sake...

So switch to Python.... (1)

Russ Nelson (33911) | more than 11 years ago | (#5263925)

The report itself points to the correct solution: switch to Python, since Python is implemented so much better than Java.
-russ

Sabotage (1)

RichiP (18379) | more than 11 years ago | (#5263926)

If they were at all aware that the memo would be leaked, it sounds like they're trying to sabotage Java. Perhaps they've realized that IBM is doing a better job of implementing Java and Java solutions.

At any rate, it sounds more like the death knell of Solaris.

Where's the proof? (5, Insightful)

MegaFur (79453) | more than 11 years ago | (#5263927)

How do we know this is even a real internal memo? I mean, this is comming froma site *named* internalmemos.com. Come on! There's a submission form. I could just send any old thing in if I wanted. The only difficult part is making it look convincing. That only takes a few hours of effort.

Anyone that has an axe to grind with Sun could have sent this in. That could be some big company or (far more realistic) some random slob that just wants to be mean.

Or it could be real. But who cares? As the Score 5 AC pointed out, this is about bugs in the JRE on Solrais, not necessarily about Java in general.

Does anyone on slashdot remember what FUD is?

I question the validity (4, Interesting)

sbuckhopper (12316) | more than 11 years ago | (#5263929)

Although it is well known that Java is a performance hog, and these bugs they talk about are real. And it is well know for anyone who has done extensive Java programming that the people who write Java have always put more emphasis on delivering the JDK and JRE's faster and more bug free for windows, I really do not believe that this memo has been sent or will be taken serisously if it has.

I have never directly worked for Sun, but I have worked with them in many ways and they have been using Java in production environments for a long time and I'm certain they will continue to.

They use it in Solaris 8 & 9. No one ever told me this, but it is not difficult to see this, login to a machine running that OS and start up their print manager, looks amazingly like the Java L&F.

If you've ever taken a training class from Sun, the survey that you fill out at the end of the class is a Java application. I worked at a training center for a while and we never had any problems with this application.

Friend of mine that work for Sun talk about where they are using Java internally and it is immense, there is no way that in the forseeable future any of this is going to change. I'm going to talk to them and see if this memo was really sent out.

My wife writes Java GUIs and actually has never ever had any of the problems that they are referring to in this memo. The GUIs she writes runs fine, and they are very complex GUIs, things that do tasks such as controlling telephone switches.

I'm not saying that Java doesn't have some performance problems by any means. I program in Java and I know a lot of peoplel who do and we've discussed these performance problems. I've also written hello world programs that don't take up 9M, but then again I question the validity of the programmer who wrote that program. I know if I write it bad enough, I could write a C program that would allocate 9M of memory and have the only functional thing it does is be to print out "Hello world."

So I guess this could be true, but as someone who has worked with Sun before, I find it very, very hard to believe.

Re:I question the validity (1)

Vengeance (46019) | more than 11 years ago | (#5263940)

Well, when they talk about a 9 megabyte 'Hello World', they're certainly not speaking of HelloWorld.class.

But take a pristine system with a fresh OS install, and install the minimal JRE needed to run 'HelloWorld.class' and get it's output onto the console, and then see how much disk space you've used up. I suspect it'll be pretty big. Especially if you keep the install .gz or .zip or whatever lying around!

*On Solaris* (0)

Anonymous Coward | more than 11 years ago | (#5263936)

If you'd read the article, you could see this applies to problems with the Solaris JRE, not Java itself.

Solaris 9 for x86 was delayed for quite a while to address some of these issues.

Ahh, Taco (2, Interesting)

Anonymous Coward | more than 11 years ago | (#5263941)


Please. Try to communicate the essence of the article in your summary.

The essence is, Sun has a buggy implementation of Java on Solaris that is scaring off internal developers.

The essence of your summary is, Java isn't usable, and Solaris is a problem. Duh, you missed the connection! It's Sun's *implementation* of Java on Solaris that's inadequate. The memo stresses that nothing's wrong with Java, and it doesn't suggest that anything's wrong with Solaris.

Why would you write such misleading over-generalizations? What's the motivation? C'mon, Taco!

Turf War (2, Insightful)

the eric conspiracy (20178) | more than 11 years ago | (#5263946)

This memo looks like a turf war to me. Somebody is ARC needs to justify his job, and has decided he can do it be getting his hooks into Java.

Goodbye PHP - Hello Zope (0)

Anonymous Coward | more than 11 years ago | (#5263954)

PHP is good for its ubiquity...

Many servers already run it or can be convinced to run it with no problems.

But if you have the opportunity to roll your own server then you really should be using Zope [zope.org] .

Based on Python, the functionality of zope and the elegance of its implementation, really blows PHP away.

PHP will never fill the application server market the way that JSP does and
that Zope will.

If you want to see why PHP is good for quick and dirty little sites that want to be run cheaply on commodity hardware, but why JSP really rock - then check out the article on aceshardware [aceshardware.com] about the rationale of setting up a java based sytem.

PHP is great but after you use Zope you won't want to go back to PHP ever again.

*please* read the f**king memo before posting (2, Interesting)

linuxghoul (16059) | more than 11 years ago | (#5263963)

The memo says that the JRE implementation on Solaris (not the implementation of SOLARIS itself)is a cause of many java problems, including

1) Large memory usage (cites an example of a "hello world" program using up 9MB)

and

2) Long startup times

the memo blames these problems in the SOLARIS implementation of java VM on the "fact" that that project doesnt seem to have prority. The memo states in passing that the win32 vm doesnt seem to suffer from these problems as much. So the memo specifically restricts itself to the solaris jvm.

It also talks about how the java vm doesnt confirm to the sun SDF, and thus the versioning is incomaptible with it. There is no support for patching an installed java vm, thus requiring an entire new install of the latest version of the jvm if a bug is discovered. This means either having multiple jvm installed and running if different java applications on a system need different java releases, or breaking a whole set of applications, which may not run with the latest release. Again, cites examples of these.

The memo makes a case for:

1)introducing a patch system for java vm, so there need not a a new install everytime a bug is discovered.

2) stict backward compatibility, so that an application written for the older version of JVM works with all later minor revisions

3) consideration of a new mechenism for "bsoleting" and interface replacing/in addition to deprecation.

4) priority for solaris jvm development, with claims (by comparing it with python!!) that the memory footprint of the java resident set (the code bloat added by the garbage collector and co to each running java program) maybe reducible to a fifth of its current size.

read the memo. its a very intelligently argued writeup, and has been completely misrepresented in the slashdot post.

very interesting read.

Ghoul2

Java No Cocoa Yes (1)

Glindonna (636715) | more than 11 years ago | (#5263970)

It's about time that the whistle was blown on this situation. Ironically, only Sun had the credibility to do so.

Java is a fine language with an great set of ready-to-use out-of-the-box classes . Unfortunately, the VM crisis and minor release incompaabilities render it USELESS for all but the most tightly controlled deployment situations. It is nearly impossible to support commerical apps on Java without torturing yourself and your customers.

What to do? Simple. Apple needs to open and get Cocoa running on Windbloze and Linux and we need to once and for all put a bullet in the head of Java as a desktop development platform.

There are so many corporate fiefdoms built on Java, of course, that this train wreck will go on for years before the final collapse. Make no mistake, however, it will collapse.

Cocoa or .Net. You decide. Java is simply not competitive. It's garbage and it's a dead end.

Glin
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?