Slashdot Mirror
Why is Java Considered Un-Cool?
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?"
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.
Java is slow when you are starting something up and the Java vm isn't started. When the vm is started, Java is outright fast. Many people fail to realize this is what's going on, but it's simply the way it works. The first time it's going to be very slow, every time after (until the vm is killed) it will be comparable to a C/C++ application in speed. When you're developing enterprise applications, that first time slowness doesn't outweigh the benefits of using Java.
This isn't to say Java is perfect for everything, but it is for some things.
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.
Java really isn't -that- slow. That's a common misconception.
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++.
never built a real world system?
Posters recognized by their sig,
I used to say the same thing whenever I ran Azureus: A Java bittorrent client. Now, I am amazed by the new release. Azureus takes up less processing time and no longer memory leaks. Like all other languages Java has the potential to be optimized.
----- You know you have ego issues when you register a domain in your name.
Maybe Java is fast but what people see is that Java gui's are typically slower than hoped.
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.
It's the startup time.
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.
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.
Tubal-Cain smokes the white owl.
Pete Becker of Dinkumware has debunked a lot of FUD spread by Java Programmers. Pete worked on the Java Library & the C++ Library for Dinkumware (& earlier for Borland) so he knows quite a bit about the subject.
Here are his usenet posts on the subject.
There are. Several big commercial Common Lisp packages (eg.), and for Scheme (a Lisp variant), a nice little free download from Rice University. I've been playing with the latter since reading Graham's latest, and it's sweet...auto-indenting, highlighting to show matching parens, source-level step-by-step debugging, unit-testing support....then there's Emacs support of lisp code editing (again with the parens matching), and the Bigloo package for well-optimized code that compiles to native or JVM (with full access to Java libraries)...google and you'll find plenty.
JRE is about 7Mb.
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.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
At least this way you don't have to maintain it, but if you add
Hope that helps!
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
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.
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ System.html#gc()
Anybody know why they decided to make it so you can't just put all .jar's in a *direcotry* referenced by CLASSPATH?
.jar files in the jre/lib/ext directory of your Java Runtime Environment. They are magically found when you use the JRE as your runtime environment. I haven't had to set a classpath environment variable in a long time.
This issue was solved a long time ago.
You put your
Ironically, the word ironically is often used incorrectly.
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 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.
Open source cross platform C++ libraries include Boost, ACE, STLSoft, and Loki to name a few.
You should give Python a try as well.
Sorry my bullshit sensor overloaded.
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
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?/ It is really easy.
http://java.sun.com/docs/books/tutorial/native1.1
You obviously haven't used some of Java's more powerfull APIs. Take a look at java.lang.reflect.* sometime. You CAN put classes into data structures (other classes with the Class class), you can call arbitrary methods on objects (Class.getMethod()).
// show the help here...
// save here...
.c file anyway, so it's not THAT big of a difference. You don't even have to instantiate the object if you declare the methods static.
;)
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.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
OK, so here's my list why Java *is* cool and is used by great programmers:
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.
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" compiler GCJ or the more mature but proprietary Excelsior JET). 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 has an article on "garbage collection in the HotSpot JVM", and another article that explains various garbage collection techniques, and finally they have an article that covers performance 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 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 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".)
Here is a couple of quotes from an article 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: