View Full Version : Java 1.4.1
I was wondering what people's thoughts and experiences were with this particular release. Specifically, it seems to have a lot of performance related improvements, I was wondering what kind of real world improvements there were in apps being run on the 1.4.1 JVM vs previous JVMs.
Here are two links to relate white papers in HTML (http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_1.html#1) and PDF (http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/JHS_141_WP_d2a.pdf) format.
Depends on the app. Swing is still slow, but that's no so much related to the raw Java VM performance as it is related to Swing's poor design/implementation. Many people's impression of Java is colored by subjective UI performance. Go to eclipse.org and download the Eclipse IDE built in IBM's SWT, or go get Jazz, a pure Java Swing GUI alternative. Both are very very fast.
The Java HotSpot server compiler is very fast, and with the new ConcurrentGC and New I/O architecture, you can now write OpenGL apps that move arround enormous amounts of data, like the Java Canyon3D demo which has about 100M of geometry data.
About 2 years ago, a friend and I both implemented a certain block cipher cryptographic algorithm in both Java (me) and C++ (him). When both were using OO features, Java turned out to be actually faster because Java can even inline data dependent polymorphic (virtual) dispatches whereas C++ can't. But when he switched to C-style coding for the algorithm (no polymorphism, pass a struct around by ref), he beat Java 1.3.1 by about 20% with MSVC.
On raw computation stuff (e.g. do a matrix multiply) , JDK 1.4.1 will do close to C++ speeds, but once you introduce the APIs into the mix, depending on which API, it could be significantly slower. Also, it depends on whether the app creates lots of objects or not.
Java programmers typically create lots of objects, and a C++ app that does no dynamic heap allocation (only stack based) will trounce Java. However, usually such a Java program can be refactored with a custom allocator that avoids creating new objects on the heap. It's just that most people won't go through the trouble.
Java's not ready for writing Doom3, but for regular non-realtime apps, it's great (if you avoid Swing, or code carefully around Swing inefficiencies), and for server-side stuff it's great. I'm not gonna say Java is "as fast" or close to C speeds. But for what I use it for, it's good enough.
Honestly, the biggest problem with Java on the desktop today isn't performance, it's memory usage. Currently, each application exists in its own Java VM. That means if you run 3 apps, you have 3 copies of all the java.* packages compiled into RAM. So there is no sharing going on between processes of the core Java platform.
Java 1.5 (Tiger) will probably address this with the Isolation API (http://www.jcp.org/en/jsr/detail?id=121) which will allow your computer to run one Java VM, where the standard Java APIs get loaded and compiled once, and then each application you launch will merely spawn a process which uses only an incremental amount of memory more (the memory used to compile your classes, but the memory use allocate on the heap)
This means no longer will you have a bunch of 64mb Java processes floating around. You'll have one master process, probably 32-64mb, and for each application you launch, you'll probably only eat marginally more heap.
Thanks, for the thoughtful reply. I hope more people dive in with their experiences.
I'm going to get to play with it in a little while. I'll also get to see what I can do with Jazz and the Eclipse IDE.
As for the multiple JVM instances. I'm kinda peeved about this. This should have been resolved much earlier IMHO. Maybe from the intro to Java 2.
Just thought I would toss my .02 in here...
I have been out of school for almost 3 years now, and have did C/C++/ASM my first year (primarily device driver related stuff), and the last 2 has been strictly in application development.
In that timeframe, I have consumed myself with a combination of Java, MFC, and .NET (specifically, C#). We have totally moved to .NET about 2 months ago...
Having said all of that, I find the Swing architecture to be among the best, IMHO. Swing performance is not what it used to be, and I loved the massive amount of flexibility. I really understood Swing in virtually all aspects. In fact, there are some things that I still find to be better performing than the equiv. in C#.
As you mentioned, the biggest problem with Java is the memory consumption if/when running multiple applications. Similarly, the nice thing about C# is the fact that the Framework does not get loaded each and everytime you run a .NET application.
I really wish .NET/C# had a highly flexible "JTable" control...that's been my single biggest complaint thus far. I got to the point where I had all of my custom Renderers/Editors ready to roll, and could implement some very nice Advanced/Custom tables in Swing...and I simply cannot do the same with .NET. Furthermore, I really do dig the whole MVC design pattern. When I moved over to Java, this really did open my eyes.
Not to totally do a segway here...But what we basically decided (about 2 months ago) was to stop development on this current project, because a decision was made to go to .NET. I was very hesitant about doing so, as we had a very good chunk of Java code developed. However, I must confess that .NET, IMHO, really rocks. The learning curve was basically nill, coming from my background. More importantly, it does have a high probability of lowering your development time.
I have been tinkering with some of the other .NET technologies as of late, such as unmanaged/managed extensions, along with getting COM components working in both C#, as well as C++ (COM from the C# assemblies). I did a fair amount of Native Interface development in Java, and I cannot tell you how much easier/quicker it is over on the C# side of the house.
im working right now on a big server in java and i agree 100% with democoder. Java is very good for writting a server. You can use non-blocking IO a lot more easy than in c/c++. Hotspot server vm is also very fast, we did a test @job. The same allgo in c (not c++) and java (find the number of occurance of a word in a buffer). The first iteration of c was ahead by far, but after some iteration c was ahead of java by few % ( less than 5). With the client vm ( optimized for swing ) c was two time faster than java. And with java you can code way faster than in c/c++.
vBulletin® v3.8.6, Copyright ©2000-2013, Jelsoft Enterprises Ltd.