Even Sun Can't Use Java 833
cowmix writes "It turns out that Sun does not eat its own dog food. Specifically, this
internal memo from Sun strongly
suggests that Java should not be used for Sun's internal projects.
More interesting still, they go on to state which other languages
fullfil Java's goals better than Java does itself. Finally, the
memo states Sun's own Solaris is the cause of many of Java's woes. Yikes."
From the article... (Score:5, Informative)
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.
Hey wait a minute ! (Score:1, Informative)
"Solaris" not java itself !.
Read the Article (Score:5, Informative)
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.
case in point: Volume Manager and Netbackup (Score:1, Informative)
~frank
It's a hoax (Score:5, Informative)
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
Political memos (Score:4, Informative)
Not that I'm suggesting they are wrong, I have no way of knowing either way, I just think that producing memos like this - and getting them leaked - is probably not the smartest way of getting the declared objective.
Admission: I use Java. It isn't perfect. It uses too much memory. It isn't hugely fast. But the applications work and the amount of debugging we have had to do is a tiny fraction of what I would have expected with C++. Its suitability for a given project depends on a whole host of factors not considered in the memo, and it would not surprise me if, for some internal Sun projects, it was inappropriate in its present stage of development.
Re:dog fooding is a microsoft phrase (Score:3, Informative)
Applets? What year are you in? (Score:4, Informative)
Anyway, regardless of the JVM, applets are only applets.
I hate to sound trite, but the fact that you place so much importance on applets (they are, after all, the only example of the technology that you imply exists) leads me to believe you're not really versed in the current trends in Java. The simple fact is that no one use's applets anymore; certainly there is no new development going on in that area. Most Java applications are written for the J2EE platform.
Even at that, those who do wish to write the modern equivalient of applets use Java Web Start [sun.com], which is much more robust and doesn't operate within the confines of a browser.
Re:Kiss and say goodbye to Java language!! (Score:5, Informative)
I hope this illiterate drivel was intended as a troll, but just in case it was not:
Forget Java man and go to PHP!
Java is a general purpose programming language, PHP is not. PHP is a scripting language designed for server side web scripting. Ever tried writting a server in PHP? You can't, it doesn't let you accept incomming socket connections.
PHP is 4 times faster than Java technology 'JSP' (Java server pages).
I'm not sure where you get your numbers from (the link you post is to a non-existent howto in the LDP), but I doubt that they are accurate. PHP is an interpreted language, C is a compiled language, Java is a hybrid (Just-In-Time compiled). C is likely to be faster than both (although a JIT language can make use of run-time profiling for optimisation, so in theory Java could run faster than compiled C code, but this is new technology so it doesn't - yet). Primitives in C are typed, in PHP they are not. This means that PHP has a lot of type checking to do even for simple variable assignments. PHP is unlikely to be faster than Java (although it may still fit your needs better in other areas).This tallies because compiled "C" program is 4 times faster than Java.
PHP is a very lightening fast object oriented scripting language.
PHP is not an OO language. PHP supports a few features of OO, but not the vast majority (public / private methods, inheritence etc). PHP Classes are more equivalent to namespaces than classes.
PHP is 100% written in "C" and there is no virtual machine as in Java.
PHP is an interpreted language (how many times do I have to say this?). There is a virtual machine, and it interprets the PHP script. The Java VM compiles the bytecode to native code at run time (and only once, when the JRE is started in server mode). <oversimplification>
Nothing can beat "C" language
This is the stupidest statement I have ever heard. C does nut support dynamic strings, so only a fool or a masochist would use it for simple text manipulation tasks (ever written a CGI script in C?). C has many advantages, it's a mature language so a lot of work has gone into making it fast. For this reason it is good for low level system work. It is not the best tool for every job. If the only tool you have is C, every problem looks like an operating system...
Java programmers will really "LOVE" PHP as PHP class is identical to Java's class keyword.
Java programmers will loath PHP. It doesn't properly support a large number of features found in Java, because it is not a general purpose language, and it isn't even an OO language. Web developers like PHP because it's simple. For a detailed criticism of PHP look at thi paper [ukuug.org] published at the UK Unix Users' Group last year. (And possibly read my reply [sucs.org] to the criticisms made.
The aim of java was to abstract the OS and windowing system away from the developer, and in this it succeeds quite well (although it still has speed issues and the API is baroque in the extreme in places - try creating a non-blocking port in Java if you don't believe me). PHP is an interpreted scripting language aimed at web design, which has agregated, rather than being designed. Comparing the two is a crazy as saying Mozilla is far better than Linux.
Re:Java Implementation (Score:3, Informative)
Hoax (Score:2, Informative)
First off, this "memo" is the complete opposite of Sun's Java stance. They believe that Java should be used for everything from running enterprise applications on E10K's to apps on your PDA. I don't think that Java should be used everywhere, and I'm a big fan of the language.
Second, these might have been arguments against Java a couple years ago, but they simlply aren't true any more. For enterprise-level applications, Java outperforms Perl or someother scripting language on every front (scalability, preformance, maintanability, etc.).
Finally, these bugs don't even exist! I seached for the bug id's in Sun's bug database, and didn't get anything.
As usual, the Slashdot community has formed a collective knee-jerk reaction against any technology that isn't open source and Perl.
Resident (Score:3, Informative)
The memo was talking about how much memory the program takes when it is running. You are on the right track, the original poster was wrong. I haven't tested it myself, but the numbers in the memo seem about right with my experience. The reason a "hello world" program takes up 9M is not because the program is inefficient, it is because Java requires a JIT compiler and other crap be loaded and running with the program. The actual "hello world" code and data were probably only a few kilobytes (if even that). The compiler, gc, &etc took up the remaining 8.9M--not to mention a bunch of processing time.
Java is only free if your memory and cpu aren't worth anything. ;-)
Re:Kiss and say goodbye to Java language!! (Score:2, Informative)
Java is a general purpose programming language, PHP is not. PHP is a scripting language designed for server side web scripting. Ever tried writting a server in PHP? You can't, it doesn't let you accept incomming socket connections.
Ahem ...
socket_accept() [php.net]
socket_bind() [php.net]
socket_listen() [php.net]
Taken from User Contributed Notes on php.net (author diogo at michelangelo dot edu dot br )
Re:case in point: Volume Manager and Netbackup (Score:3, Informative)
#1: No it isn't. VxVM is a Veritas product. Sun just resells it.
#2: Yes, the VMSA GUI (or VEA or whatever they call it today) is so stupidly broken it's not funny. That's why you have to learn the commandlines like vxvol, vxdg, vxmake, vxassist, vxdctl, vxdiskadm, vxedit, etc....
The GUI is worse-than-useless; it's counter-productive. Stick to the command-line and you'll be fine!
Damn shame they dropped the old vxva GUI.... _that_ thing rocked the house!
They've gotten what they wanted. (Score:2, Informative)
(Which they have done. I wouldn't be surprised if they're having a rather painful meeting when word gets back in Sun that this got published externally.)
I used to be a Sun Java Architect and I worked on both internal and external projects on both Solaris and Windows. I posted a lot of bug reports myself, and got some of those "will not fix" replies.
What these guys are primarily complaining about is not that Java isn't good for some things, but that Sun developers have a perpetual problem that they're almost always the cobbler's children that go barefoot. As someone else mentioned, the Windows implementation of Java seems to get priority for most things -- although, as I recall, the advanced Hot Spot optimizer was available for Solaris first (makes sense, the x86 instruction set architecture is such a pig.)
But there is a second thing going on here that you might not undderstand, which is that ever since Scott began to push Java, the old C/C++ programmers have been scrounging for reasons to us C instead of Java. Sometimes tht's appropriate, but a lot more often the difficulties are the result of someone trying to write C in Java.
In fact, this memo describes several problems that are clearly just such problems: for example, the notion that a Java-based shell should fork a new JVM for each command line execution. This is the natural way to handle the problem in C; fork()/exec() was invented for this. But it isn't the appropriate idiom in Java for exactly the reason they describe -- it means starting a whole new JVM, which is expensive. (The appropriate idiom, by the way, is class-load by name and invoke a method.) As I understand it the 1.5 JVM will have a extension that will make it easy to create virtual address spaces within the JVM for running sub-programs, which is probably a response to the issue.
The most important thing the memo is pointing out really is a problem: the freakin' language and evironment changes every time some propellor-head gets a slick idea. I posted a couple of days ago complaining about just this in the case of the for(String s: c) idiom and a couple of other such things in 1.5. This, and the way things break between Solaris and Windows, and among minor version changes, really is a problem that makes developing large-scale, multi-version applications in Java difficult.
Re:PHP is the destination (Score:3, Informative)
Now with the gtk extensions [php.net] it does a mighty fine job on the server or on the client!
It has the ease of text manipulation of Perl [php.net] without all the nasty hacks in syntax. It's cross platform [php.net], free [php.net], and performance is good [linuxplanet.com]. (Probably better than Java, since my own testing indicates it's considerably faster than Python)
It makes a good, all-around scripting language for sysadmining, UI management, etc. and it even makes a good case for fast web development!
Among other things, a web server [freshmeat.net] (yes, a replacement for Apache!) has been written in PHP!
I figure that with all the noise of "web services" this, and "cross platform" that, there's a good chance that PHP could be the "next big thing"...
Yeah, I use PHP an awful lot.
hoax, this memo is (Score:1, Informative)
InternalMemos is notorious for hoaxes (Score:5, Informative)
Re:Anonymous Inner Classes (Score:2, Informative)
Python supports a limited form of lambda, which is kinda-almost-like an anonymous inner-class. And interestingly enough it cannot be serialized by the python pickle module.
Re:Hypocrisy? (Score:5, Informative)
Re:Smells of a Fake (Score:2, Informative)
It's not just the benchmarks that say it either. The creator of Python, Guido Van Rossum, says it as well.
"The best approach is often to write only the performance-critical parts of the application in C++ or Java, and use Python for all higher-level control and customization."
That quote is taken from here. [python.org]
Re:Java is a toy language (Score:1, Informative)
Right. We should outlaw everything except raw machine code, that you enter directly in binary. Assemblers are for pussies.
Re:Smells of a Fake (Score:3, Informative)
It still uses RC to immediately finalize objects but will collect cyclical garbage as well when it periodically runs.
Re:Smells of a Fake (Score:5, Informative)
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.
Is this real? (Score:3, Informative)
Perhaps you should read the letter b4 posting it. (Score:4, Informative)
"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
Re:InternalMemos is notorious for hoaxes (Score:5, Informative)
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.
THERE IS NO JULIAN S. TAYLOR @ SUN!!! (Score:3, Informative)
-Jon
Re:From the article... (Score:4, Informative)
Psyco, not Pysco, and no psyco package in debian (Score:2, Informative)
To clarify:
psyco is the name of the Python specializing compiler. The Psyco project homepage is:
http://sourceforge.net/projects/psyco/ [sourceforge.net]
pysco, on the other hand, is a group of python modules for composing music. More information about pysco is available here:
http://www.slinkp.com/code/#pysco [slinkp.com]
I could not find a package for either of these in Debian.
Re:Anonymous Inner Classes (Score:5, Informative)
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.
Re:Smells of a Fake (Score:2, Informative)
Re:THERE IS NO JULIAN S. TAYLOR @ SUN!!! (Score:5, Informative)
I found Julian here [auburn.edu] and here [google.com]
Re:InternalMemos is notorious for hoaxes (Score:2, Informative)
For instance, bug# 4460368 [sun.com].
Re:I question the validity (Score:2, Informative)
Obligatory jwz reference (Score:3, Informative)
Re:I also have experience (Score:3, Informative)
Swing widgets themselves work reasonably well and are fairly easy to extend. The problems with Swing and Java are in areas like window management, focus, native LAF, drag-and-drop, and desktop integration. And for many of those problems, there are no easy workarounds because they involve native code.
Re:THERE IS NO JULIAN S. TAYLOR @ SUN!!! (Score:4, Informative)
Re:all non-Windows JREs (Score:3, Informative)
I'm fairly sure this is a hoax memo, but even if it's not, it only talks about the implementation of Java on Solaris.
The main reason I like Java is that I won't have to do anything, and my programs will magically get faster, support 64bit processors and other architectures. Java has the potential to be faster than C. Java libraries/classes can have functions inlined at run-time. C has to be recompiled. Java can optimize for whatever processor it is running on. C has to be compiled for the least common denominator of hardware it will be running on. Java programs have an extensively tested standard API of functions to ensure backwards compatibility. In C you may have to recompile or change code whenever a new version of Windows rolls out. Java is a very well structured object oriented language compared to C or C++. Java SQL database drivers must adhere to strict SQL standards to be considered for different levels of JDBC compliance. I can write SQL that is garaunteed by the JDBC driver to work on a database, thus having true database independance. In C, each vendor implements a different subset of SQL in different ways such that you have to pick up a third party abstraction layer, or write your own, or target one database (ODBC doesn't work, even Access runs queries locally).
The only downsides to Java is: all java programs will use more memory than C programs... always! Java programs will take longer to start until a shared VM is implemented(is a JSR right now). Java will be slightly slower than C until Java has had about half as much time to develop compiler(JITC) technology that C has. Java will be slower at floating point until an API for fast system-dependant/non-IEEE floating point math is supported (This is why people claim, and are accurate to a degree, that Java isn't as fast as C at raw number crunching... This is probably the only reason as well).
Of those, the only problem that will always plague Java is large memory footprint. That is because it comes with it's own libraries and must do garbage collection.
It's appearant to anyone (like g4dget) that SUN sinks more time into the Windows JRE than anything else. The second biggest, as of 1.4, I would have to say is Linux/Mac. Solaris is the lowest on the list really. Most people that use Solaris use it for Oracle. The Java market has always been on Windows and IBM machines. IBM rolls their own, and they do a great job. Maybe they will release theirs a bit more free if their agreement with SUN will let them. I don't think they are allowed to discuss their contract with SUN because of the contract itself. At least, that's the rumor about the Java contracts that was on the net about 5 years ago.