Forgot your password?
typodupeerror
Java Programming

Even Sun Can't Use Java 833

Posted by CmdrTaco
from the frighteningly-honest dept.
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."
This discussion has been archived. No new comments can be posted.

Even Sun Can't Use Java

Comments Filter:
  • by BitwizeGHC (145393) on Sunday February 09, 2003 @09:51AM (#5263784) Homepage
    ... a memo which says that Sun has standardized on C# and Microsoft .NET.
    • by Anonymous Coward on Sunday February 09, 2003 @09:59AM (#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...)
    • by g4dget (579145) on Sunday February 09, 2003 @10:54AM (#5264109)
      Given that Mono looks like it may become an important part of Gnome, Sun may be shipping a C#-based desktop before they have a Java-based one.

      It boggles the mind that after half a dozen years of Java, Sun has not yet moved their default desktop over to Java GUI apps. And Sun has missed lots of great opportunities popularizing Java by failing to deliver desktop apps and utilities that would motivate Windows, UNIX, Linux, and Mac users to download the JRE.

    • by Anonymous Coward on Sunday February 09, 2003 @12:39PM (#5264710)
      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
      • by MikeFM (12491) on Sunday February 09, 2003 @02:49PM (#5265480) Homepage Journal
        Julian.Taylor@central.sun.com is the address Google came up with for me. Not sure if it's the right one. Seems close enough though.

        Since when are memos technically correct? You must work at a lot geekier place than I have. Not that I think InternalMemos isn't notorious for hoaxes.

        I wouldn't hold out for Sun to switch from Java to Python either but I really wish they would. Java blows. Python is easier to develop (fewer required tools etc) and runs a lot better under both Linux and Windows. Python (with wxPython) produces nicer looking more functional gui programs to.
  • Hypocrisy? (Score:3, Insightful)

    by amigaluvr (644269) on Sunday February 09, 2003 @09:52AM (#5263789) Journal
    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? (Score:5, Insightful)

      by Zeinfeld (263942) on Sunday February 09, 2003 @11:01AM (#5264136) Homepage
      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.

      The note is certain to be used by Microsoft in their appeal against the Java injunction.

      In particular the points about Java code being tied to a particular runtime completely negates Sun's claims about the need to distribute in the O/S base. Clearly that is not going to help much since Sun have no clue about dependency management.

      Consider the following thought experiment. Microsoft distribute 30Mb of Java 1.3 with XP. Then Sun upgrade to 1.4, what does Microsoft do? Do they distribute 1.4 on the new O/S versions only, add it to the current release of XP or put it on instant update. None of these work. The instant update option will break existing java applets on the system. Mixed versions of java will mean that consumers buying a Java based progam will not be able to rely on the release number of XP to decide whether the program works on their machine. Waiting till the next O/S version is released will result in a lawsuit from sun.

      The note shows clear similarities to the early articles on C# explaining the difference in approach between Java and dotNet. If the Java lobby was not so convinced that Java was the end of program language design they would have realised their significance.

      To give one example, the version incompatibility problem is known to Windows developers as 'DLLHell'.

      My company uses Java for a lot of projects. I would not be suprised however if we didn't end up on .NET server with the applications compiled down to native code through J# and IL.

      Unfortunately Sun don't have a level 5 leader in charge. They have an egotistical idiot who is concentrated like a laser on another companies business instead of his own.Antics like those of McNeally and Ellison play well in the press but measured by the success of the companies stock price leaders like Jack Welch or Lee Iaccoca don't do as well as their PR would have it. Iaccoca may have saved Chrysler (it might also have been the government loans) but once he started concentrating his energies on being a folk hero Chrysler's performance went back down the tubes. Similarly Jack Welch's performance does not look that hot if you look at the growth in GE earnings rather than the stock price - which is certain to shrink as GE returns to its old P/E multiple.

      One of the things a level 5 leader does is to encourage comment. The memo only says what others outside Sun have been saying for eight years.

      My take on the Sun/Microsoft Java war is based on a lot of time working in standards groups with both groups of engineers. I think that the Microsoft engineers thought they could improve Java and got frustrated because the Sun engineers behaved - well like Microsoft engineers sometimes do.

      Of course this will all be rationalised away. Of course it was all the fault of the Redmond club's evil schemes. Nobody outside Sun has any ideas of any value and Sun's JCM is genuinely open and not a proprietary farce.

      • by smd4985 (203677) on Sunday February 09, 2003 @11:24AM (#5264265) Homepage
        "The note is certain to be used by Microsoft in their appeal against the Java injunction."

        Um, no.
        First off, who knows if the note is even authentic.
        Secondly, what will be MS's argument?:
        "Judge, Sun feels they should improve their Java product. As you know, the law states that no company should be able to improve their products, unless they are us, and we can improve other people's products, but only for Windows. Thank you."

        • Re:Hypocrisy? (Score:3, Insightful)

          by Zeinfeld (263942)
          First off, who knows if the note is even authentic.

          We will soon find out. However Microsoft will certainly get the ability to subpoena etc. regardless of whether it is eventually proved to be a fraud.

          Judge, Sun feels they should improve their Java product

          No, that would be Sun like Microsoft recognises that Java is broken and needs fixing. Furthermore it recognises that the monolithic architecture of the JVM makes it seriously broken.

          If Java was not a 30Mb lump it would not need to be deployed with the O/S. It would be possible to download the support libraries required together with the code. It would be possible to download the versions of the libraries that the code was compiled against - exactly what dotNET does.

          Of course this would also mean that the distinction Sun has attempted to enforce between Sun approved modules and other modules would go away. It would be possible to develop a version of dotNET that ran J2EE programs optimised for the native processor.

          Sun's legal manipulations have been aimed at forcing Microsoft to support a platform while denying Microsoft and the rest of the community any say in the development of that platform. In every other standards process the vendors always reserve the right to not support the outcome if they don't like it. So there is a compromise between the positions of the parties, usually one that is aligned to the interests of the users. In the case of Java Sun has opposed any changes by Microsoft and in fact any other party that it belives are counter to Sun's interests

          I am not a Microsoft employee but I would be happy to testify for them.

    • Re:Hypocrisy? (Score:3, Interesting)

      Yes, but not just in the way you think. The subtext hypocrisy here is that Solars is not worth SUNs top level of support but they will not publicly acknowledge this.

      From their actions, it is clear they realize the future is in Windows and Linux. Not Solaris.

      The evidence is their support of JRE on Solaris.
  • by Anonymous Coward on Sunday February 09, 2003 @09:55AM (#5263797)
    Read the article poeple, what their saying is that the JRE on solrais has huge significant bugs that need fixing!!
    • by Jugalator (259273) on Sunday February 09, 2003 @10:10AM (#5263869) Journal
      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 (Score:5, Insightful)

      by Knacklappen (526643) <knacklappen@gmx.net> on Sunday February 09, 2003 @10:20AM (#5263921) Journal
      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.
    • by jcr (53032) <.jcr. .at. .mac.com.> on Sunday February 09, 2003 @10:28AM (#5263958) Journal
      Sure, Java doesn't suck, it's just the JRE.

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

      -jcr
    • Smells of a Fake (Score:4, Interesting)

      by dnoyeb (547705) on Sunday February 09, 2003 @10:55AM (#5264115) Homepage Journal
      The internal memo was from an idiot.

      Anyone that compares a scripting languate (python) to a full programming language that also as a VM has no clue. a scripting language has minimal overhead memory requirements because it does not have much of a memory management job to do.

      Complaining about 'will not fix' items on an older JRE is dumb as their must be SOME reason for the 1.4. If everything could have been fixed in 1.3.1, it would have been 1.3.2.

      Further I personally was told not to rely on the "sun" classes as they change. The article writer suggest that each release of the JRE causes classes to be dropped and added. I have NEVER experienced this and its a violation of SUN's stated practice.

      "4. It is not backward-compatible across minor releases." Then this fool goes and compares 1.3 to 1.4 or 1.1 to 1.2 as IF those are minor releases. (anyone that uses java knows the 3rd digit has been the minor one) The 2nd number has so far been treated majorly by Sun's releases and I would NEVER call 1.2 or 1.3 or 1.4 a minor release, they have years between them.

      As for large footprints, I stopped complaining about even M$ abuse of memory after the price came down so much. Just go buy some more. Its a valid issue, but I wouldn't mark it as worth of writing a letter.

      Finally I'd like to ask why none of his bug numbers appear in the Java BugDatabase on the javasoft website
      http://developer.java.sun.com/developer/b ugParade/ index.jshtml

      I'm skeptical of this letters validity.
      • by 1010011010 (53039) on Sunday February 09, 2003 @11:21AM (#5264250) Homepage
        Anyone that compares a scripting languate (python) to a full programming language that also as a VM has no clue. a scripting language has minimal overhead memory requirements because it does not have much of a memory management job to do.

        I don't see how that makes any sense. Python also has bytecode and a VM, and it does the same job in less memory with equivalent or better performence. It's object-oriented and performs garbage collection, as does java. What do you mean, "it does not have much of a memory management job to do"?

      • Re:Smells of a Fake (Score:5, Informative)

        by tom's a-cold (253195) on Sunday February 09, 2003 @01:51PM (#5265102) Homepage
        Anyone that compares a scripting languate (python) to a full programming language that also as a VM has no clue. a scripting language has minimal overhead memory requirements because it does not have much of a memory management job to do.
        Your remarks about Python, and scripting languages in general, are not borne out by my own first-hand experience as a designer and developer.

        First, you make it sound like, in some sense, scripting languages are not as complete as "real" programming languages. And your comments about memory management make even less sense-- any language with OO features (and many without) are going to have to do dynamic allocation-- how else are object references going to be dealt with?-- and that means that they're going to have to deal with memory-management issues. And if you think that all scripts are like little baby shellscripts, you haven't been around much.

        I've developed medium-sized apps in Python and in Perl (on the order of 50K lines of executable code), and much bigger apps in Java. Python is semantically rich enough, and in most instances fast enough, to do anything that Java can do, and almost always with shorter, more readable code. The same can be said for Perl (though it requires more discipline to achieve the readability), and probably also Ruby and Scheme. From a software engineering point of view, I'd be happiest coding the whole app in Jython (the Python variant that compiles down to Java bytecodes), then recoding the hotspots in Java, or in some even lower-level language. Developers, even smart ones, usually guess wrong about what to optimize, so deferring tuning until you observe the working system is usually a good idea. Exceptions would be embedded and hard-realtime systems. Almost every business app I've seen is neither of these.

        This in no way eliminates the need to design your app before coding it, BTW, contrary to what some bozos who once read the blurb on the back of an XP how-to book might have you believe.

        When I did a demo of one Python-based app that I developed, my client was willing to accept a performance hit for the sake of better maintainability. When I benched its performance on one content-mangement task, it clocked in at 100 times faster than its C++ predecessor. Now obviously, a very clever C++ crew could have done a lot better than that. But in the real world, everyone's in a hurry and don't always choose the cleanest implementation. And when language features are too low-level, developers waste a lot of time reinventing "infrastructure." In this instance, they not only reinvented, but did it much more poorly than the developers of Python did.


      • Re:Smells of a Fake (Score:4, Interesting)

        by dozer (30790) on Sunday February 09, 2003 @05:32PM (#5266478)
        a scripting language has minimal overhead memory requirements because it does not have much of a memory management job to do.

        No, scripting languages typically have significanlty more difficult memory management requirements. Memory managers in low-level languages are simple because the programmer does everything. Since Java lies somewhere between simple C/C++ and complex Perl/Python, why is its memory management slower and more complex than all the above?

        Complaining about 'will not fix' items on an older JRE is dumb as their must be SOME reason for the 1.4. If everything could have been fixed in 1.3.1, it would have been 1.3.2.

        When everything is fixed in version 1.3.1, it does get called 1.3.2. You call it 1.4 when you add features. Refusing to release a 1.3.2 is the same as refusing to fix bugs.

        The article writer suggest that each release of the JRE causes classes to be dropped and added. I have NEVER experienced this and its a violation of SUN's stated practice.

        Then you either haven't been programming Java very long, or you don't do much in it. Sun documented the proper way to do GUI programming, date conversion, and a whole bunch of other things in Java 1.1, then deprecated it ALL in 1.2. Haven't you noticed that most Java 1.1 programs won't compile under Java 1.4 without massive deprecation warnings? Most of these programs were 100% legal java programs when written, following Sun's documentation to the letter.

        As for large footprints, I stopped complaining about even M$ abuse of memory after the price came down so much. Just go buy some more. Its a valid issue, but I wouldn't mark it as worth of writing a letter.

        Go back and read his examples to see why Java is very bad in this resepct, even on today's hardware. It takes my Athlon 1800+/512MB machine 4 seconds to start a stupid command-line utility. Why? It has to reserve 26Mb of memory (and the classloader takes forever). The same program takes less than 1Mb in C and requires next to no time to start up.

        Finally I'd like to ask why none of his bug numbers appear in the Java BugDatabase on the javasoft website
        http://developer.java.sun.com/developer/b ugParade/ index.jshtml


        Because he works for Sun and uses the internal bug database? Did you READ this memo?
  • by Jugalator (259273) on Sunday February 09, 2003 @09:58AM (#5263810) Journal
    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.
  • Not too surprised (Score:5, Interesting)

    by ragnar (3268) on Sunday February 09, 2003 @09:58AM (#5263811) Homepage
    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.
  • by Steve G Swine (49788) on Sunday February 09, 2003 @09:58AM (#5263813) Journal
    ... if you let security concerns influence your development?

    Hand the implementation to Microsoft, they can fix the problems this has...
  • by Jrod5000 at RPI (229934) on Sunday February 09, 2003 @10:00AM (#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... (Score:5, Informative)

    by Whispers_in_the_dark (560817) <rich.harkinsNO@SPAMgmail.com> on Sunday February 09, 2003 @10:01AM (#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.
    • by The Mayor (6048) on Sunday February 09, 2003 @11:08AM (#5264167)
      It has always bugged you that Java had no good mechanism to compile simple expressions on-the-fly? Here are a few options for you:
      • Jython [jython.org] is a Python scripting engine for Java. There, now you can use Python within the JVM! <sarcasm>Get the worst of both worlds!</sarcasm\>
      • Rhino [mozilla.org] is a Javascript engine for Java.
      • Jacl [sourceforge.net] is a TCL engine for Java.
      • Bean Sripting Framework [ibm.com] is a generic wrapper for including scripting languages within your application. It's from IBM, and is intended to abstract away the implementation of the scripting language. It supports Jython, Jacl, and Rhino now. It seems like I remember IBM releasing something for REXX as well.
      My point here is that saying that Java doesn't include an interpreter is a downfall to Java is like saying that Perl not having a JVM is Perl's downfall. It's not their design goal. Java is a bytecode-interpreted language, not an interpreter. If you want an interpreter you can easily add one. And many are available.

      Performance isn't great, but reports have indicated that Jython is about 75% of the performance (near the end of the article...search for the word "performance") [oreilly.com] of CPython. It's slower than Java code of the same type. But, hey, if you wanted speed you wouldn't be using interpreted code (or byte-code interpreted code, for that matter), right?

    • by Daniel Phillips (238627) on Sunday February 09, 2003 @12:25PM (#5264627)
      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.

      I did a little benchmarking recently, and I can confirm that for typical algorithmic benchmarks (not heavily library or IO oriented) Python is more than 100 times slower than C/C++. There's a Python "specializing compiler" called Psyco that produces significant speedup, running my little fibonacci test around half the speed of C, very impressive.

      Java on the other hand has had huge amounts of effort and money put into making it run faster, and to my surprise, I found it now runs my fibonacci benchmark faster than gcc-compiled C. Overall, Java performance has improved from horrible to tolerable. Programs are still taking a long time to start, even on a beefy machine, but to be fair, I've seen some long startup times on some C++ programs as well.

      Python really beats Java in startup time, with the result that Python gets used here and Java doesn't.

      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.

      I see Pysco has made it into Debian Sid, this is a good sign.
    • Java vs Python (Score:3, Interesting)

      Years back, when Sun first came out with the java VM, some suggested that Python should either scrap its bytecodes for those of the JVM or at least do something to run as fast as the JVM. Guido, the controlling force behind Python, emphatically replied that because Python was a much more dynamic language than java and allowed many more things to happen at run-time than the JVM could support, Python never could compete and never would try to compete with a fast VM like java's.

      My experience is that java is faster than Python, but that speed almost never matters for me.

  • What's the point? (Score:4, Insightful)

    by CoderByBirth (585951) on Sunday February 09, 2003 @10:02AM (#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.
    • Re:What's the point? (Score:3, Interesting)

      by rodgerd (402)
      Insightful? For what? Not even reading the memo?

      If you bothered reading the piece before clicking "Post a slaverng Java fanboi response", you';d notice the engineer is recommending Java is so bad at Sun it not be used BECAUSE THE JAVA ENGINEERING TEAM WILL NOT FIX IT. Because they regard features as more important than a stable API or bug-free runtime.
  • by random_me (608957) on Sunday February 09, 2003 @10:03AM (#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?
    • remove the JVM requirement


      Uhm... The JVM is a library, like libm is a library. Removing the JVM is like removing lib libgnome*. If you want to run program that use the features of gnome, you have to install the libraries. If you want to use the features of the JVM, it needs to be installed. If you want those features in another language, you'd need to install some other libraries (gc, gui, etc.), so it should be considered unreasonable.

      Would it be better to link the apps statically?

      Joe

    • Considering that compiling Java into a native executable would seriously improve its performance

      People often say this, without realizing that in 1996 there was a native code compiler by Assymetrix (part of SuperCede for Java) which didn't do well in the market dispite being the only native compiler for Java. Currently there is gcj, which I don't know of any projects that use it, but I think may have a subset of the Java API.

      For whatever reason, people say they want native compilation, but it's never really proven out as a need.

      I think a more significant speed improvement in Java would be to remove the += operator for Strings. You wouldn't believe how badly one of those in a loop can tank an app's performance.
  • Read the Article (Score:5, Informative)

    by sparkhead (589134) on Sunday February 09, 2003 @10:07AM (#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.
  • Java Implementation (Score:5, Interesting)

    by Detritus (11846) on Sunday February 09, 2003 @10:13AM (#5263880) Homepage
    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.
    • by The Mayor (6048)
      I don't think p-code really bears much resemblance to Java byte code. Java does a lot of stuff after things have been compiled to byte code. P-code really is just a machine language of sorts that provides a hardware abstaction layer--that is, it is still just machine language. Java's byte code offers things like late binding & reflection, bounds checking, garbage collection, and a whole slew of other things. Many of these features make compiled Java (that is, compiled to a native executable) very difficult at best. And it also means that about 9/10 of the computation time with typical Java apps is spent in the JVM doing these things.
  • It's a hoax (Score:5, Informative)

    by Anonymous Coward on Sunday February 09, 2003 @10:13AM (#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

  • by mariox19 (632969) on Sunday February 09, 2003 @10:14AM (#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.

  • Political memos (Score:4, Informative)

    by panurge (573432) on Sunday February 09, 2003 @10:16AM (#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.

  • Where's the proof? (Score:5, Insightful)

    by MegaFur (79453) <wyrd0@komyCURIE.zzn.com minus physicist> on Sunday February 09, 2003 @10:21AM (#5263927) Journal
    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?
    • by Ilgaz (86384)
      that's the new creation of Pud, owner of http://www.fuckedcompany.com . Those 2 has thousands of paid (yes, and really expensive) subscribers who generally likes to drive limos :)

      Pud has a good reputation. I mean, it could sound funny but if you think even NY Times has to quote fuckedcompany.com like f****company.com sometimes on market pages, it may give a clue.
  • by sbuckhopper (12316) on Sunday February 09, 2003 @10:21AM (#5263929) Homepage Journal
    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.
    • by obsidian head (568045) on Sunday February 09, 2003 @10:39AM (#5264024)
      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 have written complex GUIs, which actually overwrite the paint() methods of Components, and Swing is slow on Windows and Unix. Also, I've used Swing apps, and guess what, they're slow memory hogs too.

      Inevitably someone proclaims that Swing runs fast if you program well enough. (I'm not referring to you but to Sun's party line.) BULLSHIT. It's slow. It trades memory for speed, and still isn't that speedy. Run Jext or Borland JBuilder and you'll see what I mean.

      Now, /I/ may personally like it for many uses, where control outweighs performance. But it's malicious for Sun to claim it fit for mainstream desktop apps.
    • by spinlocked (462072) on Sunday February 09, 2003 @12:19PM (#5264586)
      So I guess this could be true, but as someone who has worked with Sun before, I find it very, very hard to believe.

      I have worked at Sun and this smells very real to me. I have a friend at Sun who wrote an application in his spare time (in Java) which was officially adopted for internal use - he spent a month working with the internal applications gestapo having it re-written from scratch "to official standards". I agree with much of what the document says. Writing a complex Java application means targeting a specific JRE version, it is not at all unusual for Sun software products to install the particular JRE which they were written against (look at SunMC and the SunRay server software) - it's easier to keep patched without breaking other things.

      Until the Java developers use Solaris as their tier one development platform and API changes are controlled in the same was Solaris itself (PSARC) this will continue to be a problem.

  • Turf War (Score:3, Insightful)

    by the eric conspiracy (20178) on Sunday February 09, 2003 @10:25AM (#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.

  • by snatchitup (466222) on Sunday February 09, 2003 @10:32AM (#5263985) Homepage Journal
    And I thought I was the only one actually using them. I use them all over. They're a great way to intimidate the other developers, plus I needed them to pass Sun's Cert.

    But what I've never needed to do with them is serialize them. Interesting.

    Did you notice that of the 9 key bug/issues, 5 were AWT (GUI) related and 1 was Serializing Anonymous Inner classes.

    Why would they bring those up, and then within a sentence or two, mention Python. From what I understand, Python is mainly used for server side scripting. I doubt anyone uses Python for serializing anonymous inner-classes!

    The letter was put together hastily at best. It was an eclectic set of beefs.

    The last sentence really sums it all up. It's politics to get some resources shifted in their favor for the next build: ...namely Java. By bringing the Sun Java implementation through ARC, these issues can be resolved.
    • by Jerf (17166) on Sunday February 09, 2003 @04:06PM (#5265960) Journal
      Why would they bring those up, and then within a sentence or two, mention Python. From what I understand, Python is mainly used for server side scripting. I doubt anyone uses Python for serializing anonymous inner-classes!

      No, Python is used for everything that a general-purpose language is used for, except anything best done in C is stuffed into C extensions. The exceptions are of course the standard exceptions for C, which basically owns systems programming. (The need for fast, tight code in Python is done by embedding C; see the Numeric extension which provides many very fast number operations comparable to anything else, because the operations are in C.)

      In general, Python has no need for anonymous inner-classes; anonymous inner-classes are a worthless hack in Java to provide things that should be provided through any number of other good mechanisms, and even then they only partially and frustratingly succeed. Don't take my word for it, take jwz's word for it [jwz.org] (do a find for "mind-blowing worthlessness of inner classes", for instance, though it comes up several times as he mentions the lack of several better solutions).

      Inner classes, as implemented in Java, are an atrocious idea and I know of no other language, including specifically Python, that doesn't have at least one inherently superior mechanism for doing that stuff, and most have multiple. (Even Perl has closures!) Thus, they have no need for what Java means by 'anonymous inner classes'. (Inner classes can exist in Python, but they have so many more capabilities that it's not even close to comparable, and I only need them when I'm dynamically generating classes anyhow.)

      On the one hand, I'd say have a look at some of these other languages and use them enough to understand the idiomatic uses of the capabilities in those languages. On the other hand, I don't suggest it, as you may find it very difficult to program in Java again after you are done. Java is not a language designed to empower the developer.
  • by sparkhead (589134) on Sunday February 09, 2003 @10:41AM (#5264032)
    It turns out that Sun does not eat its own dog food. Specifically, this internal memo from Sun strongly suggests that Java..

    Purported internal memo. There's nothing there that suggests it is genuine and a few things that suggest it isn't.

  • Authenticity? (Score:4, Insightful)

    by RickHunter (103108) on Sunday February 09, 2003 @10:44AM (#5264048)

    How come I've not seen any comments questioning the authenticity of this memo? All we've got is the word of some site that this memo actually came from inside Sun. Presumably, they had it leaked to them by an anonymous source. Now, lets think about this for a second. What "anonymous source" has lots to gain (potentially billions of dollars) by disgracing Java? What "anonymous source" has a history of lies, deciet, astroturfing, libel, and other shady or illegal practices?

    I'm not saying that Java doesn't have problems. But still, it pays to take this information with a grain of salt until its source is proven. Which means until Sun officially says "this is true", as there's few (or no) independant tech news sources that don't get loads of advertising from the "anonymous source".

  • by slasho81 (455509) on Sunday February 09, 2003 @10:58AM (#5264124)

    This is a great example of spreading misinformation, starting in the headline and continuing to quote someone who gives a completely wrong summary of the memo. A memo which on its surface looks like a hoax (but may not be).

    A correct summary to this memo would be: Sun is having problems with its Java implementation on the Solaris platform (it is emphasized in the memo that the problems are not inherent in Java) and also that some problems stem from different versions of Java (have you ever had problems changing g++ versions? Probably, only in Java 'going native' is done on the client machine and not on the developer's).

  • by bockman (104837) on Sunday February 09, 2003 @11:31AM (#5264291)
    The Java ahead-of-time compiler of the 'GCC' compiling suite could be a good chance to keep the benefits of Java-the-language but to get rid of buggy and closed-source JVM.

    They are not there yet( AWT not yet complete, for instance), but it looks like they will be.

    BTW: can Java specs and API be reproduced legally without SUN permission?

  • by Headius (5562) on Sunday February 09, 2003 @12:42PM (#5264733) Homepage Journal
    Everything about this memo sounds as fake as can be. For example:

    Sun complaining about the JRE support model for internal projects...THEY ARE THEY JRE SUPPORT MODEL. It would be a bit like Ford recommending people don't use Ford parts for internal work because they'd have to go to Ford to get support for them. Eh?

    Listing off the memory footprint of various "demo" applications. The "Hello World" reference gives this away as totally bogus. Anyone who's used Java knows about its memory consumption. From day one people understand that it is not recommended for smaller applications. That's not the intention of Java, and it's not a recommendation or warning Sun would ever make internally. Java is excellent, perhaps better than anything else, for interoperable, server-side, cross-platform development. The claim that there are "better languages for that" is totally bogus. Show me another single language that packages object communication, database-independent persistance, compile once, reliable threading, and hundreds of other Java features, while being available on every major (and most minor) operating systems and platforms available. An external user trying to take Java down a notch (perhaps a disgruntled C++ developer?) would almost certainly point at the size of a "Hello World" application. BTW, guess what: Hello World compiles to a couple kB of Java code. If the platform uses 9M for a small program, that's not part of Hello World's memory footprint. How much memory does a compiled C program take (including all external libraries and the kernel itself) compared to its compiled size? The holistic difference is striking.

    The numbers about startup time and third-party application time. Why on earth would Solaris care if TogetherJ takes a long time to start up? If TogetherJ is written badly enough that it consumes 900MB of memory, then it's a failing of Togethersoft, not of Java. Too many Java developers have fallen into the trap of "memory is cheap, objects are garbage collected" and use truly gross algorithms in their software. A little common sense would reduce the footprint of some of these applications down to much more manageable levels. One should look at Java applications that do extremely well with regards to memory management, for example JBoss 3 and Eclipse. Eclipse provides one of the best, cleanest, well designed Java IDEs out there, and starts up into around 25M on my system. JBoss is a fully J2EE-compliant container, and starts up into about 32M on my machine. Compare that with other offerings.

    Backward compatibility across minor releases. Everyone familiar with Java knows that 1.2, 1.3, 1.4, are as far from "minor releases" as they could possibly be. There's absolutely nothing "minor" about them. The small compatibility issues that are listed in this document are almost certainly issues someone would face if they move from one level to the next and use deeper features of the JVM. The concern about Class.fields() is ludicrous. It changed after 1.1 (about FIVE YEARS AGO, PEOPLE) and hasn't changed since. The other two complaints are about UI behavior changing across major versions (1.3 to 1.4 and 1.2.2 to 1.3.1). Guess what...they're going to introduce improvements into UI behavior to improve the performance of the platform's UI as a whole. The interfaces did not change. The contracts between classes did not change. If someone's tables ended up looking a little different (boo-hoo, perhaps this is a Java UI developer who's out of his league) then you either recommend one major revision or another, or you format your UI in such a way as to prevent problems (not a difficult thing to do with Java's UI support). These gripes more than any others point to this being a fake: Everyone outside of Sun knows that 1.2->1.3->1.4 are not "minor revisions" and would never treat them as such. There's NO WAY Sun would refer to them in that way.

    Other issues are also well known to Java developers, and are easiliy avoided:

    JNI is unstable: Well duh...anytime you link out of the JVM you are dependent on external code for reliability. If the external code bloze or doesn't behave, guess what...you crash. Sun recommends not using JNI unless there's no other way to solve a problem, and wouldn't list this as a fault.

    Vitria: 450+ containers? What in holy hell are they doing with 450+ containers? Running a single component in each one? No reasonable architecture would EVER use this many JVMs on a single machine. The person who recommended this should be shot, and the person who wrote this obviously fake memo is looking for worst case scenarios to support their arguments. Regardless of Sun's marketing, companies with alternative languages and platforms would not be buying on if the platform itself wasn't so powerful. Would IBM have blown $1B+ developing Eclipse if they thought Java had unsolvable issues? Not bloody likely.

    JSSE referred to like a distant cousin: JSSE is Java's Security Extensions, and although the article is correct (it was formerly a plugin, now included in J2EE) it is referred to as "an external module called JSSE" and never once listed as a security extension. Does the author of this "memo" not know a primary, core technology that Java uses for security? Someone is extremely ill-informed, or has nothing whatsoever to do with Java.

    Ultimately, even if this does turn out to be an internal memo, I'd wager it's from a lower-level developer on the C++ side of the company that is angry (or worried) about the push towards Java-based applications over native languages. You can bet your ass this isn't a company-wide, high-level memo, because it's simply not true. How about this scenario:

    1. Internal Sun employee NOT involved in Java becomes disgruntled about getting fewer new projects and more maintenance and support work.
    2. Employee starts to monkey around with Java, either to nitpick well-known faults and flaws or to gain a better understanding, hopefully to get an "in" on new Java-based projects
    3. Employee finds enough nitpicking details to write an "internal memo" recommending Java not be used, or get frustrated that they can't learn the entire language in a day and does the same.
    4. Employee writes said "internal memo", hoping to stir up some discussion
    5. After the employee's claims are shot down, much like I did above, the employee gets even more frustrated
    6. Employee "leaks" the memo to stir up bad press for employer. Since the memo appears on a site where "accidentally" leaked memos appear, employee can feign ignorance.

    Everyone jumps to conclusions on these things. Don't believe everything you read. Java is a spectular language...anyone who has used it for any length of time knows that. The people who have never used it on a real-world project are routinely its biggest critics.
  • by Glock27 (446276) on Sunday February 09, 2003 @01:28PM (#5264985)
    Comprehension test, folks:

    We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation.

    Also, many of the stated problems are slated to be fixed in Java 1.5...we'll see.

    In the meantime, support gcj or the IBM implementations...on other platforms. ;-)

    Another snippet:

    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.

    Don't throw out the baby with the bathwater.

    And of course, now that I read some of the replies, I see it may well be a hoax regardless. Sigh. (Disclaimer: I've never used Java on Solaris, only Linux and Windows.)

  • Is this real? (Score:3, Informative)

    by MagPulse (316) on Sunday February 09, 2003 @01:52PM (#5265103)
    This is the same site that posted the fake id memo [theinquirer.net]. Is their record besides that one mostly spotless? It seems no one here is doubting whether or not this is real.
  • by malachid69 (306291) on Sunday February 09, 2003 @02:14PM (#5265264) Homepage
    Quotes from the article that show you didn't read the letter before posting it:

    "these issues are not inherent to Java"

    "We do not believe these flaws are inherent in the Java platform"

    "We all agree that the Java language offers many advantages over the alternatives."

    "The customer must locate that release and install it." That, IMHO, is complete BS. I never keep anything but the most recent version installed, on Windows or Unix. The only issue I have ever seen like this was with JHDL from Brigham Young, which used "assert" that was added as a keyword (due to customer requests) in 1.4 -- and it still works if you tell it to compile as 1.3 (javac command-line option). I personally would not support an outdated version when a version with bug-fixes is available for free.

    "Typical resident set requirements for Java2 programs include: Hello World 9M" Again, BS. I have a TINI board running that only has 8M of memory total, AND I have an old Handspring (8M) that has Sun's JDK and IBM's JDK and Java3D on it.

    "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." Again, BS. I have been coding Java since IBM released JDK 1.0.2 for Win3.11.... I have never had this problem with ANY code I have written.

    And their overall request? "We strongly recommend that management require Java to conform to the Software Development Framework ".

    If you would have read the letter before posting it, you might have realized that what they were really complaining about was Solaris 7 and 8. They even point out that Solaris 9 is fixed. The pieces of the letter that suggested other languages was specific to the Solaris implementation, as my comments above prove that their statistics are not valid outside of Solaris.

    So, Solaris pre-9 is buggy. Big deal, that has nothing to do with how fit Java is as a language.

    Malachi
    • 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


      Hrm. Looks like Solaris 9 still needs a little work. At least we can see that the PC implementations can get those pesky "hello, world" programs into something more reasonable - like only 5 megs of RAM...

      But it's certainly not the language, nor the design, concepts, nor intent behind it... It must be the implementation. Heck, I'm sure any day now, there will be a JVM that runs even faster, even lighter than native code. Any day now...
    • I never keep anything but the most recent version installed, on Windows or Unix... I personally would not support an outdated version when a version with bug-fixes is available for free.

      With every release, Sun breaks something that worked in an older version. Swing in 1.4 blows up all over the place where 1.3 worked fine. If the failures in the latest JRE don't affect you, then you can use it. The place I work for runs into this with every release we make. We have to pick one version and say we only support that because other versions have bugs. We also don't have the QA resources to make sure we run on every single version. We're not the only ones. BEA WebLogic still does not support JDK 1.4, even though it's been out for over a year and is approaching the second minor version update.

      "Typical resident set requirements for Java2 programs include: Hello World 9M" Again, BS. I have a TINI board running that only has 8M of memory total, AND I have an old Handspring (8M) that has Sun's JDK and IBM's JDK and Java3D on it.

      Just because there's a Java implementation that runs on a small platform doesn't mean the one that runs on Windows or Solaris isn't grossly overweight. IIRC, running something not a lot larger than Hello World on 1.4 for Windows takes about 12M. That's a stupid-big footprint and there's a feature request in-process to fix it.

  • by cdthompso1 (648972) on Sunday February 09, 2003 @02:32PM (#5265376) Homepage
    I've long believed that Sun, a hardware company, should have taken their Java team and spun it off completely as JavaSoft Inc., as was contemplated in the mid 90s. The consulting and development teams would have one objective: furthering the Java platform. Doing so would have made this memo, if it is legit, a non-issue from a PR perspective. JavaSoft probably would have made the same decision on where to focus their efforts: on making the Win32 JVM implementation the best, and supporting other OSes secondarily. That's what this memo is about: pissed off Solaris admins who are tired of sitting in the back of the bus when it comes to Java. Before the advent of the web applications as the platform of choice for developing new applicattion, and even since, Win32 is where the money is because of the wide install base. (I won't go into whether monopolistic forces caused it; for a software company, you just have to accept this as the current lay of the land.) Obvioiusly the Win32 JVMs get the most development resources, and rightfully so (with Linux probably a close second, thanks to IBM, who wrote their own JVM). Unfortunately, Sun didn't do the spinoff completely, and now people want to see this as a "rift from within" and "Sun not eating its own dog food." I want to reiterate the point that others have made, because some of the early posters missed it: the problem highlighted in this article is with the specific JVM implementation for the Solaris OS. It is not about the failings of Java as a language, J2EE as a specification, nor interpreted vs. compiled applications. Java will be around for a long time to come, particularly in large environments, as evidenced by most major application vendors supporting it (Oracle, Siebel, SAP, PeopleSoft, JD Edwards, etc.) and by the fact that most academic programs are switching to it. In fact, this year for the first time, the high school AP test for programming will be in Java, not C++. It is here to stay because it is a decent enough OO language.
  • by Jonboy X (319895) <jonathan.oexner@ ... du minus painter> on Sunday February 09, 2003 @03:21PM (#5265704) Journal
    Yeah, it's a fake. I work at Sun, and a quick LDAP search lets us know that Sun doesn't employ a Julian S. Taylor. Geez, I wish f'dcompany.com would check this stuff out before they post it. Actually, I wish /. would check this stuff out first...
    -Jon
  • Java FUD (Score:4, Insightful)

    by Dragonshed (206590) on Sunday February 09, 2003 @03:33PM (#5265766)
    This article is a giant vat of uninformed bullshit.

    I won't address Java 1.4x points because in general, java 1.4 sucks. (Handicapped threads, new io architecture forced on installed base, inept standard regex and logging facilities, bah)

    Java on store shelves: The fast majority of companies use java to model internal business processes and integrate them into systems. Java is extremely useful for this because programmers don't have to worry about hardware. This is not the kind of software you shrinkwrap.

    TogetherJ/TogetherSoft: The installer asks you if you want to install a JDK with the product, or use a separately installed one. It also will tell you if your installed JDK is sufficient.

    Python: Python source is compiled into bytecode upon first interpreting. It has it's own VM, also mutable from native code. There are quite a number of differences between python and java, but your comparison is uninformed.

    Java Minor releases: The differences between 1.2 and 1.3 is quite large. These are not minor releases, despite sun's versioning scheme.

    JNI Stability: JNI isn't easy to produce correctly. But it's stability is a responsibility of the programmer. C programmers don't blame the OS when a program segfaults.

    I guarantee had this article been about perl's deficiencies, it would've been scrutinized with a scope large enough to see Venus, and wouldn't have made it passed submission.
  • by Paul Boven (211567) on Sunday February 09, 2003 @05:00PM (#5266286)
    I use and admin Solaris systems every day, at work and at home, and in itself it's a great product. But its biggest problem is Java. More and more stuff is being java-ised, resulting in absolutely horrid performance.
    Examples: the SunScreen 3.2 commandline. Takes ages to load or do anything, especially viewing your firewall logs. Sun Managment Center: It does not perform. It becomes completely laughable when you try to display the screen on another Xserver. This is how Sun was demo-ing it at Lisa2001, and although the lead developers over there agreed that it didn't perform, they blamed this on Swing but had this scary religious fervor when it came to doing things in Java.
    The new patch-managment tools from Sun? Nice idea, very flawed implementation. Sloooooow, and so buggy that we ditched it, prefering to keep our Suns up to date by hand.
    Java installers are another fun item. Sun has a very nice packaging system, which makes it possible to jumpstart machines with identical software configurations etc. But more and more software becomes 'java installed'. It does not add any functionality apart from a badly drawn gui, but it breaks all the convenience of having one standard packaging tool for the os.
    Please stop this madness.
  • by prostoalex (308614) on Sunday February 09, 2003 @09:15PM (#5267732) Homepage Journal
    Why Java sucks [jwz.org] , written in 1997, but some points still hold true.
  • Power Grab (Score:4, Insightful)

    by Performer Guy (69820) on Monday February 10, 2003 @12:11AM (#5268366)
    This is a power grab by an internal Sun committee. It's riddled with scaremongering and concocted reasons why the ARC should control Java. It's a sign of deep malaise within Sun.

A failure will not appear until a unit has passed final inspection.

Working...