Discussions

News: ALLEGED: Sun Memo Criticizes Java Platform and Solaris OS

Bookmark and Share Get thread feed

  1. ALLEGED: Sun Memo Criticizes Java Platform and Solaris OS (115 messages)

    • Posted by: Corby Page
    • Posted on: February 08 2003 00:33 EST
    An *alleged* internal report by Sun employees offers this damning assessment: "Within Sun, Java is not viewed as a satisfactory language for the construction of commercial applications."

    Checkout the report

    The report is focused on Solaris's JVM implementation, but many of the issues raised in the report are cross-platform. In particular, the employees criticise Sun's release process for introducing critical bugs across minor releases, and for breaking backward compatibility.

    What do you think of the issues raised in the report? Does Bug Parade cut the mustard for you? Are your applications hampered by startup times and memory issues? Would you prefer that fewer extensions were rolled into the J2SE Core Libraries? How difficult is it to migrate complex applications across JVM versions?

    *** editors note: ***
    There are now claims that this note was faked.
    It is still valid to read and understand what the authors are trying to say, but realise that this may not be SUN internal employees
    Reply to this

    Threaded Messages (115)

  2. Java not a satisfactory language for commercial apps[ Go to top ]

    <quote>
    Within Sun, Java is not viewed as a satisfactory language for the construction of commercial applications.
    </quote>

    Well it's a satisfactory language for BEA to construct commercial applications in, to name just one successful vendor. There are some good points in the memo (for example, memory usage on Solaris) but if Sun can't develop viable commercial apps in Java it reflects as much on their development efforts as on the Java environment itself.

    Rod Johnson, author of Expert One-on-One J2EE Design and Development
    Reply to this Reply to original

  3. SPAMMING for book sales?[ Go to top ]

    BEA doesn't build commercial applications. They build tools and leave it to the developers to actually build the commercial applications. Java is rife with frameworks, containers, specifications, patterns, books, and training classes. But when it comes down to it, actually *implementing* something in java, it is a bear.

    The two domains where java is having success are in place of ancient COBOL code, or non-type-safe scripting languages. COBOL died a long time ago, but the scripting languages are pushing back. With disciplined coding practices and increasing OO friendly scripting languages (such as python), java's weeknesses are being exposed.

    When it comes down to it, in enterprise applications, all you're doing is reading and writing text, with a little bit of arithmatic thrown in (usually in the form of a sum() in SQL.) These are problems that people were solving 20 years ago with primitive languages on slow computers. Your transactions are merely a lock() and a log file. Yes it is sometimes hard to get right. It'd be something if CMT made this less error prone, but it doesn't.

    Read the memo. It is unlikely that it is a fake. It may not have been sent as an internal Sun memo, but it is from a developer experience with Sun products. Specifically, it is
    Reply to this Reply to original

  4. Authentic?[ Go to top ]

    Has TSS checked the authenticity of this memo? Do you have internal sources at Sun that can verify it?

    One poster on slashdot who claims to work for Sun says that the author of the memo is not listed on Sun's directory services.
    Reply to this Reply to original

  5. Google says[ Go to top ]

    However, searching for -- "Julian Taylor" Sun -- on google returns something (not the first links).

    http://www.google.be/search?hl=en&ie=UTF-8&oe=UTF-8&q=%22Julian+Taylor%22+sun&meta=
    Reply to this Reply to original

  6. What keeps me away ...[ Go to top ]

    I think that who ever wrote the text is not really revelant. What is relevant is how much of it is correct?

    Here is what keeps me away from Sun Java:
    1. Differences in versions break my software. Instead of programming to interfaces (like in COM) I end up programming to JDK versions because I cannot say for sure if it will still work in the next release.

    2. Packages that have nothing to do with my application I 'get for free'. This means that bugs or corrections in those packages that may effect underlying/common packages may also effect my packages.

    3. The GUI is terrible. I am sorry, but I hate writing GUIs for Java - I can never get the user to wait while Java is figuring out what to do.

    4. Memory. We got a 5MB file filled with serialised objects that takes 80 MB of memory when it is loaded. How is this? Then when we do stuff with those objects we start getting into 128MB+ My machine has 256MB RAM and 1Gb cache because of the huge Java memory requirement.
    Reply to this Reply to original

  7. Relevant[ Go to top ]

    <i>I think that who ever wrote the text is not really revelant. What is relevant is how much of it is correct? </i>

    I disagree to some extent. If it is an actual memo from someone at Sun, it will be seized upon by Microsoft and many others and trumpeted loudly. If it is a fake, it won't have much impact.

    Of course, it will be interesting to debate the validity of its content also.
    Reply to this Reply to original

  8. Relevant[ Go to top ]

    If it's fake, someone also deliberately faked it to damage Java.

    Rod
    Reply to this Reply to original

  9. Need to verfiy the validity[ Go to top ]

    I definately think it is important to find out the validity of the authors.

    If anyone in the community learns any more information please post it here. (Hopefully SUN will come out with a statement)

    At the same time, we can still discuss the content knowing that the author may not be valid.

    Even if this *IS* from a SUN employee, it doesn't mean that its claims are correct. An employee is just one person, with his/her opinions, and they may differ from others, including their companies.

    Dion
    Reply to this Reply to original

  10. Critique is good![ Go to top ]

    Try to see the good intention in that memo :-) What could better improve Java on Suns than a memo like that from an employee? And what could damage it more than ignoring it or treating it as a "hostile comment"?

    My $.02 questions, anyway.
    Reply to this Reply to original

  11. Blame it on the rain or Java...[ Go to top ]

    Gone are those days buddy.This is an excuse given by those who cannot write OO code.Your code is prolly convoluted because of bad design , etc.... and maybe hybrid.

    >Differences in versions break my software. Instead of >programming to interfaces (like in COM) I end up >programming to JDK versions because I cannot say for sure >if it will still work in the next release.
    Which part of the API broke your code?


    Jeff Mutonho
    Reply to this Reply to original

  12. .[ Go to top ]

    Eamonn J. Casey notes does have validity.

    We have a web based, client-server mini-erp system with the front end in Java Swing. We developed a set of controls for a different look and feel. While it works with JRE 1.3 it does not work with JRE 1.4. JRE 1.4 "broke" what works in JRE 1.3

    Another valid point is the huge memory occupied by Java structures. Check out the memory requirements for a C++ based linked list with one in Java. We have overcome it here by using a 512 element cached disk based Vector, LinkedList and Hastable.

    The GUI itself is not a problem. The basic problem is the memory management by the JVM. Sun should perhaps split the native memory management code and the rest of the JVM bordered by a well defined API so that competent teams can replace the Sun memory management implementation with their own to suit their needs better.

    Java however has certain unbeatable benefits, no matter what people, "internal" or external have to say. Here are some of the benefits that we got out of the product.

    1. Truly CROSS PLATFORM for no extra development effort.
    2. Data handling from JRE 1.3 onwards beats a corresponding app developed in VB6.
    3. Very easy to implement agents for program executions either in server or client accoring to internal rules.
    4. Ability to load classes from anywhere has truly simplified remote client software maintenence.

    Umakanth
    Reply to this Reply to original

  13. What keeps me away ...[ Go to top ]

    My machine has 256MB RAM and 1Gb cache because of the huge Java >memory requirement.


    Sir,
    You are describing a 250$ machine. Why are you really complaining?
    DODO
    Reply to this Reply to original

  14. RE: What keeps me away ...[ Go to top ]

    That's one JVM. Tack on another 80MB+ for Borland's JBuilder. Another 80MB for my database managment tool (Sybase 12.5) and then we start getting the picture.

    The point made in the memo (fake or real) is that vendors writing Java applications base their support on specific versions of Java (1.2, 1.3.1, 1.4.1 etc).
    Reply to this Reply to original

  15. but do nothing[ Go to top ]

    Yes, but it does not do anything except printing Hello World after 30 secs.
    Thats what he/she is complaining
    Reply to this Reply to original

  16. Are you certain?[ Go to top ]

    Eamonn: "Here is what keeps me away from Sun Java"

    1. Differences in versions break my software. Instead of programming to interfaces (like in COM) I end up programming to JDK versions because I cannot say for sure if it will still work in the next release.

    Comparing Java to COM is ludicrous to start with. You can almost re-architect an entire Java application in the time that it takes to roll out a minor change in COM. That's the number one reason why we completely abandoned COM in '96 and proceeded _gleefully_ to Java.

    Further, I have yet to encounter general purpose code that has "broken" as the result of a new JDK release. I do know of specific Swing "improvements" that broke something, but that's about it. Our company has over 600,000 Java LOC under management, and it is all cross-platform and multi-JDK version (1.2.0 to 1.4.1_01), so I definitely would be a big whiner if each JDK went and broke stuff.

    2. Packages that have nothing to do with my application I 'get for free'. This means that bugs or corrections in those packages that may effect underlying/common packages may also effect my packages.

    What does that mean?

    3. The GUI is terrible. I am sorry, but I hate writing GUIs for Java - I can never get the user to wait while Java is figuring out what to do.

    Could you please point me to some of your Java GUI work? Also, in what year did you try to build the Java GUI, what OS, what JDK vendor and version, and what toolset (and approach) did you use?

    4. Memory. We got a 5MB file filled with serialised objects that takes 80 MB of memory when it is loaded. How is this? Then when we do stuff with those objects we start getting into 128MB+ My machine has 256MB RAM and 1Gb cache because of the huge Java memory requirement.

    Interesting. Does the JVM memory utilization expand to 80MB, or does the footprint of those objects actually use 80MB? The JVM will probably use whatever memory you give it (for temporary objects), but it may not need anywhere near that much. Obviously, the JVM (and it's half-brother the CLI) use a lot more memory than older C applications, both for "real" objects (the ones you hang on to) and for temporaries. (You should hear the complaints about load time and memory utilization by VB.NET "hello world" applications.)

    The other thing to keep in mind is that Windows and a couple of office applications would run inside of 640k fairly easily. Now it needs 256MB to do the same thing. Your quest to hold back the growing resource consumption of software is a perpetually losing proposition. In fact, it's how software people make sure that the hardware people stay employed ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  17. Are you certain?[ Go to top ]

    The other thing to keep in mind is that Windows and a couple of office applications would run inside of 640k fairly easily. Now it needs 256MB to do the same thing.


    Sir,
    I doubt that anybody, including Microsoft, can squeeze Word 98 in 640k. And I strongly doubt that the 256 Mb that Windows uses now are waisted. I'm pretty sure of the contrary. I had to write some utilities for a project I worked on 7 years ago - (than it was novell, btrieve, extended dos, windows 3.1, Watcom C++(maybe these names don't mean anything to you)). The big change now was Windows NT, 256Mb RAM(instead of 8Mb) and a 60GB harddrive(so changes mostly hardware).7 years ago the project was "slow, painfull and human resources consuming". Now it was only painfull. I was 4 times more productive.
    I've seen this opinion on TSS threads, that there is too much hardware used. I disagree. The more hardware we use, the more efficient we are as programmers.
    If you disagree, I recommend writing something, anything on a CP/M80 machine:-)))
    Reply to this Reply to original

  18. Are you certain?[ Go to top ]

    Cameron Purdy wrote:

    "I have yet to encounter general purpose code that has 'broken' as the result of a new JDK release."

    I'm glad that you, and other posters, have had such fortunate experiences with JDK upgrades. My experiences have not been so good. As a recent counter-example, I would refer you to bug 4724129 in the Bug Parade database.

    This bug report documents how in JDK 1.4.1_01 an atrocious memory leak was introduced into the StringBuffer class. This leak manifests in several popular third-party packages such as JDOM. In our case, when we did a test rollout of JDK 1.4.1_01 our servers came crashing down in hours.

    But that's not the part that concerns me. I would consider a memory leak in a very common System class to be a severe issue. The Sun engineers do not. If you read through their comments on the bug report, you will see that since the fix is not completely trivial, they have no intention of offering a fix in any of the subsequent JDK 1.4 releases.

    Suddenly, I identify very closely with the concerns raised in the memo, whether it is real or not (and I suspect that it is). It takes a truly warped set of priorities to decide not to fix a bug like this.

    And incidentally, our systems that were crashed by this bug were running on W2K. The issue of major new problems with the JDK releases, and an extremely broken methodology for responding to these bugs, in not restricted to the Solaris platform.
    Reply to this Reply to original

  19. Software Dev[ Go to top ]

    Your hurting because you didn't follow software development rule #1

    1. Always be one version behind
    Reply to this Reply to original

  20. JAVA GETTING TOO BIG???[ Go to top ]

    The main point I can relate to in the note (regardless of the authenticity) is the increasing size of the core set.

    We are all taught (or teach others) that you build systems out of sub-sets. You create 2 interface sets. 1 for authentication, 1 for data access. Then, you create a package, for authentication which implements your interface, and then you build a data access package in the same manner. Then you build an authenticated data access package using the two sets of interfaces......or something similar.

    In the "olden days" Java was released very much in this manner. The core J2SE was the set of core classes, out of which you could __build almost anything else._ I say almost because obviously over time we encounter things where we need to go to the OS for something not currently in the core set of code, so these are prime candidates for incorporation into the core core base.

    However, when you look at the J2SE now, there is a lot of stuff in there which really could be built by someone else. Java should, at least in my opinion, revert to the old style, which would go like this.

    1) Core J2SE is just that. The core. Anything which can be built out of the core classes does _not_ belong in the core.

    2) Interface definition packages, such as JDBC, Swing, DOM etc.

    3) Implementations of those interfaces.

    If the J2SE were packaged that way, then a good 33% of the issues mentioned in the article would go away, and differing JVM implementations would be significantly easier to produce and test.

    Just my 2c worth, and given the tendancy for people on this site to flame anyone that doesn't agree with them, I shall don my flame retardent overcoat now.

    Chz

    Tony

    PS. To whoever it was who said "why are you complaining you need 1GB of memory when it only costs $200." If Moore's Law is true, then why are we all still solving the same "it doesn't run fast enough" problem. Even when resources are commoditized, it is _not_ an excuse to simply treat them as something you can use with abandon. :)
    Reply to this Reply to original

  21. JAVA GETTING TOO BIG???[ Go to top ]

    Tony,

    I agree with you that you don't do bad programming just because memory is cheap. However, the "Java is a memory hog" is a general statement that a lot of people make. And it _does_ use more memory than a lot of other things. But the argument is less relevant when memory becomes a commodity product, and that's mu point. In fact that's true of most products that become commoditized.

    Jason McKerr
    Reply to this Reply to original

  22. JAVA GETTING TOO BIG???[ Go to top ]

    Jason,
          We're in agreement on the "Java is a memory hog" statement.

    I just don't think that we should allow ourselves to make the memory issue less relevant just because it's commoditized now. I think we should agressively target excessive resource consumption.

    Resources can be cheap, but the ability of a system to accomodate increasing resources grows much slower. For instance, sooner or later, even though memory is $25 for 256MB, you will have no slots left on your motherboard, which means a new motherboard or bigger memory modules....and so on and so forth. The issue is worse for high end servers where the costs are higher (but this isn't a discussion of Linux versus Sun so I'm staying away from that side of it.)

    Just my 2c worth.

    Chz

    Tony
    Reply to this Reply to original

  23. JAVA GETTING TOO BIG???[ Go to top ]

    PS. To whoever it was who said "why are you complaining you need 1GB of memory when it only costs $200."


    Sir,

    I really paid attention to the above comment. The machine described had 256Mb with 1Gb of vm. This is a state of the art machine from 1997. SO Moore's Law had noithing to do with that disscussion(unless you build in 2003 for such machines).
    (Whatever you were taught or worse you teach about from building subsets, etc, is galimatias at best- and NO, galimatias is not a VD(trying to anticipate comments:-)))).
    Reply to this Reply to original

  24. JAVA GETTING TOO BIG???[ Go to top ]

    DODO DODO,
              The specification you quotes in your original post was state of the art in 1997. When it did _not_ cost $250. It would now cost less than that for that kind of memory and specification, which is the very essence of Moores Law, interpreted from the alternative perspective(You can now buy the same processing power for a fraction of the price it cost 18 months ago.)

    I believe I made a structured, well thought out argument regarding how to properly use machine resources. It was not galimatias, it was a standard approach on how to build systems, which you will see echoed in most of the output of the JCP, and in the design patterns section of this site. You are at your liberty to disagree, but I would appreciate it if you would do so with professional courtesy.

    The memory footprint of the JVM is out of proportion with the work the VM is doing. 9MB of memory before _anything_ can be done is not practicle, particularly in the server side arena, where the shift of most industries is to consolidate systems.

    In financial services for instance, the old approach was that each system had its own server, in order to separate concerns and allow disjoint upgrade paths for large projects. This has now shifted towards server consolidation, whereby different projects simply have to move at similar speeds.

    The effect of this is many more processes running on the same server. The footprint of the JVM becomes an issue in these circumstances. The main alternative to server consolidation this consolidation is with the increasing adoption of Linux, which allows for multiple servers, similar processing power, but significantly lower TCO. You might want to check out the latest Linux Magazine you will find a fascinating article on Linux on Wall Street.

    In the first decade of the new century, technology has become holistic. Total Cost of Ownership (TCO) is now king, and things such as the memory footprint of a JVM, or the consumption of other resources, plays a part in that. Is it a big part? Maybe not, but I wonder how we moved from an 8MHZ processor, with 640K of memory, (on which you could word process, run spreadsheets etc.) to a 2.4GHZ processor, with 1GB of memory, on which you can word process, run spreadsheets etc...

    I accept that people do a lot more with computers these days than they used to, but for a core set of applications, people are generally doing what they used to do, and yet the footprint of those applications (Java or otherwise) in terms of both memory and disk requirements is 100 times what it used to be. We got where we are by allowing ourselves to consume a commoditized resource. How long can we keep doing it?

    This is now too long for my liking, but I haven't any more time left to edit it. Apologies to anyone who reads this and finds it off topic!

    Chz

    Tony
    Reply to this Reply to original

  25. JAVA GETTING TOO BIG???[ Go to top ]

    Sir,

    I don't think this is little discussion is off-topic. Au contraire, I've seen too many times the argument "Too much hardware used" for things that had to be done using that amount of harware. A 1992 wordprocessor(the one that ran in 640kb) didn't spellcheck on the fly, as a matter of fact didn't run in graphic mode at all. I know many users who take this for granted now. And windows still supports extended dos(some games use it, so MS people are not that stupid to kill it). This takes resources.(I talk about windows because vms is gone, and more and more people see Solaris and aix following its trend - debatable, of course).

    >You are at your liberty to disagree, but I would appreciate it if you would do so with professional courtesy.

    You misquoted me big time. And galimatias doesn't mean idiot.
    Reply to this Reply to original

  26. VMS is not gone[ Go to top ]

    Actually VMS is not gone.

    Not as widely used as 15 years ago.

    But not gone.

    You can even run WebLogic and JBoss on it !
    Reply to this Reply to original

  27. Re: JAVA GETTING TOO BIG???[ Go to top ]

    Evolving through APIs is just a tactical solution. and thats why the toolkit is getting bigger, more difficult to understand, learn and use (not the languaje)

    To cope with distribution, data storage, complex math (etc.)should require an evolution at the granmmar side of the language. Increasing the number of classes at the core level looks like a DCOM strategy (and you know, its just a matter of time...)

    Is Java, as it is, the definitive language ?
    Reply to this Reply to original

  28. Yes Java Core LIB is too big!![ Go to top ]

    The rt.jar need not have XML libraries and
    other stuff which can be built in "Pure Java".

    Even if Sun wants to bundle these class libs it should
    bundle in some "ext" folder. only.

    While Installing jdk installer should show option for
    selecting this extra libs.

    In my opinion Swing is also "Pure Javaa" and hence should
    be put in "ext" folders.

    If some users do not want these libs they can remove these
    libs through installer.

    Installer should have a feture to up grade these libraries
    whithout touching the core.
    Reply to this Reply to original

  29. COM & Java[ Go to top ]

    "Comparing Java to COM is ludicrous to start with. You can almost re-architect an entire Java application in the time that it takes to roll out a minor change in COM. That's the number one reason why we completely abandoned COM in '96 and proceeded _gleefully_ to Java."

    My experience with COM (and I had a lot of it) are very different than what you describe. COM has/had a lot of idiosyncracies but once you got the hang of it it was/is very powerful and not hard to develop/change.
    Reply to this Reply to original

  30. COM & Java[ Go to top ]

    My experience with COM (and I had a lot of it) are very different than >what you describe. COM has/had a lot of idiosyncracies but once you >got the hang of it it was/is very powerful and not hard to develop/>change.


    I was a big COM supporter too until Microsoft made it legacy in favor of a Java like approach (.Net). Once .Net came along I discovered that Sun had it right the whole time!
    Reply to this Reply to original

  31. So?[ Go to top ]

    Client side Java does not work, this is not news to anyone.
    Yawn.
    People just use Flash.

    Server side Java from Sun is no good, this is not news.
    Bea and Oracle use JRockit:VM
    Websphere uses IBM VM.
    IPlanet .... for those of you on it, use Sun VM, so no problems, right, except for the people that work for Sun.

    http://www.bea.com/products/weblogic/jrockit/index.shtml
    J:Rockit is much better, and saves you money, as we know.

    Look, Sun is about to go to $2 range in Stock range, and it is going to go the way of the DEC (DEC had a nice Alpha chip, I will miss it).
    Sun Hardware is Slow and Expensive, the EJB is embarasing and there is no such thing as Client Side Java.

    For those reasons, As a consultant, I have been advising clients not to use Sun for ANYTHING.

    It is about time that .NET gets healthy competition from Java, and Sun is just not healthy, so somoone else has to emerge (I hope not BEA, better IBM or hopefully Open Source).

    Like Linux, Java will own majority market share of backroom servers. (with PostgreSQL/Tomcat/Eclipse I hope).
    And corporate secretaries can use M$ Access to write Macros, and spend time in a budget meetings to aprove the new M$ license, so that the rest of can do heavy lifting in Linux/Java.

    By Sun, thanks for Java.

    .V
    Reply to this Reply to original

  32. COM & Java[ Go to top ]

    At the Tomb of the IUnknown Interface

    Sartoris, you're not only a die-hard C++ fan, but also a COM fan - my goodness, you really are a masochist. ;-)
    However, having said that, I am sure I could introduce you to at least a couple of programmers who still think that COM and C++ are the great thing. Its a small club - and its members will take their enthusiasm for unreadable code to their graves...

    BTW: I work with guys who were excellent C++ and COM programmers - and they would willingly amputated their own limbs than go back to COM (esp C++ COM).

    -Nick
    Reply to this Reply to original

  33. EJB vs COM[ Go to top ]

    |
    |Sartoris, you're not only a die-hard C++ fan, but also
    |a COM fan - my goodness, you really are a masochist
    |

    Yes, COM is a deprecated technique - but it was a highly successful in its time with hundreds of providers with thousands of ActiveX components.

    And where is the market for EJB components today? (ATG business idea - have anybody heard from them recently?)

    Do you think that EJB components ever will be as successful as COM one time was?

    The "deprecated COM" is still faster than EJB by a factor from 120 to 2, depending on the skill of the J2EE developer. That is - if you are very good, you get only a 50% performance decrease.

    ("Based on the regression analysis, it seems that the Coarse Grained Session Bean idiom is ... and about 120 times better performing than the Fine Grained Entity Bean idiom."
    http://www.urbancode.com/projects/ejbbenchmark/testsAndResults.jsp)

    <Ara Abrahamian>
    It's time to say goodbye babe...

    It was a historic day for me today, I unsubscribed from EJB-INTEREST mailing list today. I've been subscribed to it for some 4 years! It's a historic moment because that means EJB for me is now dead.</Ara Abrahamian>
    http://www.freeroller.net/page/ara_e/20021214

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  34. ZZzzzzzzz[ Go to top ]

    ZZZZzzzzz
    Reply to this Reply to original

  35. EJB vs COM[ Go to top ]

    To Rolf:

    "Do you think that EJB components ever will be as successful as COM one time was? "

    No because there are plenty of alternatives. And EJB doesn't fill all the gaps. With MS you allways have one alternative. A single one. Boring. And EJB IS successfull as long as you DO NOT identify EJB as being Entity beans.
    Reply to this Reply to original

  36. COM & Java[ Go to top ]

    "Sartoris, you're not only a die-hard C++ fan, but also a COM fan - my goodness, you really are a masochist. ;-) "

    COM served its purpose very well. It is dying like all good or bad technologies all do. It made Windows application development a lot more rich. I won't miss it but I do appreciated it.

    I will also miss C++. I just wish Java was more like C++. Or I wish there was a language platorm that was a Java/C++ combination. The Java folks left out WAY too much functionality.

    The C# folks have taken a different approach. They took copied Java and added some really dumb features.
    Reply to this Reply to original

  37. C/C++ not dead yet![ Go to top ]

    I am not arguing against you but what are the things you don't like?

    (Seeing that many of the C# functionality will be added to Java in the future)

    Regards
    Rolf Tollerud
    C/C++ projects in Sourceforge, 19804, Java 7821.
    Reply to this Reply to original

  38. COM & Java[ Go to top ]

    |
    |The Java folks left out WAY too much functionality
    |
    | The C# folks ...<snip>...copied Java ...<snip>
    |

    Like what?

    What really important things do you see that is missing from C# and Java?

    Do you concede that Java and C# add some really nice features that are not possible in C++ ?

    -Nick
    Reply to this Reply to original

  39. COM & Java[ Go to top ]

    "Like what? "

    A preprocessor.
    Stack-based objects.
    Deterministic destructors.
    The ability to destroy objects on demand (delete).
    Generic types.
    Constant types.
    Pass-by-reference.
    Multiple implementation inheritance.
    Default parameters.

    "Do you concede that Java and C# add some really nice features that are not possible in C++ ? "

    I do. But they left out a lot, too.
    C# seems to have added things that I don't like. Properties, for instance. To me it is a mess. I coded a bug in a C# class recently. It is an easy bug to produce.
    Something like (I can't remember the exact bug):
    class MyClass {
    int x;
    public int X {
    get { return X; } // X here should have been x
    }
    And it compiled!
    C# also mucks up simple inheritance with override and new modifiers. It's totally confusing.
    Also the boxing of "native" types into full blown objects is confusing and must be wasteful of resources.
    It's too much like VB for my taste. But I'm afraid to not learn it because I may need to know it to earn a living one day;-)
    Reply to this Reply to original

  40. On the right track[ Go to top ]

    Sartoris: A preprocessor.

    Necessary in C++. Available for Java (there are plenty) but rarely needed.

    Sartoris: Stack-based objects.

    Who cares where they are? Java VMs allocate them on the stack (not SS:BP but a stack of memory pages similar in concept) quite often before copying them into intermediate generational storage. It's nice not to care.

    Sartoris: Deterministic destructors.
    Sartoris: The ability to destroy objects on demand (delete).

    This can be nice. There's really no reason for Java to not support it. Basically putting the object (what's left of it) into an illegal state, or a link thereto.

    Sartoris: Generic types.

    They're coming. C# too (the MS proprietary version, that is. ;-)

    Sartoris: Constant types.
    Sartoris: Pass-by-reference.

    I'm tempted to agree, but I know what a pain they are in C++.

    Sartoris: Multiple implementation inheritance.

    Again, both good and bad. Why include something that's bad? Isn't that the job of a tool, not a language? ;-)

    Sartoris: Default parameters.

    Syntactic sugar. Not very evil though.

    Sartoris: C# seems to have added things that I don't like. Properties, for instance.

    That's because Properties are meta data, not a language feature. IMHO. Just a sign that the authors of C# weren't language designers, they were tools developers.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  41. better with some experience than none[ Go to top ]

    "That's because Properties are meta data, not a language feature. IMHO. Just a sign that the authors of C# weren't language designers, they were tools developers."

    Java does not have "meta data Properties" ( to be added in future versions), hmm - maybe because the authors of Java did not have any background in language design whatsoever!

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  42. better with some experience than none?[ Go to top ]

    Cameron: "That's because Properties are meta data, not a language feature. IMHO. Just a sign that the authors of C# weren't language designers, they were tools developers."

    Rolf: "Java does not have "meta data Properties" ( to be added in future versions), hmm - maybe because the authors of Java did not have any background in language design whatsoever!"

    Meta data does not have to be munged into a class structure in order to be meta data. That's what tools (and even patterns) are for. The tool we use has supported properties in Java since '97 without having to write any code, neither accessors nor mutators, neither ugly square bracket stuff nor "property" keywords. Miraculously, no special language support needed.

    IMHO Munging that stuff into a language is what happens when a tool developer gets put in charge of designing a language. It's shite.

    It's simply too bad that Java tools, in general, waited five years for Microsoft to get in the game before deciding that power and ease of use could go together. But, hey, that's what competition is for, right?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  43. On the right track[ Go to top ]

    "Sartoris: A preprocessor.

    Necessary in C++. Available for Java (there are plenty) but rarely needed. "

    Just 1 example is the ability to include/not include debugging code.

    "Sartoris: Stack-based objects.

    Who cares where they are?"

    If object are created on the stack they never need to be garbage collected.

    "Sartoris: Multiple implementation inheritance.

    Again, both good and bad. Why include something that's bad? Isn't that the job of a tool, not a language? ;-) "

    Why is it bad? Thers's a lot of goofy things that are done to get around the problem of not having it. Like putting data in interfaces. The Serializable also just a little foolery to get around it as well.

    "Sartoris: Default parameters.

    Syntactic sugar. Not very evil though"

    I think it helps limit copy-paste bugs. No need to have multiple methods for overloading (in many cases anyway).
    Reply to this Reply to original

  44. some people is difficult to satisfy![ Go to top ]

    here Sartoris,

    ..a present to you from MS:

    http://research.microsoft.com/vault/

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  45. COM & Java[ Go to top ]

    Sartoris: A preprocessor.
    Cameron: Necessary in C++. Available for Java (there are plenty) but rarely needed.

    Agree with Cameron - rarely needed in Java. I certainly havent missed it.
    Whats more, code that requires preprocessing makes it more difficult to debug (try debugging C++ code with lots of macros) and also makes it quite difficult for dev tools (like Together) to parse intelligently;

    Sartoris: Stack-based objects.
    Cameron: Who cares where they are?

    Agreed. The only time this is interesting is in combination with deterministic destructors... but not even this is that interesting (see below)

    Sartoris: Deterministic destructors.

    In conjunction with stack-based objects, this makes for handy to setup and have guaranteed tear-down. However, a try-finally block or an anonymous inner class command pattern passed into template method is actually much much more useful and more obvious to the reader.
    Destructors are a necessity in technologies that heavily depend on reference counting (ie COM and CORBA) but, as these technologies have shown, reference counting always leads to problems that are almost impossible to debug.

    Sartoris: The ability to destroy objects on demand (delete).
    Cameron: There's really no reason for Java to not support it.

    There is a fundamental mismatch between deterministic object deallocation and a managed environment - the two cannot really coexist.
    In any case, its not really that interesting. If deleting is just to invoke the destructor - then a close() method is no more difficult to implement or easy to forget.
    Sartoris: Generic types.
    Cameron: They're coming.

    I havent missed them. Moreover, I have been against their introduction to Java - but I am prepared to see how it goes.

    Sartoris: Constant types.

    While I understand the benefits, in general, in C++ I have found them to always be a pain.

    Sartoris: Pass-by-reference.

    Not sure what this actually buys you vs Java.

    Sartoris: Multiple implementation inheritance.

    In the RARE cases where this actually makes sense, its nothing that cannot be achieved via dynamic proxies. Though slightly more complex, the result is a lot clearer (and far more useful).

    Sartoris: Default parameters.
    Cameron: Syntactic sugar. Not very evil though.

    I find default parameters a very easy way to confuse the reader of code - so its evil enough in my mind. I am a very small fan of having to look in multiple places to understand what a piece of code is doing.

    Sartoris: C# seems to have added things that I don't like. Properties, for instance.

    I agree - for the same reason as above. You have to look in multiple places in the code to work out whats going on.

    Sarrtoris: C# also mucks up simple inheritance with override and new modifiers. It's totally confusing.

    Agreed 100%.

    Sartoris: Also the boxing of "native" types into full blown objects is confusing

    Agreed again. While its nice not to have to create Object types when using Collections, its not really a big deal and I would rather remove primitives altogether than the evils of implicit type conversions that plague VB.

    ---//---

    I think that the one reason why Java has become so popular in server-side programming is the ease in which you can develop ~reliable~ code (or the comparitive difficulty to develop unsafe code). Checked exceptions and memory management are dominant aspects of this - but so too is code readability.
    If a piece of code can be read and instantly understood it is far less likely that bugs will arise through incorrect modification or re-use. Anything that distracts the reader (like having to find a macro definition) reduces their ability to comprehend the code they are looking at. Not only does this affect the number of bugs created, but also the speed at which they can be detected.

    Practically all the things "missing" from Java that are mentioned above, impact the readability of code. Whats more, I dont think many of them are all that usefuul in the context of Java (while they may have been in C++).

    -Nick
    Reply to this Reply to original

  46. COM & Java[ Go to top ]

    "Agreed again. While its nice not to have to create Object
    types when using Collections, its not really a big deal and
    I would rather remove primitives altogether than the evils
    of implicit type conversions that plague VB."

    Actually, in my haste, I have confused two issues here :-\.

    Auto-boxing messes with object identity and this can have a lot of pitfalls (especially when combined with C#'s structs). (However, its a different issue to the lack of compile-time checking that you get when you have implicit type conversions).

    -Nick
    Reply to this Reply to original

  47. COM & Java[ Go to top ]

    "Stack-based, preprocessors, etc"
    I replied to these in a prior post.

    "Sartoris: Deterministic destructors.

    In conjunction with stack-based objects, this makes for handy to setup and have guaranteed tear-down. However, a try-finally block or an anonymous inner class command pattern passed into template method is actually much much more useful and more obvious to the reader."

    I think that try/finally blocks are very hard on the eyes and make it easier to produce errors. Closing resources in destructors makes much more sense.

    "There is a fundamental mismatch between deterministic object deallocation and a managed environment - the two cannot really coexist.
    In any case, its not really that interesting. If deleting is just to invoke the destructor - then a close() method is no more difficult to implement or easy to forget. "

    Consider this: give the opportunity to call delete on an object. At the same time keep the garbage collector. If an object cannot be reached any longer the GC can do its business. But, by golly, let me get rid of stuff I know I no longer need.

    I think that would allow Java systems to run a lot faster.

    "I think that the one reason why Java has become so popular in server-side programming is the ease in which you can develop ~reliable~ code (or the comparitive difficulty to develop unsafe code)."
    But when a system gets large the deficiencies really become evident and have a negative impact.
    Reply to this Reply to original

  48. COM & Java[ Go to top ]

    |
    |Just 1 example is the ability to include/not include
    |debugging code.
    |

    And when you can have a runtime-configurable logging like log4j, why would you want to recompile your code to turn logging on or off?
    In any case:

    if (Logging.debugFlag) {
       log.info("hello loggy");
    }

    Is the same as a preprocessor due to the Java compiler optimisation (if debugFlag is final)

    |
    |If object are created on the stack they never need to be
    |garbage collected.
    |

    Admittedly this would give some perfomance benefit in a minority of systems (for most systems, it wouldnt make a lick of difference). I dont think the added complexity is worth it.

    |
    |I think that try/finally blocks are very hard on the eyes
    |and make it easier to produce errors. Closing resources in
    |destructors makes much more sense.
    |

    How does closing resources in a destructor make more "sense" than in a finally block?.
    In fact, using the destructor of a stack-based object, although common, is really a bit of a hack due to the fact that C++ has no "finally" clause.

    |
    |Consider this: give the opportunity to call delete on an
    |object.
    |

    Oh, come on now. How often have you seen this same argument and its responses?
    If you are allowed to call delete, then you can call it twice and you can delete it when some other code references it. If you have these risks you may as well not bother with a GC - it doesnt give you anything any more.

    |
    |But when a system gets large the deficiencies really become
    |evident and have a negative impact.
    |

    I would say the opposite. When C++ systems get really large you really start seeing the cracks in reliability and maintainability.

    -Nick
    Reply to this Reply to original

  49. non verbose please[ Go to top ]

    It never cease to amaze me how such small bagatelles can be important. For me the only thing who matter is that I have to write as little as possible!

    Regards
    Rolf Tollerud
    (BTW, pass by reference is implemented in C#)
    Reply to this Reply to original

  50. non verbose please[ Go to top ]

    |
    |For me the only thing who matter is that I have to write |as little as possible!
    |

    For me, what is important is that what is written is understood as quickly as possible. This means that the code should be succint - but does not always mean writing as fewer characters as possible. The distinction is important.

    -Nick
    Reply to this Reply to original

  51. maintainable[ Go to top ]

    |
    |what is important is that what is written is
    |understood as quickly as possible
    |

    That is true of course, of good code. But some guys have the attitude that "it was hard to write it should be hard to read"! I am reminded about an episode at the university.

    When the psychologist teacher talked, and the students complained that they did not understand anything, he was proud.

    When the philosopher teacher talked and the students complained that they do not understand anything, he was ashamed.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  52. maintainable[ Go to top ]

    |
    |That is true of course, of good code
    |

    Well, I am not really talking about developer standards (though, they obviously play a big part).
    What I am talking about are language "features" that make code comprehension more difficult (even though they may be less verbose).

    Examples are:
    1) Macros. While macros mean that you can write more code with less text, it also means that the reader has to check whats in the macro before he/she can understand it.

    2) C# Properties. While it means that (the classic example) examples such as obj1.setValue(obj1.getValue() + 1) are avoided, it also means that the developer has to check whether obj1.Value actually means obj1.Value - or does it mean obj1.setValue().

    The instant that the reader of code has to think "whats going on here" and has to check some other part of the code, then their concentration is broken and their comprehension of the code has been compromised. (Thats not to say that really verbose code is best either - because by the time they have finished reading it they have forgotten the beginning.)

    -Nick
    Reply to this Reply to original

  53. simplify coding[ Go to top ]

    x = obj1.Value;
    obj1.Value = x;

    The only problem with C# properties is that you could mistake it for a public variable.
    But as you never use public direct accessible variables anyway, it is not a problem.

    In fact, there is a discussion in the community to further simplify the properties declaration!

    Meanwhile we all await eagerly the support for generics. That will reduce the verbosity still more, without taking away the readability. For instance Hashtable <int, string> lookup,
    no need for casting.


    "The proposed Java syntax looks like templates as created in C++ and C#, including type parameters and constraints. But, because Java lacks a unified type system, the unmodified Java Virtual Machine will not be able to support generics for value types. As such, generics in Java will gain no execution efficiency. Indeed, the Java compiler will inject automatic downcasts from the specified constraint, if one is declared, or the base Object type, if a constraint is not declared, whenever it needs to return data. Further, like the C++ compiler, the Java compiler will generate a new specialized type for each constructed type, resulting in more bloated code than in C# generics. Finally, because the Java Virtual Machine will not support generics natively, there will be no way to ascertain the type parameter for an instance of a generic type at run-time and other uses of reflection will be severely limited"

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  54. simplify coding[ Go to top ]

    |The only problem with C# properties is that you could
    |mistake it for a public variable.
    |
    Exactly.

    |But as you never use public direct accessible variables
    |anyway, it is not a problem.
    |
    Not true. It is a problem. Every tome you read someone elses code, you are always going to have to check to see whether they have adhered to this practice or not before you understand what the code is doing.

    |
    | "The proposed Java syntax ".... blah blah blah
    |
    I am not surprised that you quote from the gotdotnet site - but you may as well have posted a link to the source site since you cut&pasted the rest... ;-)

    I havent looked at generics thoroughly enough yet to comment - though my understanding from what I have read thus far is that the performance cost (of not changing the JVM) is negligible (benchmarks I have read found it difficult to measure the cost, it was so small).
    As for reflection limitations, I cant see anything immediately obvious that will be impacted - be interested if you can provide some examples.

    -Nick
    Reply to this Reply to original

  55. many new things in next version of c#[ Go to top ]

    Ok, I apologize for the cutting and pasting..
    I am in the process of digesting all the news from the next C# version.

    But I don't know what to say about the issue we are discussing - I've read a lot of code from others, and promise you that never I've seen a public variable used in this fashion - thus there are no problem even if you are correct "in theory".

    It should be clear by now that I am pragmatic - always prefer the useful solution and doesn't have much patience with impractical thetoricians (I don't count you as one - they present are always excluded!) and it seem to me that .NET was constructed by people with a lot of practical intelligence in their minds in a way that it is not possible when your are dealing with a committee. It is always difficult to defend an "incorrect" (but practical) solution against the purists.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  56. many new confusing things in next version of c#[ Go to top ]

    Rolf: "It should be clear by now that I am pragmatic..."

    Such a kidder, you! First you call yourself a zealot, then you claim to be pragmatic. You've got me in stitches!
    Reply to this Reply to original

  57. many new things in next version of c#[ Go to top ]

    |
    | it seem to me that .NET was constructed by people with a
    | lot of practical intelligence in their minds in a way that
    | it is not possible when your are dealing with a committee.
    |

    Well, I think its fair to say thats your gut feeling based on your love of all things Microsoft (its not uncommon of Microsoft guys - I know a few).

    You sum up a very cliched Microsoft argument: "We have the smartest people - and design by committee never works". At times, there is a fine line between a "practical" solution and a "short sighted" solution.

    |
    | I've read a lot of code from others, and promise you that
    | never I've seen a public variable used in this fashion
    |

    I have. And in some cases (if you are truly as pragmatic as you say you are) its quite acceptable to do this. Consider a DTO - its a dumb data aggregation object. Whether you have p.getName() or p.name - its rather academic. There is nothing about the internal implementation you want to hide so using an accessor doesnt buy you anything.

    If, as you say, no-one codes with public attributes, then no-one would mind if they were not allowed. The C# designers could have prohibited public attributes on classes - there would be less confusion with properties.

    -Nick
    Reply to this Reply to original

  58. and It's actually true too![ Go to top ]

    "We have the smartest people - and design by committee never works"

    Thank you Nick, for putting the words so nice - better than I could do myself!

    Next round Java vs C# is coming up soon.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  59. and It's actually true too![ Go to top ]

    |
    |"We have the smartest people - and design by committee
    |never works"
    |
    |Thank you Nick, for putting the words so nice - better
    |than I could do myself!
    |

    The thing is that only Microsoft zealots, in their own little PC world, actually believe this crap.

    The rest of the enterprise computing industry, many hundereds of companies from the size IBM down to small companies like Atlassian, are firmly on the Java/J2EE train - so that must be evidence that some design-by-committe worked somewhere....

    -Nick
    Reply to this Reply to original

  60. nobody use :NET[ Go to top ]

    Nick,

    "The rest of the enterprise computing industry, ...are firmly on the Java/J2EE train"

    Is that so?

    Search at www.it.jobserve.com
    by Yann Caroff on January 29, 2003

    .NET: 455
    WebLogic: 182
    WebSphere: 140
    PHP: 58
    ColdFusion: 54
    ATG Dynamo: 38
    iAS: 11
    JRun: 11
    JBoss: 10
    Sun one: < 11 ("one Sun administrator" matches)
    SilverStream: 9
    Borland Application Server: 1
    EAServer: 1
    Jonas: 0
    Pramati: 0
    Trifork: 0
    Interstage: 0
    Zope: 0
     
    When I searched today I got 557 hits for .NET.

    200 case studies:
    http://msdn.microsoft.com/vstudio/productinfo/casestudies/default.asp

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  61. ZZZzzzzzzzz....[ Go to top ]

    ZZZZzzzzz.....
    Reply to this Reply to original

  62. Java vs C#[ Go to top ]

    OK, I rest my case. Why quarrel? By the 17 February
    next year we everyone will know the facit anyway.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  63. Java vs C#[ Go to top ]

    |
    |OK, I rest my case.
    |

    You rest what case?

    You cant seriously think that some search results on one job site mean anything? (BTW Did you do a search for "java"?)

    Can you point me to any major software vendors that are moving their software stack to .net?

    -Nick
    Reply to this Reply to original

  64. to clarifiy my position[ Go to top ]

    Nick,

    Well, I could say something - but first you have to promise
    not to put the ZZZZzzzzz..... it is not polite!

    I think I have to explain a bit. For me there isn't a case of Java against C#/.NET. For me the fight really is against all expensive middleware. Websphere Portal or MS Sharepoint Portal - all the same shit. Middleware should be Open Source, - or at least no run time fee.

    It just looks like I am against Java - that only because the Java world seem to have fallen into some hopeless love with "Computer Science". You will not find *any* .NET developers be caught dead with the expression "Organize inter-service transfers according to use cases from known domain objects into a coarse-grained Composite" or even "domain model".. I can not strong enough convey my feelings every time I hear idiotic buzz words uttered by some nit-wit.

    And unfortunately such "mumbo-jumbo" nonsense seems closely affiliated to the big expensive middleware vendors. If you have the one you have the other!

    On the other hand in the Java world there are also guys like Juergen Hoeller, perfectly reasonable and competent, Jakarta - unmatched in professionality, and so on.

    As you can see, I don't want any major software vendors moving their software stack to .NET, I want them to lie over and pass away! That is the reason big app server people are so afraid they know they have nothing to gain by porting to .NET - nobody want them there.

    Juergen Hoeller:
    "The days of expensive middleware are gone, hopefully"

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  65. to clarifiy my position[ Go to top ]

    |
    |Well, I could say something - but first you have to promise
    |not to put the ZZZZzzzzz..... it is not polite!
    |

    OK. But "Zzzzz.." means I have heard this all before from you (usually several times) - it wasnt valid before and its not valid now - its just repetition. (And oftent its just provocation)

    But anyhow, point taken.

    |
    |I think I have to explain a bit
    |

    I know your position on this - even if it wavers somewhat and gets lost amongst rabid .Net zealotry. ;-)

    |
    |Java world seem to have fallen into some hopeless love
    |with "Computer Science".
    |

    Dont be put off by Java developers who have had an education in their chosen field.

    And whatever contempt you have of patterns and discussions of patterns, you need to recognise that they are valuable. Dont assume that just because the sentence is a mouthful that the users dont know how to solve a real problem.

    I can tell you from experience (in my current job) that the opposite approach (dare I say it, the uneducated approach) of just hacking out crap code and reinventing the wheel is, I am sorry to say, the norm rather than the exception for most ASP/VB hackers that are now wanting to move to .Net.

    |
    |And unfortunately such "mumbo-jumbo" nonsense seems closely
    |affiliated to the big expensive middleware vendors. If you
    |have the one you have the other!
    |

    I think this is a bit of an inductive leap. I think that most vendors are in the business of dumbing J2EE down. You only have to look at the efforts of IBM and BEA in this area.

    |
    |Middleware should be Open Source, - or at least no run
    |time fee.
    |

    Quality software costs time & money. People can either make this money via licenses (or runtime fees), or via services (e.g. support). If you believe in zero runtime cost, then what incentive does any vendor have to produce quality software? They would be better off creating worse software so that they can recoup cost via support. What sort of quality software will we be working with then?

    |
    |As you can see, I don't want any major software vendors
    |moving their software stack to .NET, I want them to lie
    |over and pass away! That is the reason big app server
    |people are so afraid they know they have nothing to gain by
    |porting to .NET - nobody want them there.
    |

    Well, good luck. If you think that Open Source software is going to solve all the worlds computing problems, then I think this is a little fanciful - unless of course, you want to take the chinese approach and just throw more people at the wheel reinvention task.

    -Nick
    Reply to this Reply to original

  66. clarifiy my position[ Go to top ]

    Nick,

    Of course I do not expect you to agree with me. But at least I want to specify where I stand. 1) I don't mind being an MS zealot 2) I am violently against expensive middleware as well as impractical theorists, but 3) * I am not against Java* - I want that to be clear. C# and Java is more or less the same to me (no matter what Richard Öberg thinks).

    Programming with Tomcat with Open Source middleware is an agreeable experience. The reason for me to leave that word - I have said this before - was that semi-technical management people did not understand that my carefully handcrafted and fast apps was superior to the EJB shit that was produced by fresh students from University. OK - so I move on.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  67. Off Topic Again![ Go to top ]

    Rolf, Nick, Whoever else....

    I believe this thread was supposed to be about the memo, allegedly from Sun, which pointed out some Java issues.

    This memo is not _yet another_ excuse to start a debate about .NET versus Java (be it a reasoned discussion or an all out war.)

    If you want to talk about that, please do so on a thread dedicated to that topic.

    There's not a lot of point in having threads and discussions if they all end up being about the same thing.

    Chz

    Tony
    Reply to this Reply to original

  68. Programmers need to take control..[ Go to top ]

    1. TSS continues to look like a site that cannot be trusted with respect to java
    2. Sun is the last organisation I will rely on when it comes to java innovation - I am not happy with java bcos it is very possible to improve it but nothing much has been done by Sun or JCP
     - memory, (single vm is preferrable like Mac OS X)
     - the library is definitely too large, could be broken down to different parts
     - the saviour has been open source java, IBM, and the various small java companies

    So much for Rolf and Nick's continual off-point discussion!!

    I call for onejava, I call for all java programmers to collaborate in the spirit of objects. I call for us programmers to compare and contrast java technologies in a single forum. We can collectively define a single standard, we can appoint/ vote the pple we believe in who are ready to serve. We can make java survive and grow +vely.
    Let the consciousness grow.
    Reply to this Reply to original

  69. Off Topic Again![ Go to top ]

    My sincerest apolagies. I am usually fairly conscious of this.

    -Nick
    Reply to this Reply to original

  70. like a black panther[ Go to top ]

    When you are working with Tomcat/Resin and Open Source middleware you feel like a black panther.

    And a "Big App Server" like Websphere (kludge of 300+ products)?
    Abhorred? Disguised, Appealed?

    Sorry I lack word(s)!

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  71. many new things in next version of c#[ Go to top ]

    |
    | it seem to me that .NET was constructed by people with a
    | lot of practical intelligence in their minds in a way that
    | it is not possible when your are dealing with a committee.
    |

    Actually, its very arguable whether or not a Common Language Runtime is the result of "practical intelligence".

    I dont see many projects making practical use of this feature - developing some in C#, some in VB.net, some in delphi.net. (In fact this feature is the one of the .net features that scares IT managers the most).

    Also, when this decision forces you to limit the services offered by the VM (the most striking of which are checked exceptions), then you have to wonder whether this is practicality or theory.

    -Nick
    Reply to this Reply to original

  72. Here is what keeps me with Sun Java[ Go to top ]

    1. Java has evolved as a server-side language
    2. Java became the first multiplatform language, you can build your software on Windows platform and deploy it on Unix without any modifications
    3. J2EE is major breakthrough non comparable with COM/DCOM etc. windows based distributed technology
    4. J2EE based web applications proved to be robust, resilent multiplatform and scalable.
    5. J2EE forces you to program to the interface not to JDK because J2EE container takes away from the programmer a lot of responsibilities. Many issues resolved by changing deployment descriptors
    6.Memory is cheap in comparison to the labor cost
    Reply to this Reply to original

  73. Before shifting to damage control ...[ Go to top ]

    Look at the intro: "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."

    In other words, these engineers are being forced to use Java and they aren't getting the support they need from the OS+JVM group. I'd be upset too. In fact, their gripes don't differ significantly from those posted routinely on (for example) JavaLobby:

    "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++."

    So if it's a fake, it was probably built from quotes off of JavaLobby from real Java users, and if it's real, let's just hope it causes the problems to be fixed.

    Regarding Java on Solaris, the issues with Swing (etc.) hardly ever come up for most companies because Solaris is used for servers but is a piss poor desktop OS to start with (almost everyone already uses Windows (90%+), Mac (4%) or Linux (2%)). Imagine, though, that you're the poor C++ programmer at Sun that has to do GUI admin tools (etc.) in Java (because the manager half your age told you to use it) for Solaris and you run into a bug and it gets closed as "will not fix".

    Conclusion: It's bad form, it's bad press, but the problem that it describes has a basis in reality.

    (Note: This story apparently started breaking a week ago or so on theinquirer.net. Apparently, it is a very purposeful leak from a Sun employee to a number of media outlets.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  74. ** Proof and my comments[ Go to top ]

    I have read the article and all your comments with
    great interest. I particularly take note of the
    size of the running JVM and patch/upgrade issues.

    Hopefully Sun will take stock of these issues and
    address the Reliability, Availability and Scalability (RAS)
    issues that is has been saying was/is one of the main
    concerns (in JDK1.4 onwards) at the JavaOne conference.

    I now suggest that we invite FORMAL response from Sun and
    the author/reviewers of the article on TSS?

    Sun, should post their comment on TSS with a link to
    their response on the Sun Java site.

    Thanks,

    Gary
    ____________________________________________________
    Co-author Java Server Programming, J2EE 1.3 Edition
    http://www.wrox.com
    Reply to this Reply to original

  75. name the cross platform issues[ Go to top ]

    Since the memo concentrates on Solaris please by all means name the cros spaltform issues..

    Typical TSS FUd..

    Its time to stop the FUD aroudn here if you want the develoeprs back after the testing debacle..

    spreading fud does not help yor case..
    Reply to this Reply to original

  76. name the cross platform issues[ Go to top ]

    <quote>
    Since the memo concentrates on Solaris please by all means name the cros spaltform issues..

    Typical TSS FUd..

    Its time to stop the FUD aroudn here if you want the develoeprs back after the testing debacle..

    spreading fud does not help yor case..
    </quote>

    I think that its interesting enough to know and read about it - if its floating around elsewhere. And it is.

    Sandeep.
    Reply to this Reply to original

  77. name the cross platform issues[ Go to top ]

    Julian dot Taylor at central dot sun dot com
    stephen dot talley at central dot sun dot com
    mark dot carlson at central dot sun dot com

    seem to be legitimate email addresses.

    Dr. Peter Madany (madany at eng dot sun dot com) was the original Sun rep on the J2ME spec.

    Mike Boucher is/was a Performance Architect Sun Microsystems, and was a speaker at SunNetwork 2002.

    So if its faked its very, very well faked.

    In any case, I think Cameron brings up some good points.

    A flaw is a flaw - for all you know this was leaked because no one within Sun would heed the need to make changes in this regards...

    Sandeep
    Reply to this Reply to original

  78. so you want flaws[ Go to top ]

    You mena that you rather rely on fkaed flawed memo than reality?

    that is the saem as saying that you can rely on the latst flwawed Petstore tesing by TSS...

    Not when my job i son the line..no thanks..

    However you may be a more expert risk taker where faked memos and data are concerned..
    Reply to this Reply to original

  79. Backwards compatibility[ Go to top ]

    On the whole the report seems to be stressing problems with Sun's practices in implementing and supporting the JDK, rather than with Java per se, so I think the new forum title is a big improvement on the tabloid style "Java not a satisfactory language for commercial apps" one...

    I, personally, thought the most interesting issue the report raised was about keeping extensions to Java as separate versioned modules rather than as part of base Java, so that they could be allowed to evolve as requirements change. I am not sure how the author(s) of the report envisioned this being implemented - perhaps by having packages that had version numbers??? (E.g. com.sun.javax.swing1_2.*)

    Personally, I can't help but wonder what the long-term implications of the backwards compatibility requirement will be on Java. Will Java stagnate because it is weighed down with deprecated, but not removed, functionality? Will we ever see better implementations of poorly implemented functionality (like the ugly Date/Time classes)? Will the hindrance to the addition, adoption, and evolution of new functionality in Java (caused by the current packaging/versioning protocol) cause it to be superceded?

    Regards,
    Lawrie
    Reply to this Reply to original

  80. Backwards compatibility[ Go to top ]

    Lawrie,

    I was also intrigued by the backwards compatability issue that was raised. This issue was been discussed many times on TSS. I think I remember hearing that 1.5 will be the first version to actually remove deprecated methods, but I could be mistaken.

    I wonder, is there ever a point where Java says, "Backward compatability be damned, we need to move forward!" Will there ever be a day where there actually is a real Java 2, as in 2.0. A release that addresses some of the *big* language issues, such as the ones addresses here. One that fixes the date/calendar crap and drops "old" collection classes.

    The article also mentions that as more and more APIs get rolled into the JRE, it becomes more and more bloated. I like the naming scheme many OSS projects have adopted for their JAR files - log4j-1.2.7.jar. It is nice to be able to look in your /lib directory and know exactly what you are dealing with. Perhaps Java can have the main JDK download contain a rt.jar with core files, and more "versioned" jar files. Not sure where you draw the line with core files, but surely rt.jar can be smaller that 23MB?

    Just some thoughts.

    Ryan
    Reply to this Reply to original

  81. fake is afake[ Go to top ]

    If the memo is a fake it snot valid to base any conclusion on it other than its afake..

    more TSS FUD..
    Reply to this Reply to original

  82. Anything to do with the Motz ruling?[ Go to top ]

    Microsoft is appealing the Motz ruling to deploy Sun's JVM with XP on grounds that it will "break" and hinder XP. The timing of this "advertised" complaint is suspicious.
    Reply to this Reply to original

  83. The sky IS falling...again[ Go to top ]

    So Java is a sham and doesn't work for commercial apps, eh? I guess I better pass this along to all of the companies where I have worked that are RUNNING COMMERCIAL APPS THAT ARE WRITTEN IN JAVA.
    Reply to this Reply to original

  84. ALLEGED: Sun Memo Criticizes Java Platform and Solaris OS[ Go to top ]

    Even if this was real, when was this written? I can't seem to get it. All I get is a blank page. But what JDK/JRE are they referring to for Solaris. Didn't 1.4.0 or 1.4.1 fix something absurd like 8,000+ bugs? Did this memo come out when JDK1.3.0 or 1.2.0 was released?

    I'm always upgrading both workstations and servers to the latest JDK and I can't remember _ever_ having had a compatability problem. I don't think I've even ever had a problem going from Sun to IBM JDK.


    On the client:
    I do get tired of some of the JVM stuff. Sure, some things take a lot of memory. In my experience those that take up ridiculous memory are not all that well designed. I use Intellij on Linux and even when I'm debugging with an app-server, it rarely jumps above 35 or 40 megs. I found Borland JBuilder Enterprise to use a lot more. And who cares anyway...I bought a Gig of RAM for my puter for something like $250. But I use TONS of java cliens on my linux puter and love it: SmartCVS, SquirrelSQL, DataStudio, the Axis TCPMonitor, and more! And I don't really have performance problems with any of them.

    On the server:

    I decided to take a look at one of my development servers this morning. It's a Sparc, Solaris 8, JRE 1.4.1, 1GIG of RAM, JRun 4.0. I'm running a pretty large app on there that is using OJB which does a lot of caching, Castor for marshalling/unmarshalling large object grapths to/from XML, then using Axis/SOAP to send the object graphs as DOM Documents. On top of that, there's the JDBC connection pool, and all the JRun stuff that get's started with the server.

    No I don't know about you, but all that sounds pretty memory intensive (Especially the Castor and DOM stuff). I just fired off a whole bunch of requests to it to SOAP requests to get lots of these large graphs, and my memory only once jumped over 57 Megs. I ran an especially huge test that jumped me up to 114! This is by no means a formal test (anecdotal at best), but it seems good to me. And it's even on a solaris machine.

    hmmm...

    On the other hand, if Sun is just pointing out some flaws that need work, that's a good thing. Although the flaws as they've been described here an in slashdot seem more a business unit problem than a Java one.

    Jason McKerr
    Northwest Alliance for Computational Science and Engineering
    Reply to this Reply to original

  85. ALLEGED: Sun Memo Criticizes Java Platform and Solaris OS[ Go to top ]

    And no, I can't speell, typpe, OR proofreed my own crappy grammerr.


    -Jason
    Reply to this Reply to original

  86. ALLEGED: Sun Memo Criticizes Java Platform and Solaris OS[ Go to top ]

    I don't think I've even ever had a problem going

    > from Sun to IBM JDK.

    I can't say the same.

    If I recall correctly, in my problem, IBM's "ClassLoader.getResourceAsStream" method does not allow me to specify the root directory using "/". E.g. "/myFile.cfg".

    Mind you, I encountered these problems about half a year ago.

    My original working setup:
    Tomcat 4.0.x
    Sun JDK 1.3.x
    Windows 2K

    My buggy setup:
    Tomcat 4.0.x
    IBM JDK 1.3.x
    Redhat Linux
    Reply to this Reply to original

  87. ALLEGED: Sun Memo Criticizes Java Platform and Solaris OS[ Go to top ]

    My Together 6.0 installation is about 175MB, not 300-900 as claimed in the article. And it takes less than 1 minute to start and load a medium sized project (100+ classes). I am using a Pentium 4 Dell notebook with 1GB RAM.
    Reply to this Reply to original

  88. ALLEGED: Sun Memo Criticizes Java Platform and Solaris OS[ Go to top ]

    I am using a Pentium 4 Dell notebook with 1GB RAM


    With Solaris?
    Reply to this Reply to original

  89. Something Fishy....[ Go to top ]

    Why does this post have to come out just the exact day when Sun CEO (scott) is making a big presentation to the world of suns vision.

    It seems that it is kinda orchestrated for some wars ahead.
    Reply to this Reply to original

  90. there is nothihg fishy[ Go to top ]

    except ur BO.
    Microsoft has hell lot to do with its own bugs. its not interested in stupid SUNW problems.
    Reply to this Reply to original

  91. Looks true[ Go to top ]

    If it's a fake, it's a good one. May I suggest that someone sends some of them an email to kindly ask them to look at this post on TSS ?

    Just searched on Google...

    Julian Taylor --> Julian dot Taylor at central dot sun dot com
    Steve Talley --> stephen dot talley at sun dot com
    Mark Carlson --> http://servlet.java.sun.com/javaone/conf/speakers/bio-2875/google-sf2001.jsp
    Eugene Krivopaltsev --> In Java since at least 1998 but not mentioned at Sun
    Peter Madany --> definitely at Sun http://www.jcp.org/en/jsr/detail?id=62
    Michael Boucher --> Michael dot Boucher at Eng dot Sun dot COM

                    Yann
    Reply to this Reply to original

  92. Author's Identity[ Go to top ]

    From a Sun employee, I find that the author of the memo is in fact a fellow Sun employee... a junior engineer in the STORAGE division, hardly the right person to evaluate Java's strengths and weaknesses.
    Reply to this Reply to original

  93. Author's Identity[ Go to top ]

    " From a Sun employee, I find that the author of the memo is in fact a fellow Sun employee... a junior engineer in the STORAGE division, hardly the right person to evaluate Java's strengths and weaknesses."
    -- Joseph

    It's Sun's storage division that most heavily embraced Java for fat clients and n tiers, so your remark doesn't make sense. This is where Jini and Swing get their workout. No "junior engineer" could have composed that memo.
    Reply to this Reply to original

  94. Its not a work of Jr. Employee[ Go to top ]

    It takes hell lot of knowledge and deep understanding of all moving parts in JVM to come out with a report like this.
    Even most senior employees must be amazed at this report. A Jr. programmer is not even going to understand most of it.

      Joseph, Just stop being a jerk. U have no clue of what u r talking abt.
    Reply to this Reply to original

  95. Its not a work of Jr. Employee[ Go to top ]

    Might I point out that my information is second hand, from a Sun employee? I'm interested - almost - in what relaying what information I have from a Sun insider makes me a jerk. :)
    Reply to this Reply to original

  96. Its not a work of Jr. Employee[ Go to top ]

    Joseph,
           Nothing in your post warranted that response. Check here for a post I made to the portal feedback forum (where it belongs) for the rest of my views on the matter.

    Chz

    Tony
    Reply to this Reply to original

  97. ALLEGED: Sun Memo Criticizes Java Platform and Solaris OS[ Go to top ]

    http://www.neward.net/ted/weblog/index.jsp?date=20030210#1044876995759
    Reply to this Reply to original

  98. Memo is from a frustated employee at SUN[ Go to top ]

    A serious senior programmer - who has spent half his life time on making java the best is frustated with the new stupid generation of programmers SUN has hired in last 2-3 years.
       If you get a list of employees in SUN, u can draw a lot of <b>Family Trees</b>. This is all because SUN hired most of the programmers thro some reference or someone who is related to one of the employees without proper screening or interviews. Not only this but most of the sales force and marketing people are also like that. They spend more time in meetings or in gym and talk abt their weekend plans more than a <b>stupid</b> JVM memory leak. <p>
       The lack of seriouness and aim to achieve higher is the main reason behind SUNs loss in last few quarters. Its like a illness which spreading across SUN.
       May GOD keep SUN shining. ( or atleast keep apache and JBOSS alive).

    - ex SUNW employee
    Reply to this Reply to original

  99. Is it real or not? (IT Journalism SUCKS!)[ Go to top ]

    Why does the IT media suck so badly? What happened to cut throat hard hitting journalism?

    Can't TSS do some real digging and come up with a scoop?

    Personally, I think Java on Solaris is slow when it comes to the client side application such as the management console and other Solaris applications. A round of updates could not hurt even if the memo is fake.

    On the plus side, on Linux, Mac and Windows client side Java is nice and responsive.

    None the less the world needs to know!
    Reply to this Reply to original

  100. ALLEGED: Sun Memo Criticizes Java Platform and Solaris OS[ Go to top ]

    Smells like M$ plot again.

    .Net 's total failuer in the market is making M$ desperate.
    Reply to this Reply to original

  101. linux lesson[ Go to top ]

    It makes lots of valid points. Does anyone remember the Linux community's response to Microsoft's performance comparison. They said thanks, went off and refactored, and came back with a better product. Last I looked, Microsoft was running a different performance comparison against Linux, this time in its SEC filings. Dooh!

    I think it says more about Sun's investment in Solaris than it does about Java.
    Reply to this Reply to original

  102. ALLEGED: Sun Memo Criticizes Java Platform and Solaris OS[ Go to top ]

    I believe TheServerSide has become the National Enquirer of software development..
    Reply to this Reply to original

  103. Let's look at the facts[ Go to top ]

    What do we know?

    1. The memo is probably fake but that's irrelevant. What's important is whether it raises serious issues. I think it does, and beyond the Sun Solaris implementation.

    2. Java has seen big performance increases in terms of execution speed but still uses excessive amount of RAM for its VM. The comparision with Python and other languages is interesting. Windows is the best platform for VM footprint, but it is still too big. One of the biggest wins for speed is footprint, so this should be tackled.

    3. JVMs still take too long to startup. Hello World should not take seconds to execute.

    4. Sun seems determined to pile more and more into J2SE. They confuse the problems installing Java (and the associated MS lawsuit) with installing libraries. The core set should be much smaller and stick to SPIs wherever possible.

    5. J2SE is full of crud. There are masses of deprecated features and brain-damage that have never been removed or cleaned-up Backwards-compatibility is great but should always be limited. Sun should now remove all deprecated features prior to 1.2.

    6. Sun is finally realising some of the above and 1.5 may address some of the memory problems (at least with shared classes).

    7. It is far too easy to write slow and memory-hogging applications in Java. Java has no serious performance problems these days, even in Swing (IntelliJ IDEA and others prove that). The problem is the level of skill required to produce such high-performance applications.

    8. Sun's VM is not the best, but is the most up-to-date. If you're doing client-side development, then it's often best to stick to it. For server-side, where latest features are often less relevant, other vendors prove a better solution.
    Reply to this Reply to original

  104. RE: Let's look at the facts[ Go to top ]

    1. fake but that's irrelevant. it raises serious issues.


    I agree.

    > 2. excessive amount of RAM for its VM.

    There are two things here. A) each application starts its own JVM and B) more often than not, each application uses a different version of the JDK.

    > 3. JVMs still take too long to startup.

    Hopefully the Microsoft lawsuit will allow Sun to load the common Java VM on startup.

    > 4. The core set should be much smaller.

    Agree. For example, I do not want the Swing library if I do not want a GUI.

    > 5. J2SE is full of crud.

    Good OOP practices should have protected us, the developers, from changes in the library. Most times I end up making a Facade on top of the original Sun class.

    > 6. 1.5 may address some of the memory problems.

    Hopefully.

    > 7. The problem is the level of skill required to produce such high-performance applications.

    And here in lies the danger. Why hire a single professional Java developer when you can get 2 or 3 from University for the same price. Java IS as complex as C++ because of (and every one says this), you need to do your OO right.
    I think that the environment should protect our software better from the mistakes of the unskilled Java programmer.

    > 8. Sun's VM, If you're doing client-side development, then it's often best to stick to it.

    Another option is to write the GUI in a language with smaller footprint (i.e. .NET) and CORBA your way to the server.

    Eamonn J.
    Reply to this Reply to original

  105. each application starts its own JVM[ Go to top ]

    Hm, nice, another mud-slinging on TSS!

    With respect to:
    'each application starts its own JVM'

    There's a JSR (no 121) that specifies several applications running in one JVM while they're insulated from each other. Something like that is already available in the .Net CLR and the JVM should have it too.
    See http://www.jcp.org/en/jsr/detail?id=121

    It would be implemented in Tiger (JDK 1.5).


    gr
    Joost
    Reply to this Reply to original

  106. RE: Let's look at the facts[ Go to top ]

    Eamonn,

    I agree with you completely, with one slight exception on point 5.

    While good OO practise says we should build facades, the JCP process is supposed to produce a lot of those. The XML classes for instance.

    The underlying point is that, if I don't want to use their versions of the implementation of the interfaces (or facades) then I should be able to. In this contet, a different version constitutes either a totally different implementation or an older version of the provided implementation. While Sun does allow you to do that in some cases, it's often done using the somewhat inelligent technique of -D system properties.

    I agree we should be insulated, but I think at most (and I don't really believe this either, but I'd compromise. :)) the interfaces should be in the core J2SE. Implementations should come from elsewhere. Ideally even the intefaces would be elsewhere simply to allow them to evolve at a different rate.

    Chz

    Tony
    Reply to this Reply to original

  107. RE: Let's look at the facts[ Go to top ]

    "Java IS as complex as C++ because of (and every one says this), you need to do your OO right. "

    Java is not 1/2 the complexity of C++. And the tradeoff is it's not 1/2 as useful. I think the Java inventors sided too much for simplicity (simplicity for compiler writers) and left out way too much. I believe the makers of C# made the same mistake.
    Reply to this Reply to original

  108. RE: RE: Let's look at the facts[ Go to top ]

    The point I was trying to make is that Java is a language - that IS easy. However the OO technique is difficult to get right.

    Other languages such as Visual Basic do not have so much OO so it is easy to let a first timer programmer off on VB.

    However, getting you application right using Java WITH OO takes solid experience. Not for the first timer. Therefor it is more complex than other languages to get right.

    If you read the postings they generally go along the line:
    > >> Java is slow, memory consumption is high
    > >> and the garbage collector does not work.
    > Go back to Visual Basic, you obviously don't know
    > anything about Java and good OOP.
    Reply to this Reply to original

  109. C++ vs. Java[ Go to top ]

    Uh.. maybe the current C++, with templates and stuff. Not what most C++ compilers were like 5 years back.
    Things like inner classes (and their ability to create indefinite number of scopes), unclear scoping generally etc. makes it quite hard - albeit in entirely different way than C++ is hard.
    If you do include templates, with partial specialization stuff, avbility to de-const/dereference etc. dynamically inside the template (so for example you can templatize with a pointer as well as reference as well as object), then yes, C++ is much much more complex. Java (in 1.5) is overlooking all these complexities.
    Otherwise, code generation from JAva AST or C++ AST is about the same complexity - if you don't optimize. As for optimization, Java optimization is entirely different game than C++ as you can't optimize Java at compile time nearly as much as C++, so much that comparing them is meaningless.
    Overall, I'd say that except from the shallow (syntax-like) point of view, C++ and Java should not be compared any more than C++ and smalltalk.
    Regards,
    Vlad
    Reply to this Reply to original

  110. RE: Let's look at the facts[ Go to top ]

    |
    | And the tradeoff is it's not 1/2 as useful
    |

    Sorry, but I just couldnt help but bite at this one.

    While I think that we definitely gave up stuff moving away from C++ (generics being the main thing), to say that Java is less useful than C++ is way off. (and this is such an old debate its almost refreshing)

    For a start, there are all the things that are built into the runtime as Standard, like 1 String class (instead of about 8!), checked exceptions, a proper exception class hierarchy, serialisation, remoting, collections etc etc etc.

    Aside from this, there are many things in Java that are just not possible in C++ - like Anonymous Inner classes, Reflection, Dynamic Proxies, network class loading etc. In fact, its the dynamic aspects of Java that make it most useful (simple things like class.forName are very powerful when it comes to such things as XML language bindings).

    Believe it or not, amongst all of the "this appserver is better than that appserver, JDO is better than X debate" in our organisation, were are also still firmly engaged at the "why Java is better than C++" level - it means you keep a good perspective...

    -Nick
    Reply to this Reply to original

  111. Sun's Response[ Go to top ]

    Sun responded to the allegation that the memo was based on a two year old document which refers to an old implementation of Java technology.

    Also says that the issues mentioned in the memo are irrelevant at this point. Sun's Java remains vibrant as a standard and as an open basis for multi-platform products from many companies, including Sun.

    Here is the URL: Sun's Java 'remains vibrant', Sun says
    Reply to this Reply to original

  112. Sun's Response[ Go to top ]

    Sun responded to the allegation that the

    >memo was based on a two year old document
    >which refers to an old implementation of
    >Java technology.

    But the memo makes some references to JDK 1.4,
    which came out quite recently.
    Reply to this Reply to original

  113. Sun's Response[ Go to top ]

    But the memo makes some references to JDK 1.4,

    >>which came out quite recently.

    May be the old document did not mention the version of the JDK, or perhaps to hype the allegation the latest version number was used.
    Reply to this Reply to original

  114. alleged[ Go to top ]

    really??well its a matter of opinion stork club newsreel
    Reply to this Reply to original

  115. really[ Go to top ]

    so thats what Sun Memo was blabbing about
    Reply to this Reply to original

  116. this[ Go to top ]

    so not true buffalo freelance website designer
    Reply to this Reply to original