Don't forget he's talking about java 1.4 and you're talking about java 1.5. One of the design features of 1.5 was to have the startup process pre-JIT'd specific to a target platform
There is no pre-JITing as far as I can tell from the documentation. The reason for the faster start-up is that system classes are cached (not compiled) in a way that allows much faster loading.
I tried the same tomcat startup on Java 1.4.2_04. Instead of 5 seconds (for 1.5.0) it took 7.
That's the thing that annoys me about a lot of Java performance talks. The folks who defend it provide a lot of theory, talk about xxx JVM being faster, XXX app being faster, roundabout arguments like that.
What theory? I am talking established fact. The newer JREs ARE faster. Let me show you some java numerical benchmarks:
Java 1.5.x is faster than Java 1.4.x which is faster than Java 1.3.x
You can provide all the hypothesis and conjecture you want.
It is not hypothesis or conjecture. There are demo applications provided with each Java JDK. Try them. Time them.
Hundreds of millions of instructions per second on a heavily multi-pipelined CPU backed up by a gigantic multi-tiered cache system and a gigabyte of RAM, and this is the best I get?
This is tedious. I heard exactly the same arguments false arguments against C++ 20 years ago. There was a myth that C++ (as against assembler) was slow, so many users and developers had convinced themselves (after experiencing a few badly written apps) that it was, and that it could never be practical.
The performance of the language has greatly improved while the perception of language has remained the roughly same (at least amoung the general coding community).
This is something that puzzles me. I would have thought that coders in general would feel the need to keep their skills and IT knowledge up to date. However, I still find attitudes which were based on an evaluation of Java 5 or more years ago predominate. In an industry where things change so dramatically over a period of a few years, I find this strange.
I am using an AMD K7 Machine, Linux, 1.8 GHz, 512 MB memory.
It does have too long a startup,
JEdit, a popular Java programmers editor. Start up time 3 seconds.
most of the UI toolkits are horribly slow,
On the same machine I am using NetBeans. There is no delay in menu use, dialogs, text editors.
it does not follow native platform UI conventions,
On MacOS/X it follows native platform UI conventions exactly, as the implementation was written by Apple. On other platforms you can use SWT which not only follows the native UI, it IS the native UI! On the upcoming version of Windows, Swing will be guaranteed to be undetectably different from the native UI by both Microsoft and Sun.
and it is just not as nice to use a Java app as it is an equally well written native app.
Nice is subjective. Both NetBeans and Eclipse have won developer.com open source awards, so I guess a reasonable number of people find them nice.
It does take far too memory, especially compared to other languages.
I can start up the Java Swing Notepad demo in... 3 megabytes of memory. I can start up the Java full GUI demo (SwingSet2) in 10 megabytes. I can run the Sun full-featured NetBeans IDE in only 64MB.
Not my definition of 'far too much memory'.
Even the cross-platform nature of the code is largely a lie.
Nonsense. I use this nature of Java on a daily basis, as do tens (if not hundreds) of thousands of other developers. If you looked at the surveys you would see that it is entirely routine for developers to use both Windows and Linux to develop Java and to deploy on the other platform.
Different JREs don't support the same things.
They absolutely do if they are the same version of the JRE. They have to pass a compatibility test.
There are massive differences between the various editions of Java so as to make it useless to try to write something across them.
Well of course not! What do you expect? Do you expect the same binary program to work with different version of Linux or libc? Java is pretty much guaranteed backward compatible, but why should anyone expect a Java 5.0 app to work on Java 1.3?
Your Java app written against "Vendor X Version Y Edition Z JRE" should work fine on any other platform with the same version of "Vendor X Version Y Edition Z JRE". That's all you can safely say without a good amount more testing.
Since Java 1.2 I have never had any cross platform issues with Java. Java is so portable that Sun's NetBeans IDE will not only run totally unchanged on any Java 1.4 or above platform, it even runs totally unchanged on Java implementations from companies other than Sun's (BEA, IBM HP).
There are guidelines for writing portable apps (such as don't use com.sun.* or sun.* packages). They are easy to follow. If you choose to ignore these, and you have issues about different vendors JREs it is your fault.
I'm afraid that your points seem to me to be nothing but myths or FUD.
The problem isn't application code typically, its the VM startup time people complain about. If java is already running its fast, but if you are starting a vm from scratch (server vm in particular) it takes a few minutes. As an example, it takes 35 seconds to start up tomcat on my freebsd server including VM startup (java 1.4.2 native) and loading all the webapps. I've timed it.
Server specs are a p4 2.4ghz with 1gb ram and freebsd 5.4 release.
I am talking about VM startup time - that is included in the 2.5 seconds. I'm sorry, but server VM startup time does not take a few minutes, at least not on machines I deal with.
Let me give you an example: AMK K7 - 1.8 GHz, 512MHz ram. Java 1.5.0_04
The issue you are dealing with is the loading of all the webapps. This has nothing whatsoever to do with the VM startup time. A typical Tomcat installation may have to deal with half a dozen applications, all with security issues, JARs to load, and database applications to establish. It is basically like starting up an operating system!
If you get bare tomcat (I use 5.0.28) I have found that I can access the management application only 5 seconds after startup.
If you are going to comment on VM startup time, you need to test an application that actually measures that.
but judging from what my computer does with Java apps here in 2005, most of that performance improvement that you're seeing is the work of Intel, not Sun.
No, it is Sun and IBM. The quality of JIT and Hotspot systems has improved phenomenally in the past few years. Performance of Java 5.0 is way ahead (many times) that of Java 1.3 or 1.2.
A *good* C++ programmer will probably write code that outperforms the equivalent in Java
This is frequently not true now, and will almost certainly not be the usual situation for much longer. Why? Because of the increasing quality of the Java Hotspot optimising system. The Java Hotspot system profiles code as at runs and tweaks code optimisation (inlining, constant rearranging, loop unrolling, array bound check removal etc.) and the machine code (instruction ordering) based on real performance, not in-advance guesses (as with C++ pre-compilation). Because this can be done on-demand and because the Hotspot system can include highly specific processor optimisations, there is a good chance that general Java code performance (which already approaches C++ in most cases) is likely to be improve significantly in coming years.
Or, if you are doing web apps, use Ruby on Rails. You'll never look back.
Unless you need to make dramatic changes to your database schema. Or have to port to a different database with different SQL and column naming conventions. They you will look back a lot.
But imagine if all your applications took a couple seconds to open. Even notepads or terminals or calculators or system monitors. It would change the way you used your computer.
That is exactly the situation on all my workstations right now, and I have never seen a system that is faster. It changes nothing, of course.
I have stated that I do not want to wait even a few seconds for an application to load. It's obnoxious to me and, I would venture, most other users. I don't understand why you are supporting the idea that latency is good.
I am not. I am just saying that below a certain point it is completely irrelevant and has no impact on the user. I have been in IT for 25 years and have never seen anyone ever complain or have any issues with a 2 or 3 second load time. When you say that this is obnoxious to most users, I have good evidence from decades of IT support that you are just plain wrong.
If this really is annoying to you, you must find the majority of applications on any workstation intolerable! I use both GNOME and KDE routinely and I can't think of a single application that starts up in less that 2 seconds.
Small, orthogonal tools. That's the UNIX philosophy, right?
Sure. I agree. But that has never ever applied to GUI systems; they have always had some lag.
Also, please note that the bulk of Microsoft Word's libraries are NOT preloaded with the operating system.
Fair enough, but you mentioned Notepad. I would be very interested to see a 2 second startup for any Office application anywhere - Microsoft or otherwise!
Your statement's only grain of truth is that IE's rendering libraries are indeed preloaded (they are used within the Explorer shell).
Wrong. The text editing controls are preloaded (hence Notepad's speed), the menu and GUI controls are loaded, the file browsing tools are preloaded. (This is the advantage of a common GUI library in Windows).
Because of Java's failings, I dislike Java -> anything. Does this make sense?
No. Because as far as I can tell, what you are labelling as failings simply would not even be noticed by the majority of users, so I don't believe it is fair or sensible to call them failings.
Yet again, I would be interested in proof that a start-up time of a GUI app of a few seconds has any ergonomic impact on anyone anywhere, other than being annoying to you.
You are imposing a requirement on GUI software that almost no major GUI application meets. If such applications, written in supposedly high performance languages like Delphi, C and C++ can't do this, why should Java be any better?
Besides, I have already identified Microsoft applications that have very short load times, so we know it's possible to create efficiently loading applications.
That simply isn't true, as Microsoft applications are basically just skins over libraries that are pre-loaded when the OS starts. In effect, the applications are already running - you are only opening windows on them.
However, Java's load-time performance cannot be excused just because you have a hard on for cross-platform binary compatibility.
There is no load-time performance problem. A start up time of a few seconds simply does not matter, as this is the case for almost any other application as well - as I have clearly demonstrated!
And in those, we see slow startup time and high memory use.
No, this is false. We start up times of a few seconds and apps that can run in what is a minor fraction of the memory of a modern machine.
I have NetBeans running in 64MB. That means I could run 4-5 copies on a modern machine. That is NOT high memory use by any standards.
I would be interested if you could give a single example of where having a start-up time of 2-3 seconds for an GUI application is likely to be of any significant disadvantage to anyone.
(I happen to think that Java is an awful language, too, but this is orthogonal to discussions of its runtime environment)
I think it would explain why you keep repeating what I believe to be completely mistaken and spurious arguments in the face of conflicting evidence.
GUI responsiveness. Click a menu button and wait literally half a second for the menu to appear. Click an OK button and the dialog hangs around with it pressed for a couple of seconds. And even while this slow it's still taking all the CPU, if I try and run (for example) an mp3 player at the same time the song starts skipping. Startup times are also pathetic (20s for a text editor) but that's excusable
Sorry, but I simply don't find this! As a test, I have tried running NetBeans in a small (these days!) amount of memory (64MB). It runs fine and the GUI response is instant - no menu delays, no dialog delays. I have tried a basic text edit - the notepad demo provided with Java, and that starts up in 2 seconds. To make sure I had the same situation as you, I have installed JEdit. Starts up in 3 seconds.
This is a 2GHz machine, 512MB memory, Java 1.5.0_04.
"There are no performance problems at all with the Java 5.0 VM either in terms of general use or the GUI."
People always say this, but my experience is that it's simply not true. I'm not saying you aren't having performance problems; I am simply suggesting that they aren't typical, and can't be used to generally criticise Java.
I used to be severely critical of Java (and Swing in particular) for being far too slow to use and simply not practical. However, these days, I just don't find that anymore.
Even 2.5 seconds is an unreasonable amount of time for a simple application such as the notepad example, especially on a modern machine like yours.
It is not unreasonable, and saying this is just plain silly. Applications like FireFox and Thunderbird are C++ start up in tens of seconds. Where is the huge outcry?
There really is no excuse for Java's kind of bloat in a desktop application;
What bloat? I keep posting the fact that Java can run in small memory environments, but this keeps being ignored.
a language with just as much abstraction, expressive power, and (source) portability as Java could be natively compiled without much trouble (see academic languages, such as Lisp, ML, etc. for examples).
There are extremely good reasons why Java is not natively compiled. It is portable between systems not just at start-up time, but dynamically - for example, updates to code can be distributed between clustered mixed systems while applications are running. Not being compiled also hugely improved security, as classes and what they do can be dynamically validated when the program load them and while a program is running.
However, load times are critical when you are running a multitasking GUI.
Utter nonsense. The idea that someone sitting at a desktop seriously can't wait two seconds for an application to start is such outrageous exaggeration that I am starting to think that this is nothing more than an anti-java rant! I try to argue back calmly, but honestly!
Even though it is-preloaded when Windows starts, MS office can take many seconds to open a document from disk. Do we see a mass migration away from MS office based because it does not meet your 'critical load time' criteria?
I am currently using GNOME. On my 2GHz machine opening the file manager took 7 seconds. Opening the character map took 1.5 seconds. Opening Evolution took 5 seconds.
By your criteria we should abandon C++ and GNOME because they take too long to load!
I'm curious if there are *any* certified-Java(tm) implementations that don't rely on Sun code for java.* and javax.*. Let me be more specific: certified-Java(tm) J2SE runtime environments at 1.2+ level.
Good point. BEA and IBM both have fully-clean room JVM implementations, but I don't know about all of java.* and javax.*.
I know that at least some of the IBM code is different as they implement at least some of these using their own code and not Sun's (there are com.ibm packages not com.sun.. etc.)
So, Sun ARE certifying competing implementations, at least to some extent.
Java 5.0 usually came within 5-10% of optimised C++. Within 5-10% is still slower....
That was for just this benchmark. In some others the IBM JVM is faster than C++.
I'm afraid that I can't take a complaint about a 5-10% speed difference seriously, as the difference in performance between different C++ compilers is more than that!
Just the concept that ANYONE would think that it is reasonable for a "hello world" program to need a few megabytes is disgusting. What ever happened to efficient code.
Of course it doesn't need a few megabytes! It is the runtime that needs a few megabytes. Even the simplest C program will dynamically connect to the libc and other stuff. Even the simplest PERL or Python program will require the interpreter.
Funny how people are prepared to neglect this for those languages, but not for Java.
In fact Java can be pretty efficient in memory as it selectively loads only the required classes into memory and not the entire library file. This is why Java can run in low-memory environments such as embedded device controllers and mobile phones.
Benchmarks are NOT real world. In the real world, the time it takes for an app to become useable means something, and in a few cases it means a lot more than the raw speed of the app after launching.
OK, so let's time it. An non-GUI java app can start up in a fraction of a second. A Swing app can start up in a few seconds.
I have just opened the Java 5.0 jsf example Notepad. On my 2GHz machine (512MB memory) it started in 2.5 seconds.
So let's try another app - something more complicated: SwingSet2, the full Swing GUI demo. It starts up in 7 seconds.
Sorry, but I can't see a problem.
It's a sad state of affairs when it's faster to load up a saved virtual machine running a java app, than to load the actual app itself on the host.
As I have just demonstrated, there are no speed issues with loading apps. Why don't you try the tests yourself and report back the results.
By the way, the full SwingSet demo ran in 10MB (-Xmx10m) of memory, and the Notepad example ran in 3MB.
No sign of slowing down the machine or causing swapping there!
I have, last one I tried was iirc 1.5.04. It still sucks to the point of being unusable on an 800mhz system. I'm using linux, maybe the windows JVM performs better.
I'm puzzled. What exactly sucks? I know people who use, for example, the NetBeans IDE on Linux and Windows on machines of that spec. There are no performance problems at all with the Java 5.0 VM either in terms of general use or the GUI.
Just one professional programmer's opinion here: The so.cal job market right now has loaded with.Net work. I've never in my time seen that kind of buzz for Java programming positions, when it comes to PC/Server applicaitons. Not even during the.com boom days.
Then you need to look around. There are major new exciting things happening with Java - real-time devices, robotics, embedded device control is one aspect that interests me. Java is the single most in-demand language in IT jobs at the moment.
I don't expect things to get any better for a Java programmer.
I don't understand what you mean. There is a thriving open source community around Java, and the demand for Java is huge and growing.
I just can't imagine.Net fading away in 5-8 years as you predict, especially with Vista being loaded with C# apps.
I'm afraid that similar statements were made about Visual Basic - now VB.Net (with incompatibilities) has made it redundant.
Cut the crap. My computer has 512MB DDR RAM, and each time I use a Java application it starts swapping LOADS. The computer is nearly UNUSABLE due to all swap usage.
Strangely, mobile devices can run java in just a few 100k. The Java 5.0 VM itself can run in just a few MB.
Write a simple Java 'hello world' program, and you will find it can run in just a few megabytes (use the -Xmx switch to set the max usage).
So the claim that your machine will swap 'each time you use a Java application' is provably nonsense.
I'll start Eclipse, to tell you how much RAM the JVM will use (it might be a shock for you!).
It's an IDE for goodness sake! They are some of the largest apps.
Mind you, the NetBeans IDE can run quite happily in moderate memory. In fact, if you look at the IDE config file for NetBeans 4.1 you will see that the IDE is by default not allowed to use more than about 90-100MB.
In fact, I have just started it giving it a maximum memory of 64MB.
Try it yourself! I am using Java 1.5.0_04 and NetBeans 4.1. The configuration file within the netbeans install directory is etc/netbeans.conf.
So, on a 512MB machine, it isn't causing swapping. (It never does on my PCs, which have this memory).
Saying Java is performing nearly as fast or even faster than C++ is BULLSHIT.
If it is, then it is bullshit backed by considerable evidence. Last year there was a study of java speed for numerical work, using the well-known Linpack benchmark:
Java 5.0 usually came within 5-10% of optimised C++.
So, I am sorry, but you are plainly factually wrong.
If you don't believe me, again, try it yourself. The source code for these benchmarks is available.
You may also be interested to know that Java is now so fast it can be used for real-time device control and AI systems. Boeing use Java for robotic and autonomous experimental planes, and one of the entrants for this years robotic road race has its software entirely in Java.
One thing I really miss with C++ and Java is properties. What's with a language that will put all the work into a ternary operator so they don't have to type if/then/else, but insists on mutators and accessors because properties are syntactic sugar?
The reason for the ternary operator is simple - to allow C code to be easily ported.
As for properties, this is a good point but in practice does not matter - all good Java IDEs have property management built in: The will allow the automated generation and management of get/set methods and the values they change. For example, on NetBeans you simply select the 'properties entry' for the class, and off you go..
With.NET you get a much higher level of performance, and most of the benefits that Java.
No, you don't get a much higher level of performance. Both.NET and Java are now fast. Java is fast enough that it is often used for numerical and graphical work.
Java on the other hand would have a hell of a time trying to get enough performance out of the VM to do very advanced graphics for example, and with.NET it is a no sweat do able thing.
This is simply a statement without foundation.
Have you actually looked at Java vs.NET benchmarks? It might be an idea before you post such things.
So why bother? Speed my friend, speed. Also reliability isn't on the side of JAVA at the moment either. You still have to test your apps on all platforms, so being fully transparent to each VM on all OSes, JAVA still has a ways to go.
Complete nonsense! There may be issues in some aspects of mobile devices, but on main platforms (Linux, Windows, Solaris, HP/UX etc) Java is robust and totally portable. No-one I know ever bothers to test for cross-platform portability. If you use a certified JVM on each platform, there are simply no problems.
Yeah, and if you read forums on the Internet, you'll see that everybody is always complaining that those apps are slow (slow in the sense of they-hog-so-much-memory-that-my-computer-dies-from -swapping, not CPU usage).
Perhaps 5 or 6 years ago. Now I usually only see such complaints on Slashdot where there seems to be a puzzling reluctance to accept that technologies can change in half a decade!
C# also follows along the same lines of Java, making it quite similar except you have the option of getting out of the sandbox that Java uses. Some people need to get out of the sandbox for various purposes, and C# allows that, not Java.
Only specialised Java code (such as applets) runs in a sandbox. Other code can do anything you like. You can interface with C code using JNI.
Slashdot Mirror
Don't forget he's talking about java 1.4 and you're talking about java 1.5. One of the design features of 1.5 was to have the startup process pre-JIT'd specific to a target platform
There is no pre-JITing as far as I can tell from the documentation. The reason for the faster start-up is that system classes are cached (not compiled) in a way that allows much faster loading.
I tried the same tomcat startup on Java 1.4.2_04. Instead of 5 seconds (for 1.5.0) it took 7.
That's the thing that annoys me about a lot of Java performance talks. The folks who defend it provide a lot of theory, talk about xxx JVM being faster, XXX app being faster, roundabout arguments like that.
What theory? I am talking established fact. The newer JREs ARE faster. Let me show you some java numerical benchmarks:
http://www.shudo.net/jit/perf/
Java 1.5.x is faster than Java 1.4.x which is faster than Java 1.3.x
You can provide all the hypothesis and conjecture you want.
It is not hypothesis or conjecture. There are demo applications provided with each Java JDK. Try them. Time them.
Hundreds of millions of instructions per second on a heavily multi-pipelined CPU backed up by a gigantic multi-tiered cache system and a gigabyte of RAM, and this is the best I get?
This is tedious. I heard exactly the same arguments false arguments against C++ 20 years ago. There was a myth that C++ (as against assembler) was slow, so many users and developers had convinced themselves (after experiencing a few badly written apps) that it was, and that it could never be practical.
The performance of the language has greatly improved while the perception of language has remained the roughly same (at least amoung the general coding community).
This is something that puzzles me. I would have thought that coders in general would feel the need to keep their skills and IT knowledge up to date. However, I still find attitudes which were based on an evaluation of Java 5 or more years ago predominate. In an industry where things change so dramatically over a period of a few years, I find this strange.
Let's take these myths one by one.
... 3 megabytes of memory.
I am using an AMD K7 Machine, Linux, 1.8 GHz, 512 MB memory.
It does have too long a startup,
JEdit, a popular Java programmers editor. Start up time 3 seconds.
most of the UI toolkits are horribly slow,
On the same machine I am using NetBeans. There is no delay in menu use, dialogs, text editors.
it does not follow native platform UI conventions,
On MacOS/X it follows native platform UI conventions exactly, as the implementation was written by Apple. On other platforms you can use SWT which not only follows the native UI, it IS the native UI! On the upcoming version of Windows, Swing will be guaranteed to be undetectably different from the native UI by both Microsoft and Sun.
and it is just not as nice to use a Java app as it is an equally well written native app.
Nice is subjective. Both NetBeans and Eclipse have won developer.com open source awards, so I guess a reasonable number of people find them nice.
It does take far too memory, especially compared to other languages.
I can start up the Java Swing Notepad demo in
I can start up the Java full GUI demo (SwingSet2) in 10 megabytes.
I can run the Sun full-featured NetBeans IDE in only 64MB.
Not my definition of 'far too much memory'.
Even the cross-platform nature of the code is largely a lie.
Nonsense. I use this nature of Java on a daily basis, as do tens (if not hundreds) of thousands of other developers. If you looked at the surveys you would see that it is entirely routine for developers to use both Windows and Linux to develop Java and to deploy on the other platform.
Different JREs don't support the same things.
They absolutely do if they are the same version of the JRE. They have to pass a compatibility test.
There are massive differences between the various editions of Java so as to make it useless to try to write something across them.
Well of course not! What do you expect? Do you expect the same binary program to work with different version of Linux or libc? Java is pretty much guaranteed backward compatible, but why should anyone expect a Java 5.0 app to work on Java 1.3?
Your Java app written against "Vendor X Version Y Edition Z JRE" should work fine on any other platform with the same version of "Vendor X Version Y Edition Z JRE". That's all you can safely say without a good amount more testing.
Since Java 1.2 I have never had any cross platform issues with Java. Java is so portable that Sun's NetBeans IDE will not only run totally unchanged on any Java 1.4 or above platform, it even runs totally unchanged on Java implementations from companies other than Sun's (BEA, IBM HP).
There are guidelines for writing portable apps (such as don't use com.sun.* or sun.* packages). They are easy to follow. If you choose to ignore these, and you have issues about different vendors JREs it is your fault.
I'm afraid that your points seem to me to be nothing but myths or FUD.
The problem isn't application code typically, its the VM startup time people complain about. If java is already running its fast, but if you are starting a vm from scratch (server vm in particular) it takes a few minutes. As an example, it takes 35 seconds to start up tomcat on my freebsd server including VM startup (java 1.4.2 native) and loading all the webapps. I've timed it.
Server specs are a p4 2.4ghz with 1gb ram and freebsd 5.4 release.
I am talking about VM startup time - that is included in the 2.5 seconds. I'm sorry, but server VM startup time does not take a few minutes, at least not on machines I deal with.
Let me give you an example: AMK K7 - 1.8 GHz, 512MHz ram. Java 1.5.0_04
The issue you are dealing with is the loading of all the webapps. This has nothing whatsoever to do with the VM startup time. A typical Tomcat installation may have to deal with half a dozen applications, all with security issues, JARs to load, and database applications to establish. It is basically like starting up an operating system!
If you get bare tomcat (I use 5.0.28) I have found that I can access the management application only 5 seconds after startup.
If you are going to comment on VM startup time, you need to test an application that actually measures that.
And SciTE starts in roughly 0.5s... (the "true" notepad startup time being more or less null, making it just about infinitely faster than java)
I would be interested in an explanation of how a 2.5 second startup time has any relevance whatsoever to the general user.
but judging from what my computer does with Java apps here in 2005, most of that performance improvement that you're seeing is the work of Intel, not Sun.
No, it is Sun and IBM. The quality of JIT and Hotspot systems has improved phenomenally in the past few years. Performance of Java 5.0 is way ahead (many times) that of Java 1.3 or 1.2.
A *good* C++ programmer will probably write code that outperforms the equivalent in Java
This is frequently not true now, and will almost certainly not be the usual situation for much longer. Why? Because of the increasing quality of the Java Hotspot optimising system. The Java Hotspot system profiles code as at runs and tweaks code optimisation (inlining, constant rearranging, loop unrolling, array bound check removal etc.) and the machine code (instruction ordering) based on real performance, not in-advance guesses (as with C++ pre-compilation). Because this can be done on-demand and because the Hotspot system can include highly specific processor optimisations, there is a good chance that general Java code performance (which already approaches C++ in most cases) is likely to be improve significantly in coming years.
Or, if you are doing web apps, use Ruby on Rails. You'll never look back.
Unless you need to make dramatic changes to your database schema. Or have to port to a different database with different SQL and column naming conventions. They you will look back a lot.
The java vm startup time is a problem for client apps, but server side its not a big deal.
This is yet another urban myth about Java. I have a 1.8GHz machine. Java 1.5.0_04.
JEdit starts up in 3 seconds.
The jsf demo Notepad.jar starts up in 2.5 seconds.
SwingSet2 - the full Java GUI demo starts up in 7 seconds.
So where is the problem?
But imagine if all your applications took a couple seconds to open. Even notepads or terminals or calculators or system monitors. It would change the way you used your computer.
That is exactly the situation on all my workstations right now, and I have never seen a system that is faster. It changes nothing, of course.
I have stated that I do not want to wait even a few seconds for an application to load. It's obnoxious to me and, I would venture, most other users. I don't understand why you are supporting the idea that latency is good.
I am not. I am just saying that below a certain point it is completely irrelevant and has no impact on the user. I have been in IT for 25 years and have never seen anyone ever complain or have any issues with a 2 or 3 second load time. When you say that this is obnoxious to most users, I have good evidence from decades of IT support that you are just plain wrong.
If this really is annoying to you, you must find the majority of applications on any workstation intolerable! I use both GNOME and KDE routinely and I can't think of a single application that starts up in less that 2 seconds.
Small, orthogonal tools. That's the UNIX philosophy, right?
Sure. I agree. But that has never ever applied to GUI systems; they have always had some lag.
Also, please note that the bulk of Microsoft Word's libraries are NOT preloaded with the operating system.
Fair enough, but you mentioned Notepad. I would be very interested to see a 2 second startup for any Office application anywhere - Microsoft or otherwise!
Your statement's only grain of truth is that IE's rendering libraries are indeed preloaded (they are used within the Explorer shell).
Wrong. The text editing controls are preloaded (hence Notepad's speed), the menu and GUI controls are loaded, the file browsing tools are preloaded. (This is the advantage of a common GUI library in Windows).
Because of Java's failings, I dislike Java -> anything. Does this make sense?
No. Because as far as I can tell, what you are labelling as failings simply would not even be noticed by the majority of users, so I don't believe it is fair or sensible to call them failings.
Yet again, I would be interested in proof that a start-up time of a GUI app of a few seconds has any ergonomic impact on anyone anywhere, other than being annoying to you.
You are imposing a requirement on GUI software that almost no major GUI application meets. If such applications, written in supposedly high performance languages like Delphi, C and C++ can't do this, why should Java be any better?
Besides, I have already identified Microsoft applications that have very short load times, so we know it's possible to create efficiently loading applications.
That simply isn't true, as Microsoft applications are basically just skins over libraries that are pre-loaded when the OS starts. In effect, the applications are already running - you are only opening windows on them.
However, Java's load-time performance cannot be excused just because you have a hard on for cross-platform binary compatibility.
There is no load-time performance problem. A start up time of a few seconds simply does not matter, as this is the case for almost any other application as well - as I have clearly demonstrated!
And in those, we see slow startup time and high memory use.
No, this is false. We start up times of a few seconds and apps that can run in what is a minor fraction of the memory of a modern machine.
I have NetBeans running in 64MB. That means I could run 4-5 copies on a modern machine. That is NOT high memory use by any standards.
I would be interested if you could give a single example of where having a start-up time of 2-3 seconds for an GUI application is likely to be of any significant disadvantage to anyone.
(I happen to think that Java is an awful language, too, but this is orthogonal to discussions of its runtime environment)
I think it would explain why you keep repeating what I believe to be completely mistaken and spurious arguments in the face of conflicting evidence.
GUI responsiveness. Click a menu button and wait literally half a second for the menu to appear. Click an OK button and the dialog hangs around with it pressed for a couple of seconds. And even while this slow it's still taking all the CPU, if I try and run (for example) an mp3 player at the same time the song starts skipping. Startup times are also pathetic (20s for a text editor) but that's excusable
Sorry, but I simply don't find this! As a test, I have tried running NetBeans in a small (these days!) amount of memory (64MB). It runs fine and the GUI response is instant - no menu delays, no dialog delays. I have tried a basic text edit - the notepad demo provided with Java, and that starts up in 2 seconds. To make sure I had the same situation as you, I have installed JEdit. Starts up in 3 seconds.
This is a 2GHz machine, 512MB memory, Java 1.5.0_04.
"There are no performance problems at all with the Java 5.0 VM either in terms of general use or the GUI."
People always say this, but my experience is that it's simply not true.
I'm not saying you aren't having performance problems; I am simply suggesting that they aren't typical, and can't be used to generally criticise Java.
I used to be severely critical of Java (and Swing in particular) for being far too slow to use and simply not practical. However, these days, I just don't find that anymore.
Even 2.5 seconds is an unreasonable amount of time for a simple application such as the notepad example, especially on a modern machine like yours.
It is not unreasonable, and saying this is just plain silly. Applications like FireFox and Thunderbird are C++ start up in tens of seconds. Where is the huge outcry?
There really is no excuse for Java's kind of bloat in a desktop application;
What bloat? I keep posting the fact that Java can run in small memory environments, but this keeps being ignored.
a language with just as much abstraction, expressive power, and (source) portability as Java could be natively compiled without much trouble (see academic languages, such as Lisp, ML, etc. for examples).
There are extremely good reasons why Java is not natively compiled. It is portable between systems not just at start-up time, but dynamically - for example, updates to code can be distributed between clustered mixed systems while applications are running. Not being compiled also hugely improved security, as classes and what they do can be dynamically validated when the program load them and while a program is running.
However, load times are critical when you are running a multitasking GUI.
Utter nonsense. The idea that someone sitting at a desktop seriously can't wait two seconds for an application to start is such outrageous exaggeration that I am starting to think that this is nothing more than an anti-java rant! I try to argue back calmly, but honestly!
Even though it is-preloaded when Windows starts, MS office can take many seconds to open a document from disk. Do we see a mass migration away from MS office based because it does not meet your 'critical load time' criteria?
I am currently using GNOME. On my 2GHz machine opening the file manager took 7 seconds. Opening the character map took 1.5 seconds. Opening Evolution took 5 seconds.
By your criteria we should abandon C++ and GNOME because they take too long to load!
I'm curious if there are *any* certified-Java(tm) implementations that don't rely on Sun code for java.* and javax.*. Let me be more specific: certified-Java(tm) J2SE runtime environments at 1.2+ level.
.. etc.)
Good point. BEA and IBM both have fully-clean room JVM implementations, but I don't know about all of java.* and javax.*.
I know that at least some of the IBM code is different as they implement at least some of these using their own code and not Sun's (there are com.ibm packages not com.sun
So, Sun ARE certifying competing implementations, at least to some extent.
Java 5.0 usually came within 5-10% of optimised C++. Within 5-10% is still slower....
That was for just this benchmark. In some others the IBM JVM is faster than C++.
I'm afraid that I can't take a complaint about a 5-10% speed difference seriously, as the difference in performance between different C++ compilers is more than that!
Just the concept that ANYONE would think that it is reasonable for a "hello world" program to need a few megabytes is disgusting. What ever happened to efficient code.
Of course it doesn't need a few megabytes! It is the runtime that needs a few megabytes. Even the simplest C program will dynamically connect to the libc and other stuff. Even the simplest PERL or Python program will require the interpreter.
Funny how people are prepared to neglect this for those languages, but not for Java.
In fact Java can be pretty efficient in memory as it selectively loads only the required classes into memory and not the entire library file. This is why Java can run in low-memory environments such as embedded device controllers and mobile phones.
Benchmarks are NOT real world. In the real world, the time it takes for an app to become useable means something, and in a few cases it means a lot more than the raw speed of the app after launching.
OK, so let's time it. An non-GUI java app can start up in a fraction of a second. A Swing app can start up in a few seconds.
I have just opened the Java 5.0 jsf example Notepad. On my 2GHz machine (512MB memory) it started in 2.5 seconds.
So let's try another app - something more complicated: SwingSet2, the full Swing GUI demo. It starts up in 7 seconds.
Sorry, but I can't see a problem.
It's a sad state of affairs when it's faster to load up a saved virtual machine running a java app, than to load the actual app itself on the host.
As I have just demonstrated, there are no speed issues with loading apps. Why don't you try the tests yourself and report back the results.
By the way, the full SwingSet demo ran in 10MB (-Xmx10m) of memory, and the Notepad example ran in 3MB.
No sign of slowing down the machine or causing swapping there!
I have, last one I tried was iirc 1.5.04. It still sucks to the point of being unusable on an 800mhz system. I'm using linux, maybe the windows JVM performs better.
I'm puzzled. What exactly sucks? I know people who use, for example, the NetBeans IDE on Linux and Windows on machines of that spec. There are no performance problems at all with the Java 5.0 VM either in terms of general use or the GUI.
Just one professional programmer's opinion here: The so.cal job market right now has loaded with .Net work. I've never in my time seen that kind of buzz for Java programming positions, when it comes to PC/Server applicaitons. Not even during the .com boom days.
.Net fading away in 5-8 years as you predict, especially with Vista being loaded with C# apps.
Then you need to look around. There are major new exciting things happening with Java - real-time devices, robotics, embedded device control is one aspect that interests me. Java is the single most in-demand language in IT jobs at the moment.
I don't expect things to get any better for a Java programmer.
I don't understand what you mean. There is a thriving open source community around Java, and the demand for Java is huge and growing.
I just can't imagine
I'm afraid that similar statements were made about Visual Basic - now VB.Net (with incompatibilities) has made it redundant.
Cut the crap. My computer has 512MB DDR RAM, and each time I use a Java application it starts swapping LOADS. The computer is nearly UNUSABLE due to all swap usage.
Strangely, mobile devices can run java in just a few 100k. The Java 5.0 VM itself can run in just a few MB.
Write a simple Java 'hello world' program, and you will find it can run in just a few megabytes (use the -Xmx switch to set the max usage).
So the claim that your machine will swap 'each time you use a Java application' is provably nonsense.
I'll start Eclipse, to tell you how much RAM the JVM will use (it might be a shock for you!).
It's an IDE for goodness sake! They are some of the largest apps.
Mind you, the NetBeans IDE can run quite happily in moderate memory. In fact, if you look at the IDE config file for NetBeans 4.1 you will see that the IDE is by default not allowed to use more than about 90-100MB.
In fact, I have just started it giving it a maximum memory of 64MB.
Try it yourself! I am using Java 1.5.0_04 and NetBeans 4.1. The configuration file within the netbeans install directory is etc/netbeans.conf.
So, on a 512MB machine, it isn't causing swapping. (It never does on my PCs, which have this memory).
Saying Java is performing nearly as fast or even faster than C++ is BULLSHIT.
If it is, then it is bullshit backed by considerable evidence. Last year there was a study of java speed for numerical work, using the well-known Linpack benchmark:
http://www.shudo.net/jit/perf/
Java 5.0 usually came within 5-10% of optimised C++.
So, I am sorry, but you are plainly factually wrong.
If you don't believe me, again, try it yourself. The source code for these benchmarks is available.
You may also be interested to know that Java is now so fast it can be used for real-time device control and AI systems. Boeing use Java for robotic and autonomous experimental planes, and one of the entrants for this years robotic road race has its software entirely in Java.
One thing I really miss with C++ and Java is properties. What's with a language that will put all the work into a ternary operator so they don't have to type if/then/else, but insists on mutators and accessors because properties are syntactic sugar?
The reason for the ternary operator is simple - to allow C code to be easily ported.
As for properties, this is a good point but in practice does not matter - all good Java IDEs have property management built in: The will allow the automated generation and management of get/set methods and the values they change. For example, on NetBeans you simply select the 'properties entry' for the class, and off you go..
But Java on the desktop really sucks just because swing is so pathetically slow.
Try a modern JVM - late 1.4.x or, even better, 5.0. The Swing performance has improved dramatically.
With .NET you get a much higher level of performance, and most of the benefits that Java.
.NET and Java are now fast. Java is fast enough that it is often used for numerical and graphical work.
.NET it is a no sweat do able thing.
.NET benchmarks? It might be an idea before you post such things.
No, you don't get a much higher level of performance. Both
Java on the other hand would have a hell of a time trying to get enough performance out of the VM to do very advanced graphics for example, and with
This is simply a statement without foundation.
Have you actually looked at Java vs
So why bother? Speed my friend, speed. Also reliability isn't on the side of JAVA at the moment either. You still have to test your apps on all platforms, so being fully transparent to each VM on all OSes, JAVA still has a ways to go.
Complete nonsense! There may be issues in some aspects of mobile devices, but on main platforms (Linux, Windows, Solaris, HP/UX etc) Java is robust and totally portable. No-one I know ever bothers to test for cross-platform portability. If you use a certified JVM on each platform, there are simply no problems.
Yeah, and if you read forums on the Internet, you'll see that everybody is always complaining that those apps are slow (slow in the sense of they-hog-so-much-memory-that-my-computer-dies-from -swapping, not CPU usage).
Perhaps 5 or 6 years ago. Now I usually only see such complaints on Slashdot where there seems to be a puzzling reluctance to accept that technologies can change in half a decade!
C# also follows along the same lines of Java, making it quite similar except you have the option of getting out of the sandbox that Java uses. Some people need to get out of the sandbox for various purposes, and C# allows that, not Java.
Only specialised Java code (such as applets) runs in a sandbox. Other code can do anything you like. You can interface with C code using JNI.
Ever try creating a reusable web control in java? VERY_PAINFUL.
Heard of JavaServer Faces?