Slashdot Mirror
Even Sun Can't Use Java
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."
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.
Did you "read" this, it says the problem is
"Solaris" not java itself !.
In the rush to bash Java, the summary here was totally off the mark. From the article:
A review of the problem indicates that these issues are not inherent to Java but instead represent implementation oversights and inconsistencies common to projects which do not communicate effectively with partners and users.
And it goes on to mention issues with Solaris. Nothing about Java itself being inherently problematic, just issues with certain implementation.
InternalMemos is notorious for running hoax emails. This email is no exception. It includes a number of inaccuracies and curious references. The comparisons with Python are just amusing.
Doing a quick search on the names, you'll note that there's no reference to the sender anywhere in Google, let alone associated with Sun. Most of the folks in the CC list do not have Sun email addresses. They're probably friends of the hoaxer. The Sun folks in the CC list include a JavaOne and a guy who has himself on the J2ME JSR.
I wouldn't hold out for Sun switching to Python. haha
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.
Panurge has posted for the last time. Thanks for the positive moderations.
¦ ©® ±
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, which is much more robust and doesn't operate within the confines of a browser.
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 published at the UK Unix Users' Group last year. (And possibly read my reply 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.
I am TheRaven on Soylent News
I don't think p-code really bears much resemblance to Java byte code. Java does a lot of stuff after things have been compiled to byte code. P-code really is just a machine language of sorts that provides a hardware abstaction layer--that is, it is still just machine language. Java's byte code offers things like late binding & reflection, bounds checking, garbage collection, and a whole slew of other things. Many of these features make compiled Java (that is, compiled to a native executable) very difficult at best. And it also means that about 9/10 of the computation time with typical Java apps is spent in the JVM doing these things.
--Be human.
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.
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. ;-)
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()
socket_bind()
socket_listen()
Taken from User Contributed Notes on php.net (author diogo at michelangelo dot edu dot br )
Hey, folks, calm down. This is a memo from a couple of developers with their hair on fire, writing a purposefully inflammatory internal memo to get attention.
(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.
PHP is "the one" for me!
Now with the gtk extensions it does a mighty fine job on the server or on the client!
It has the ease of text manipulation of Perl without all the nasty hacks in syntax. It's cross platform, free, and performance is good. (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 (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.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
How do we know this is even a real internal memo? I mean, this is comming froma site *named* internalmemos.com. Come on! There's a submission form. I could just send any old thing in if I wanted. The only difficult part is making it look convincing. That only takes a few hours of effort. Anyone that has an axe to grind with Sun could have sent this in. That could be some big company or (far more realistic) some random slob that just wants to be mean. Or it could be real. But who cares? As the Score 5 AC pointed out, this is about bugs in the JRE on Solrais, not necessarily about Java in general. Does anyone on slashdot remember what FUD is?
InternalMemos is notorious for running hoax emails. This email is no exception. It includes a number of inaccuracies and curious references. The comparisons with Python are just amusing. Doing a quick search on the names, you'll note that there's no reference to the sender anywhere in Google, let alone associated with Sun. Most of the folks in the CC list do not have Sun email addresses. They're probably friends of the hoaxer. The Sun folks in the CC list include a JavaOne and a guy who has himself on the J2ME JSR. I wouldn't hold out for Sun switching to Python. haha
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.
Well... The Inquirer had a blurb about this about a week ago, before anyone heard about any "memo".
I like Python more than I like Java. Still, in terms of speed (ignoring how much memory it takes), Java is faster.
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.
I know it's very politically-correct to keep lowering the bar for everyone,
Right. We should outlaw everything except raw machine code, that you enter directly in binary. Assemblers are for pussies.
No, Python has had a generational garbage collector for some years (since Python 2.0).
It still uses RC to immediately finalize objects but will collect cyclical garbage as well when it periodically runs.
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.
Get your teeth into a small slice: the cake of liberty
This is the same site that posted the fake id memo. Is their record besides that one mostly spotless? It seems no one here is doubting whether or not this is real.
Quotes from the article that show you didn't read the letter before posting it:
"these issues are not inherent to Java"
"We do not believe these flaws are inherent in the Java platform"
"We all agree that the Java language offers many advantages over the alternatives."
"The customer must locate that release and install it." That, IMHO, is complete BS. I never keep anything but the most recent version installed, on Windows or Unix. The only issue I have ever seen like this was with JHDL from Brigham Young, which used "assert" that was added as a keyword (due to customer requests) in 1.4 -- and it still works if you tell it to compile as 1.3 (javac command-line option). I personally would not support an outdated version when a version with bug-fixes is available for free.
"Typical resident set requirements for Java2 programs include: Hello World 9M" Again, BS. I have a TINI board running that only has 8M of memory total, AND I have an old Handspring (8M) that has Sun's JDK and IBM's JDK and Java3D on it.
"Each of these examples is simple, but they demonstrate the general problem that people cannot program for a particular release of Java and expect that their programs will continue to run." Again, BS. I have been coding Java since IBM released JDK 1.0.2 for Win3.11.... I have never had this problem with ANY code I have written.
And their overall request? "We strongly recommend that management require Java to conform to the Software Development Framework ".
If you would have read the letter before posting it, you might have realized that what they were really complaining about was Solaris 7 and 8. They even point out that Solaris 9 is fixed. The pieces of the letter that suggested other languages was specific to the Solaris implementation, as my comments above prove that their statistics are not valid outside of Solaris.
So, Solaris pre-9 is buggy. Big deal, that has nothing to do with how fit Java is as a language.
Malachi
http://www.google.com/profiles/malachid
Yeah, it's a fake. I work at Sun, and a quick LDAP search lets us know that Sun doesn't employ a Julian S. Taylor. Geez, I wish f'dcompany.com would check this stuff out before they post it. Actually, I wish /. would check this stuff out first...
-Jon
"In a 32-bit world, you're a 2-bit user. You've got your own newsgroup, alt.total.loser." -Weird Al
The typo in the parent post confused me at first (spelled correctly the first time, wrong the second). Furthermore, there does not appear to be a psyco package in Debian.
To clarify:
psyco is the name of the Python specializing compiler. The Psyco project homepage is:
http://sourceforge.net/projects/psyco/
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
I could not find a package for either of these in Debian.
Why would they bring those up, and then within a sentence or two, mention Python. From what I understand, Python is mainly used for server side scripting. I doubt anyone uses Python for serializing anonymous inner-classes!
No, Python is used for everything that a general-purpose language is used for, except anything best done in C is stuffed into C extensions. The exceptions are of course the standard exceptions for C, which basically owns systems programming. (The need for fast, tight code in Python is done by embedding C; see the Numeric extension which provides many very fast number operations comparable to anything else, because the operations are in C.)
In general, Python has no need for anonymous inner-classes; anonymous inner-classes are a worthless hack in Java to provide things that should be provided through any number of other good mechanisms, and even then they only partially and frustratingly succeed. Don't take my word for it, take jwz's word for it (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.
Python modules can be compiled. Write a simple little script that imports your module(which in Python means just about any source file). You'll notice a *.pyc file now hanging out in your directory. Cngratulations, it's Python bytecode.
While I would definitely agree that Swing is slower than native Windows and Unix widgets, they are often plenty fast enough. While I'm not questioning your java programming ability per se, but I've found that oftentimes, slow Swing applications can be attributed to lack of skill/deep understanding of Java as to limitations of running within a virtual machine. You can make very complicated applications with Swing, and while those applications will probably be memory hogs, they are very responsive if they are implemented well. Just look at Netbeans as an example. Check out Swing Sightings on Sun's website for yet more examples.
Why Java sucks , written in 1997, but some points still hold true.
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.
Just so you know... I think the problems that you mention were fixed in Java 1.4... In fact, they were the major concerns of the release other than NIO and the obvious stuff. Also, non-SUN JRE's preform much better as well on the whole. IBM makes the best, but SUN caught up a lot on 1.4, and surpassed IBM in a select few cases. IBM now has a 1.4 JDK for Linux on xSeries(x86). It's only free as in beer, but it's worth toying with to get a feel of where Java is headed in the next few years.
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.
Karma Clown