Why is Java Considered Un-Cool? 1782
jg21 writes "After the Slashdot discussion on Paul Graham's 'Great
Hackers' essay, it had to happen. Java developers have taken umbrage at
Graham's assertion that "Of all the great programmers I can think of, I know of
only one who would voluntarily program in Java. And of all the great programmers
I can think of who don't work for Sun, on Java, I know of zero." Now in JDJ Sachin Hejip pinpoints the Top
Reasons Why Java is Considered Un-Cool and to tries to debunk them. He levels some of the blame at the Java compiler for "too much
chaperoning" and speculates that Java fails the geek test precisely because
"it's such a language-for-the-masses." But isn't he missing the point? Enterprise-grade apps and "coolness" may be inapproriate bedfellows. Besides, does any language offer both?"
Its just a tool (Score:5, Informative)
Java is a tool - just like every other programming language.
People do/don't use Java for many reasons - the choice of a programming language in a commercial environment depends on many different factors.
I work in Java - I can't say it excites me but it does the job.
Re:Maybe because it's slow ? (Score:4, Informative)
This isn't to say Java is perfect for everything, but it is for some things.
Re:lame (Score:2, Informative)
Not really. Tried it recently? eclipse is a good example (eclipse.org) of fast java program.
>Java is not supported by all platforms
You can get a JVM for most if not all platforms. It also works on XP (don't confuse MS JVM as being a workable JVM, its years old).
>All the Java "binaries" I've tried relies on me having installed a local interpreter.
Actually you can get a program which will create an EXE for you, but then that defeats the purpose of Java doesn't it? Everyone moans about having to download the JVM, why don't people moan about the VBRUNxxx.dll and MSFC that you have to install to get EXE apps to run sometimes.
> Hey, I said this is MY list. I dislike object oriented languages,
Your basis of dislikes is hardly a good argument for what is wrong with Java.
70mbit/sec, 100% Java (Score:1, Informative)
Totally mis-informed (Score:4, Informative)
The number of mis-informed posts on this subject is staggaring. An attempt to debunk some of them:
Java is slow - This is a myth. A long-running Java app running under HotSpot will over time grow to be faster than nearly any simmilar C or C++ app. Why? Because the Vm can over time learn how the codepath actually is executing and optimize it at the assembly level. The only way you could consistantly achive performance as good would be to hand-code the whole app in assembly, and thati s assuming you already know in advance exactly how the program will be used so you know what paths to optimize. This is highly unlikely.
Java UIs are slow - Java UIs are only as slow as your toolkit. Yes, Swing blows ass. But there are Java bindings for Gtk, Qt, and wxWindows, all of which are pretty cross-platform. And there is also the SWT toolkit from IBM which uses native widgets when possible, and when not falls back on its own widgets.
Java needs a VM so you can't run it everywhere - THis has to be the dumbest one of all. Since when can you write any resonably complex C or C++ application for multiple platforms without some effort? Any C/C++ app targetting anything more than basic POSIX will be littered with #ifdefs everywhere. With Java at least you can complile it just once, then ship multiple VMs , rather than having to adust your code and re-compile for every target platform.
Re:Well... (Score:2, Informative)
Re:Maybe because it's slow ? (Score:5, Informative)
Everyone thinks "Java is slow" because the only time they experience Java is in a Swing app. Swing is VERY bloated and therefore very slow. The only other "slow" processes in Java are Garbage Collection, which is pretty minimal if the app is written correctly, and the initial startup of the VM.
Look, for example, at Eclipse IDE. Eclipse is a Java app, and its extremely powerful and not very slow. Why? They use their own widgets that have less overhead, they are not using Swing widgets.
Also, a correctly written OpenGL java app has been proven to perform at 85% the speed of its C counterpart (yes C, not C++). A couple of guys (I can't find the link) ported QuakeII to java to get this statistic. Not bad considering the relative youth of OpenGL bindings in Java.
I once had a "Java Sucks" attitude myself (I've been a hardcore C++ programmer for over 9 years), but I must say, after using the language for quite some time (~2 years), I've become very fond of it, and have written several large & FAST Java apps -- in about 70% of the time it would have taken to write in C++.
Re:promise (Score:3, Informative)
Re:Why is Java Considered Un-Cool? (Score:3, Informative)
1) Java in OSX (as an example) doesn't require a classpath at all.
2) Two problems with pointers: a) even "real" programmers make mistakes. b) in real, rather than one-developer toy, development who owns an object/lump of memory and therefore can/must delete it is an issue.
Re:who cares what he says? (Score:4, Informative)
Re:who cares what he says? (Score:2, Informative)
Re:lame :) (Score:2, Informative)
However eclipse itself is built on java and isn't slow.
Only slowness I have seen in java is in applets in browsers or coded to the MS JVM.
Re:Maybe because it's true (Score:4, Informative)
Re:Maybe because it's slow ? (Score:4, Informative)
I've tried the 1.5 beta and it seems to go a long way toward addressing this problem. It feels as fast as native, and easily beats gcj in my own unprofessional benchmarks. But massive Java applications like Eclipse and NetBeans still perform horrendously slow for me, even with the server vm, and I doubt it can be blamed on any gui toolkit.
Re:Maybe because it's slow ? (Score:5, Informative)
I have no complaint about the speed of a Java application once it is up and running. The only problem I have is that the runtime takes so long to heave its vast bulk into memory and fiddle with stuff before the app. gets control.
Notice that as the size of the app. grows, and the time you spend in it begins to dominate the time you spend getting there, this becomes less and less a problem. But it's still noticeable. The time-to-first-interaction is painful here on a box that opens non-Java, non-Gnome app.s in what my human nervous system perceives as zero time.
There's no reason writ in stone for code compiled to an abstract architecture, running on a suitable interpreter, to be slower than native code. It could be *faster*, if the architecture is well-designed and the interpreter well-written. I have no doubt that someone could trot out an app. which runs faster in Java than in native machine code made from well-crafted C.
Re:Why is Java Considered Un-Cool? (Score:4, Informative)
2) No pointers. Real programmers know how to use memory properly. That is all.
Real programmers also know how pointer aliasing can absolutely kill optimization. They therefore avoid pointers wherever possible, resorting instead to constructs such as Fortran 90/95/03's ALLOCATABLE(:) arrays.
Re:Go write me an OS in Java (Score:3, Informative)
Regards,
Steve
Re:Well... (Score:3, Informative)
Debunking Pro-Java Myths (Score:4, Informative)
Here are his usenet posts [google.com] on the subject.
Re:who cares what he says? (Score:3, Informative)
Re:Why is Java UnCool? (Score:3, Informative)
Most people, however, will either use a manifest file:
manifest.mf:
Class-Path: main.jar lib/library.jar lib/otherlib.jar
Main-Class: org.slashdot.example.MainClass
(Don't for get the blank line at the end).
And/Or they will use WebStart, where you declare what you need in XML, and it can be launched and is automatically updated through the internet when available.
All this is free of course, and so is Ant, which you can use to automatically compile and build your directory structure, including your executable jar file and any libraries you need.
If you have a hard time running a Java application, it's the developers fault. There are PLENTY of ways to make it easy... easier than installing software on any other system.
Re:Also Speed (Score:3, Informative)
Re:Maybe because it's slow ? (Score:3, Informative)
Anger/distrust of liars, Sun-dependence, OS pain. (Score:3, Informative)
First, there's still anger and distrust of Sun. When Java first came out, Sun promised to help make Java a standard not solely controlled by any one vendor, and Sun started working with ECMA and ISO to make it so. IBM invested over $1billion with that understanding. Then Sun suddenly decided to take Java out of the standards process, and take complete control over Java. Yes, there's a "Java Community Process", but look at the process: if Sun doesn't like it, it's dead. Period. That's not an independence, it's a dictator model. And it's not necessarily benevolent; in an open source software project, you could fork the project if things went really badly (e.g., XFree86), but there's no mechanism for a true 'vote of no confidence' in the current process.
Fundamentally, developing in Java still primarily involves kneeling to Sun. We have lots of C and C++ compilers, with vendor-independent standards for them. Many other languages have standards, too. There's no need to return to a language totally controlled by any single vendor, that's a model from decades ago. Yes, there are other Java implementations, but not many; few others support the GUIs, and none support the massive library that's the primary point of using a language like Java. gcj does great stuff, but try compiling a normal Java program with Swing and other key libraries. C# is heavily controlled by Microsoft, and there are reasons to distrust that too, but at least Microsoft managed to release the language fundamentals to a more neutral party; why can't Sun exceed those low expectations?
And on most systems, implementing a Java system is a pain. It doesn't come with Microsoft, who's actively trying to kill it. It doesn't come with any purely open source software OS (Fedora, Debian, etc.), because it's not open source. This isn't a killing problem, but it does make development of Java applets essentially hopeless -- because it's quite likely that users will NOT have the necessary plug-in. You can do Java application development, and install the necessary libraries -- on servers that's not a big deal, but it's a little more painful on clients for client applications. But at that point Java enters a crowded field: there are LOTS of languages that can be used this way.
There's a lot to like about Java. But Sun has managed, through a series of missteps, to make a lot of people unhappy and avoid Java, even if Java would be a fine fit technically.
Re:Well... (Score:3, Informative)
Exactly. It was the first JSR [jcp.org] created as part of the Java Community Process. The final API can be viewed on the JCP website. [rtsj.org] The "reference implementation" being used for testing can be found here [timesys.com].
Keep in mind that the API is most likely to show up on hard real time systems and probably won't be available on your standard desktop OSes. (Windows? Hard realtime? *rolls eyes*)
Re:Maybe because it's slow ? (Score:4, Informative)
I have no complaint about the speed of a Java application once it is up and running. The only problem I have is that the runtime takes so long to heave its vast bulk into memory and fiddle with stuff before the app. gets control.
You should try using Java apps compiled with gcj or one of the commercial traditional Java compilers. There's nothing set in stone that requires Java to be interpreted.
JRE 1.5 should help quite a bit also.
Device drivers don't hit the Java "soft spot" (Score:3, Informative)
Re:One word. (Score:5, Informative)
At least this way you don't have to maintain it, but if you add
Hope that helps!
Re:Well... (Score:5, Informative)
In many situations, Java absolutely thrashes VBS/JS/Python/Perl. In other situations, it doesn't. The numbers certainly shouldn't lead you to conclude that Java is the slowest of them all.
SWT (Score:3, Informative)
*You still need to use layout managers as in the other frameworks, but this is a given for cross-platform apps.
Re:Also Speed (Score:3, Informative)
Re:Java is unpractical!!! (Score:2, Informative)
And the "developer that creates scripts of executable that start the application" is essentially implementing a hack to get around this problem, not solving it. Java is supposed to be cross platform remember? You're supposed to be able to run a ".jar" bundle without setting custom options, remember?
Re:Maybe because it's slow ? (Score:4, Informative)
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ System.html#gc() [sun.com]
Re:One word. (Score:5, Informative)
This issue was solved a long time ago.
You put your
Re:Depends ... (Score:5, Informative)
I used ACE for a previous multithreaded server and the project was very successful. We developed on Linux and FreeBSD but had no difficulty porting to Solaris, and could have ported to Windows with a couple of days of effort (we had use the occasional POSIX-specific idiom, but this was our own fault, not the toolkit).
The author, Douglas Schmidt, is a well-known standards wonk and performance freak -- an interesting combination that results in a kit that provides full cross-platform support while running hard with C++'s approach of "you don't pay for it if you don't use it." The kit included a full CORBA ORB [wustl.edu] that supported realtime operation (ie, bounded maximum delay).
Probably the best compliment I ever heard about ACE was a from a very senior coworker who commented that ACE was "not bad, for C++." Trust me -- from him, that was high, high praise.
Having said all that, when I have to share the tree with other developers, Java is my favorite mainstream language.
Re:Great Programmers? (Score:3, Informative)
(Although I think Martin Fowler's language of choice these days may be Ruby.)
Re:Depends ... (Score:3, Informative)
Worth considering, anyway.
Java is slow - so what? (Score:3, Informative)
Anyone who has worked with budgets in large corporations can tell you Developer/Tester hours are generally the majority of the budget. Hardware is a drop in the bucket (and you can even capitalize it). On many projects I've worked on, Java has driven the people cost down resultig in a net savings even though we may have had to throw a crap load (official Business terminology) of CPU/memory at the application.
Re:Depends ... (Score:3, Informative)
Open source cross platform C++ libraries include Boost, ACE, STLSoft, and Loki to name a few.
You should give Python [python.org] a try as well.
Re:Java doesn't play nice with other children (Score:5, Informative)
Compile in kernel support for misc binaries on linux. Read Documentation/binfmt_misc.txt to learn how to use it. Read Documentation/java.txt to learn how to use it with java. On any recent version of windows it works to just type the name of the jar file.
Here I am with some code written in Java, and I want to call it from Tcl. Write a quick C wrapper, link the .o in, and package require... no...? How do I do that, then? 0 511-legacy.html [javaworld.com]
The first google hit - http://www.javaworld.com/javaworld/jw-05-2001/jw-
Here I am with a library written in C, or Fortran, and I want to call it from Java... well, how badly do I want it?/ [sun.com] It is really easy.
http://java.sun.com/docs/books/tutorial/native1.1
Re:Lack of Flexibility (Why *I* don't like java) (Score:4, Informative)
So you could do something like this:
public Class CommandHandlers
{
public command_Help()
{
}
public command_Save()
{
}
public void command_Exit()
{
System.exit();
}
public void doCommand(String command)
{
getClass().getMethod("command_" + command).invoke(this, null);
}
}
This is really basic, but you get the idea. Some of your other complaints are annoying, but not as big a deal as you seem to think. I have wanted autoboxing about twice, I don't use things like Integer much. I just use the primitives. I have wanted generics for quite some time, avoiding the need to typecast (and to get compile-time checking) when using collections, but that's a minor thing, and is coming in the next version (along with autoboxing/unboxing).
Helper functions have to be part of a class. So what? Make a Utilities.java if you want and call them from there. You have to put them all in a
I don't find the class library nearly so complex as you seem to. I think it's eaiser to work with than standard C++ or MFC. Sure, clib is a simpler, but it's also less capable.
Most of the complaints I see about Java boil down to "but it's DIFFERENT". So what? Every language is different. They all have strong and weak points. If I could have Java's code with C's memory usage, I'd be so very happy.
Re:What is this responding to.. exactly? (Score:4, Informative)
Re:Depends ... (Score:3, Informative)
2nd that. I've used ACE on Winnt, Solaris, HP/UX 10.20 and 11, and Linux. I'd also recommend reading Schmidt's various papers on design patterns. Many of these are implemented in ACE and greatly cut down on design/coding time as well as bugs in the code.
Top reasons why Java *is* cool... (Score:5, Informative)
1. It runs everywhere unmodified. This has got to be the coolest thing of all, and the reason I adopted Java in the first place. At the beginning this was not always true, due in major part to the AWT graphics libraries, but today it is.
2. It's more productive to work with it, leading to fewer bugs. This is very important in business apps. I certainly no longer get C/C++ pointer problems, memory leaks, or perl syntax error problems.
3. It is fast (ok, it loads slow the very first time, but with JDK1.5 this seems to being addressed as well). Somehow Java lends itself so easily for users to write efficient code (i.e.: multithreading is a snap and platform-independent), that somehow the applications we've been replacing with it simply run at least twice as fast as the older C++, VB, and perl apps.
4. It is simple. Sure, some hackers like garbage-looking code because they think the harder to understand their code the cooler it is, but in my book the cleaner and simpler code wins any day, specially when programming in a team environment. I think Java should be given credit as the environment that brough simplicity back to programmers in the internet age (just as VB did in the client-server day).
5. You can use multiple tools to develop the same code base. Heck, and now with ANT (possibly one of the coolest tools in recent times) you can choose your IDE (or command-line if that's your thing) and move the project back-and-forth between IDEs to take advantage of each (GUI design, refactoring, etc). Choice is a good thing.
6. I'll repeat it again: How cool is it to develop in Windows and drop the app unmodified in Linux or OS/X and see it run as expected with NO changes to the code? Or if you prefer, develop in Linux and deploy in Windows. Either way it works.
7. It is standard. Sure, it is not open source but then again not everything has to be. I think the fact that open sourcers advocate freedom should be reason enough to allow other companies to choose if they want to free their software or not. It is their choice. The fact that it is standard means that Java is protected from the "Unix division plage" where now almost no Unix is compatible with any other Unix. Geez, even Linux is starting to become incompatible with all the different versions of itself. Sometimes centralized control is a good thing.
Re:Paul Graham isn't Cool, Duh. (Score:2, Informative)
Re:Well... (Score:3, Informative)
I don't know why you find that funny. That's exactly what Symbolics did. [wikipedia.org] They beat Unix to the "Workstation" market by several years, too. Many Unix Haters were very upset when their LISP machines were replaced with Unix [xahlee.org]:
This is the fifth day I've used a Sun. Coincidentally, it's also the fifth time my Emacs has given up the ghost. So I think I'm getting a feel for what's good about Suns.
One neat thing about Suns is that they really boot fast. You ought to see one boot, if you haven't already. It's inspiring to those of us whose LispMs take all morning to boot.
Another nice thing about Suns is their simplicity. You know how a LispM is always jumping into that awful, hairy debugger with the confusing backtrace display, and expecting you to tell it how to proceed? Well, Suns ALWAYS know how to proceed. They dump a core file and kill the offending process. What could be easier? If there's a window involved, it closes right up. (Did I feel a draft?) This simplicity greatly decreases debugging time because you immediately give up all hope of finding the problem, and just restart from the beginning whatever complex task you were up to. In fact, at this point, you can just boot. Go ahead, it's fast!
Besides, it's not like a task scheduler is a hard piece of code to write. It's actually stupidly simple to write. The hard part is creating an algorithm that will most effectively extend CPU resources to running programs. What is effective depends on the purpose of the OS. See "The Dining Philosophers Problem" for an example of the issues that task schedulers must resolve.
AFAIK, its not the API but the language features (VM and garbage collector) that don't allow deterministic behavior.
1. VMs by their very nature are deterministic. If they weren't, your CPU wouldn't be either.
2. Garbage Collection is as deterministic as the algorithm behind it. Standard "mark and sweep" algos are indeed deterministic.
None of this has anything to do with compiled Java code, which runs in as deterministic a fashion as you code it. Do you even know what "deterministic" means?
I'm not saying that C/C++ are better languages but you don't have these problems there.
Yes you do. Any problem you code, you have in any language you code it. If you choose to write a device driver with a random timeout inserted, you must take responsibility for that behavior, no matter what the language. If you require that your device driver have an uninterrupted time slice of X milliseconds, then you must use the OS services available to ensure that you have a time slice of X milliseconds.
It's not a question of performance, but deterministic behavior and guaranteed maximum latency.
Maximum latency is not a determinable factor in ANY language, save for when real-time services are utilized. If you utilize real-time services, then it doesn't matter what language you use as long as you have access to those real-time services.
Re:Depends ... (Score:2, Informative)
C/C++ is great for embedded work, its the perfect abstraction for what you do in assembly, but this isn't what the "cool hackers" are doing these days.
They are doing higher-level applications with more abstraction. At this level Python/Perl/Php are extremely flexible/powerful/easy to use.
Before you drive your camry make sure you check out the saturns
Re:Well... (Score:3, Informative)
You use the APIs provided for Device Driver writing. Java allows you to access memory mapped areas (see the java.nio package). All that's needed is an API to obtain that area. Since you normally don't want to give that functionality to developers, it would have to be part of a Device Driver API like Sun's JDDK or JNode's OS services.
State in Functional Programs (Score:3, Informative)
Single-use values are used to represent the parts of the outside world that can change -- when, say, inserting a record into the database, you pass a value representing the database to the "insert" function, and it returns a value representing the modified database, and invalidating the previous "database" value.
Arguably the invalidation of the old value is still a side-effect, though, and it's still somewhat awkward to use.
Monads approach things the other way around, permitting you to set up purely functional "pipelines" through which state will be passed at runtime (but the state-passing need never be explicitly exposed, and in the pure sense cannot be).
Monads work very well, and maintain purity (without having to pass extra arguments around everywhere), but they're very, very mind-bending to think about until you get accustomed to them.
There are also other monad-like approaches (e.g. "arrows") which are possibly better, but this is an area that's still being actively researched.
So, it's possible today, but really it's an issue computer scientists have only recently started to experiment with in earnest; I expect we will have even better approaches for managing state in functional programs in the next few decades.
Cool things about Java (Score:3, Informative)
It does have some redeeming features tho (it certaining is a better COBOL than COBOL!)
1) Java has absolutely the best programming tools out there
There is nothing out there that touches the Java IDEs such as Eclipse and Intellij. Some of the advanced features they provide like intelligent code completion and some of the refactoring support are impossible to do with weakly typed languages such as Perl or Python, and very difficult to do with natively compiled languages such as C/C++.
2) Java seems to becoming popular for a lot of OO and software engineering research. A lot of the originator of ideas such as design patterns (Erick gamma), refactoring (Martin fowler), XP and test-driven development (Kent Beck, Ward cunningham) are Java people.
3) You can do some amazing hacks in Java, using features reflection, dynamic class loading and byte code engineering, etc.
C++ looks like it's more powerful than Java because it supports templates, operator overloading etc, but Java also has some features that let you do some quite advanced things. For example look at the Jakarta Byte code engine library (BCEL) and look how it has been used in AspectJ and Jython. For example in Jython you can run an embedded Python script in your application that can seemlessly call any Java code, catch Java exceptions and so forth - i can't think of any language designed for embedded scripting that is this convenient.
4) Java has a huge open-source development community
The average Linux desktop user probably doesn't realise this, but there is absolutely piles of open-source Java development going on. A lot of this is on libraries useful for server-side enterprise deployment, web frameworks, workflow engines, object-persistence layers etc. but there is no shortage of projects out there.
On the whole i think the Java world is more interesting that people give it credit for.
Re:Debunking Pro-Java Myths (Score:3, Informative)
I don't know how you ended up modded 5-insightful, but you are the one to be hugely wrong.
If you don't check the bounds of every single array, you could be exposing buffer overlows in your application, which is a huge security hole. +1 for Java
Why should I have the burden of array bounds checking forced on my neck? In C++ I can skip it wherever the array access is trivial, and that's a lot of cases. What happened to freedom of choice?
Faster when run how many iterations under hotspot? 1? 10? 100?
First of all, no benchmark runs 1 time only. Secondly, the hotspot compiler does not re-optimize an already optimized block of code.
For one, most people use the Collection or List interfaces for utility classes so that you can pass in any type of object
This has several drawbacks: a) it forces you to go back to where the collection is created to see want kind of key is being used b) it allows for any type of object to be inserted in the collection, which is undesirable.
Additionally, Java 1.5 has templates so it is a moot point.
Java templates are nothing more than autoboxing. The Java 1.5 generics still use Object-derived instances internally, with many disadvantages: a) losts of unecessary dynamic casts that slow down the program, b) lots of unecessary small object allocations like integers.
Just for reference, I am *not* a Java developer.
It is obvious.
both are ideal for certain situations
C++ is much better as a language specification than Java (with many minor problems), but the language environment has serious flaws. Imagine a C++ running with garbage collection and the same toolset as Java, and you can easily see what language is the best.
until Java Vms are built into the OS
BS. You don't need that built into the OS. VMs are frequently updated.
where startup time is not a huge requirement and ease of development, debugging, and security are a higher priority, Java wins hands down
You got that one right, mate.
Re:Depends ... (Score:3, Informative)
the problem is... (Score:3, Informative)
it failed on both counts.
Re:the real reason (Score:1, Informative)
Now, how serious is this leak? Not too bad in most cases, but it can be serious if using application frameworks that dynamically generate classes and load them (like Java Server Pages). And so, you have to reload your server every once in a while. Of course, you could just allow it to be unsafe and reclaim those TIB's, since nobody in their right mind would actually reload one of those old classes anyway.
I just thought I would bring it up since so many Java coders get their panties in a bunch when someone disses their language. Me? I program in Java, but I agree that it is a terrible lanugage. Unfortunately, I can't afford Franz Lisp (and only use CLISP for non-gui stuff), I don't really like Qt (sorry C++, I liked you the most), I hate PHP, don't like the fact that ObjectiveC isn't useful off of the Mac,
You want lisp in a box (Score:3, Informative)
This link [common-lisp.net] normally works, but common-lisp.net appears to be offline as I type. Google [google.com] will show you the sites for various platforms
Re:Well... (Score:3, Informative)
Java is NOT slow! (Score:3, Informative)
One of the reasons that some consider Java uncool, is because of the myth that Java is slow. I call it a myth, and I will try to explain why it is a myth. (Actually, in theory, Java will outperform C++ soon).
Just to take a swing at another myth, while we're at it: When it comes to size of the stack, how you want the garbage collector to use memory etc., you CAN in fact give the JVM parameters to control this stuff.
Java isn't slow anymore. It may be true, that (small) Java applications generally takes a little longer to start up, if you didn't use an AOT compiler (like for instance the "free as in freedom" [gnu.org] compiler GCJ [gnu.org] or the more mature but proprietary Excelsior JET [excelsior-usa.com]). Its true that early versions of Java were slow, but 1.4.x isn't generally slower than C++, in fact, I wouldn't be surprised if it outperformed C++ on general terms one of these days.
One of the things that makes Java "not slow", is actually the way memory is allocated. Its rather cheap to allocate memory in Java, compared to other languages, and its even cheaper to "free" memory, since you don't do it, you have the cost of the garbage collector instead. The garbage collector in Java is very fast, compared to older garbage collectors.
(For the interested, IBM [ibm.com] has an article [ibm.com] on "garbage collection in the HotSpot JVM", and another article that explains various garbage collection [ibm.com] techniques, and finally they have an article that covers performance [ibm.com] concerning garbage collection. They have a lot of other interesting articles, but I don't want to list all I know, if you like to check it out, here is the search [ibm.com] I used to "refind" these articles.)
I make the claim that Java isn't slow, but don't just take my worth for it. (Not that I think you would). Go search on google [google.com] or whatever. A word of warning though .. since older Java's were
indeed slow, do note the version of the Java tested. It should be (at
least) 1.4.x. I don't think 1.5.x is stable yet and I dunno if its
faster or slower, but 1.4.x have a real nice enhanced garbage
collecting subsystem. (Esp. 1.4.2 and above).
(On purpose, I didn't go for SUN benchmarks, as they might be (considered) biased, but sun does have a word to say about "Java Performance" [sun.com].)
Here is a couple of quotes from an article [idiom.com] that considers performance of Java vs. C++, analysing some benchmarks of Java, C++ and other languages. While the article was updated this year, I was still unable to find a link to a benchmark diagram of the current 1.4.x JVM. It seems though, that the 1.3.x wasn't too slow, even without latest optimised GC-subsystem, which is one of the key factors that makes 1.4.2 faster.
Here are the quotes:
Re:Why, Python, of course. (Score:1, Informative)
class bla:
def method1(self, str):
print "spike2131 is", str
b = bla()
b.method1("confused") # no self reference passed
Re:Lack of Flexibility (Why *I* don't like java) (Score:3, Informative)
Polymorphism. It has the advantage of being far more readable than your code.
Then there's the type system, which uses hideous wrapper classes around the most useful types
Autoboxing.
There's the complete lack of introspection.
Reflection.
There's the absolute need to put every helper function into a class whether it logically belongs there or not
Every function logically belongs
There's the misdesigned basic library so complex I need documentation every time I read from a pipe....
I'll concede that point. Streams are a bit of a mess. But at least the documentation is good
Static types. (Score:2, Informative)