Slashdot carries a story about Sun trying to speed up the UI of Java applications by using native OS looks. Sun released J2SE version 1.4.2 beta1, release notes here. Footnotes ran an interview about the integration of Java and GTK+ and they feature three screenshots. In other developer/GTK+ news, Inti 1.0.7 is released. Inti is a C++ wrapper for GTK+ (similar to gtkmm).
Sun to Amp Java for Desktop Performance? J2SE 1.4.2b Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
SWT anyone?
They aren’t using GTK, they are just making a Swing theme that looks like GTK. Bah, still gonna be slow.
hmmm, this on the same day as Mozilla declares that XPFE is a bloated failure?
The swing application contiue to be as ugly as they are :
no anti-aliased font, poor emulating look and feel,… very slow. Swt is so much better…why sun doesn’t ambrace a similar approch ?
What..where can I read more about that?
Sounds very familiar to their original approach…AWT. Someone needs to make up their mind.
-G
That should read very “similar”…
-G
Every time I hear someone saying Swing is slow I think about jEdit. I use it every day and it is not slow at all (it uses a lot of memory though). IMHO, Swing slowness in these days is related to poorly written code. If you are clever, and don´t create too many objects, your Swing apps will be ok. 😀
jEdit. I use it every day and it is not slow at all (it uses a lot of memory though).
It helps if you only load the plugins you absolutely need.
Swing slowness in these days is related to poorly written code
Exactly, there are plenty of fast swing apps too, but people just seem to ignore them.
That Bluecurve look&feel is just what I’ve been waiting for ! Nice.
J2SE 1.4.2’s support for Windows XP Themes rocks! Ammai.com has a tour of the new look and feel in 1.4.2. Go here to see some screenshots of the Windows XP theme in action:
http://www.ammai.com/modules.php?op=modload&name=News&file=article&…
Every time I hear someone saying Swing is slow I think about jEdit. I use it every day and it is not slow
Assuming you have access to a Win32 machine, install jEdit and UltraEdit on the same machine, compare their startup times, and get back to us with the results.
Java sucks.
Assuming you have access to a Win32 machine, install jEdit and UltraEdit on the same machine, compare their startup times, and get back to us with the results.
Yes, you can’t compete with the speed and integration of native widgets. Many input method editors, designed to work with native text input boxes, will not work with Swing because the input box isn’t recognized. Who do you pin the blame on, the author of the input method editor, or Java?
I’ll agree SWT is a better approach, but when are we going to see Swing abandoned for SWT? It doesn’t appear to be any time in the near future.
Java sucks.
I’ll also continue to stick with native applications, thanks.
Should not of uninstalled before downloading…
Dam d/l site is dead
I in two minds about SWT, I like its more AWTish approch, but not the APIs , while Swings are much nicer.
There are limitations placed on these because of ONE operating system. For example, AWT applications don’t have right click, why? because Mac doesn’t have two mouse buttons. There are a string of limitations placed on AWT and SWT because of stupid UI design decisions made by Apple.
IMHO it is about time SUN just simply said, “stuff it” and worked on SWT so that both GTK+ and Win32 users can have a unhindered experience and if Apple has a problem, there is only one way to sort it out, get over and fix up your GUI toolkit.
http://www.theregister.co.uk/content/6/30077.html
[i]
Team leaders have advised Mozilla developers to abandon the “swiss army knife” approach for smaller and lighter applications, according to a statement posted on the mozilla.org site today.
In the statement, team leaders Brenden Eich and David Hyatt take the criticism on the chin, and the team has also vowed to tighten up its development methodology.
The losers are the cross-platform toolkit (XPFE) and the user interface language (XUL), which created a rich scriptable environment that can justifiably be described as a “platform”. The Mozilla suite will favor standalone mail and composer applications in preference to the monolithic package developed now.
“As intended, [XUL] allowed us to write a cross-platform application front end once, instead of writing native-OS-toolkit-based front ends for at least three platforms. But we ended up spending at least as many people and as much time on the various applications in the suite, and on integrating those application components, as we would have spent developing native browser-only front ends and one browser back end. “
Assuming you have access to a Win32 machine, install jEdit and UltraEdit on the same machine, compare their startup times, and get back to us with the results.
This beta is supposed to speed up startup times.
Anyway, once jEdit is loaded, what’s the experience like?
It does have a background option to stay in ram for quick response times
Assuming you have access to a Win32 machine, install jEdit and UltraEdit on the same machine, compare their startup times, and get back to us with the results.
Java sucks.
Ok. So I tried it. UltraEdit opened the millisecond I clicked the icon on my quick launch bar and was ready and impatiently waiting on me to move my mouse across 80% of the screen to the file menu to open a file. jEdit, on the other hand, took about a second to start up… but I have to admit that its file menu was there and waiting by the time I moved my mouse up from the quick launch bar to load that same text file.
Now try the same comparison on OSX? FreeBSD? Solaris? RedHat? Yeah… jEdit opens on all those systems a helluva lot faster than the UltraEdit developers can port their application.
Native apps suck.
(I’m just highlighting the stupidity of the previous argument rather than really advocating that native apps actually suck. I’d like to see people work a little harder here in presenting a valid point rather than spewing their agenda in snide, pithy little blurbs.)
Now try the same comparison on OSX? FreeBSD? Solaris? RedHat?
vim is available for all these platforms, as well as Windows. UltraEdit was just a token example.
Native apps suck.
If portability means more to you than performance perhaps…
If portability means more to you than performance perhaps…
The slowest element in any program is user interaction. If you can remove users, your program can get a lot of work done fast. Countless CPU cycles are wasted on users hemming and hawing about what input to supply next (which manu option do I want?, etc.). Even typing at 80 words a minute still leaves thousands of wasted cycles between characters.
Performance is not important to every application. And, as computers get faster, the magnitude of the performance issue diminishes quickly. As long as the program is responsive (or appears responsive) to comparitively slow human interaction, performance can (and arguably should) take a second seat to other factors (good design, portability, etc).
jEdit, on the other hand, took about a second to start up…
I assume that when you did this, there were no parts of the program already loaded in memory, and all of the functionality of jEdit was available at startup?
There is a problem with native applications, if it were just *NIX and MacOS then the portability would be easy, however, Windows is incompatible between itself and the rest of the known universe. If the win32 api was standardised like the UNIX 98 and POSIX specifications then life would be made easier and one would simply implement the win32 api on that particular OS, however, that isn’t the case and as a net result we end up jumping to non-native applications.
Non-native applications don’t have to be slow. If all that needs to be re-written is the front end then atleast it won’t be as bad as requiring a total re-write. If you look at Mono, sure, it won’t be 100% “there” but will make portability alot easier with a lower overhead.
The slowest element in any program is user interaction.
Oh boy, here we go ….
I would personally be willing to bet that if Java apps were faster than native apps, you along with all the other Java zealots would be in here ‘swiging’ your dicks going on and on about how fast Java is. But since it isn’t, you have to make up all of these lame-ass excuses of why performance isn’t that important. Hell, Mac zealots do the same thing – instead lf just admitting that it’s slow …
It’s just like the ‘megahertz myth.’ It’s really not that important, assuming the chip you use is slower than the other. *cough* AMD *cough* But assuming your chip is on top of the mhz chain, you will be on the rooftops proclaiming it boldy. And what is the deal anyway? I assume that by answering my UltraEdit/jEdit post, you were trying to prove that Java’s performance is as good as native apps? And if so, what’s with the speech about why performance doesn’t matter?
What am I trying to say here? PERFORMANCE DOES MATTER – I don’t give a damn what platform you’re on. And even though it’s just a hunch, I’d be willing to bet that the only people who give two shits about Java are the ones that give two shits about portability. The others of us will tell you to get your crappy VM off the desktop and off of web pages (how many more crappy web applets can the web endore anyway?), and keep that pile of shit on servers and embedded devices where it belongs. End users want no part of it. They may not be able to tell that it’s Java, but they’ll definitely be able to tell that ‘something is wrong’ as soon as they start it up.
Let Java die.
Assuming you have access to a Win32 machine, install jEdit and UltraEdit on the same machine, compare their startup times, and get back to us with the results.
Now compare their features and get back to me. UltraEdit is a good editor, but is not as feature-rich as jEdit.
-G
I assume that when you did this, there were no parts of the program already loaded in memory, and all of the functionality of jEdit was available at startup?
Yeah. I just open it, see the splash sceen for a second and I’m in.
I assume that by answering my UltraEdit/jEdit post, you were trying to prove that Java’s performance is as good as native apps?
No, actually I wasn’t. The performance of VM languages isn’t as good and will never be as good as that of native apps. My point is that Java’s performance is good enough, and this myth that it’s *slow* is a relative argument from Java 1.0 on 1995 hardware.
you along with all the other Java zealots [….]
Look, I’m no Java zealot. I use the right tool for the job when the toolbox is mine to choose from. Personally, I think C# is a ‘better’ language (operator overloading, delegates, enumerations, etc.), but Java is a nicer ‘platform’. To each his own. But lets actually have an intelectual discussion about it instead of digressing to the elementary school payground with talk of pulling pants down and swearing up a storm. That sort of garbage leads no creedence to your point and makes you look more like a boob than a guy with a legitimate argument (which I admit you have, I just happen to disagree).
Let Java die.
The market gets to decide that. Maybe it will die. Maybe it won’t. But at least in Columbus, 1/2 the businesses in town have an extensive Java infrastructure already in place. (The other half, of course, are Microsoft shops like where I work).
Performance is not important to every application.
It is if you take into account the fact that the majority of the world’s computer users don’t exactly have the latest and greatest hardware. I have friends who are still on 233MHz Pentium systems running Windows 98.
And, as computers get faster, the magnitude of the performance issue diminishes quickly.
Yes, that again assumes your entire userbase is running the latest and greatest hardware.
Here’s the thing… a native application will run just fine on those Pentium 233 systems. A Java application will take several minutes to start up, and will probably have the system swapping so badly as to make it unusable.
What good is portability between Windows and other operating systems if 97% of the computers in the world are running Windows, and your Java application can’t even run on the majority of those systems because they are not powerful enough?
Given this, I’d argue a native Windows application has a greater potential userbase than Java applications, because there exists a large number of Windows systems for which the overhead of Java is too severe to make the application usable.
Let Java die.
Java won’t die, simply because it has garnered enormous mindshare and has niche penetration, namely for developing web services.
I forsee a future where Java applications continue to be rammed down our throats for some time to come…
Argue all you want about how Java isn’t that bad, but one thing remains the same for me:
I hate using Java applications
On my machine it takes 5 seconds for the splash screen to appear. This is a Linux system AMD 1200Mhz 512MB Ram
Here’s the thing… a native application will run just fine on those Pentium 233 systems. A Java application will take several minutes to start up, and will probably have the system swapping so badly as to make it unusable.
Sure. You’re absolutely right. And if I was asked to make a choice at gunpoint, I’d say that currently Java is better suited to the server room (where the percentage of crappy hardware is much lower) than on grandma’s old pc. That doesn’t exclude it from use at home, just that it’s not best suited there. Who knows if that’ll always be true though. But, from a developer standpoint, a heck of a lot more of the software being written daily is for businesses – not the home users.
Not to get too off topic here since this isn’t an article about jEdit – but since I’ve made the statement benchmarking jEdit on my machine at ~1 second, maybe I ought to at least give the specs on that number.
jEdit version 4.1 final – not preloaded in memory
Sun’s Java SDK 1.4.1_02
Windows 2000 SP3
AMD 1700+ (1.47 GHz) 512 Meg RAM
I haven’t used Jedit ever, but how often do you start up an app that startup time matters? The only time I start my editor is when I restart my computer. Egad. That’s why we have swap space!
The performance of VM languages isn’t as good and will never be as good as that of native apps.
I don’t think this is true. By compiling at runtime, JITs are able to make more optimizations than are possible with a static compiler using things such as method devirtualization, method inlining, and variable to constant conversions. Java itself might not perform better than native code on average (it’s an old architecture, not optimized for JIT compilation), but VM code can in principle outperform native code.
And, Darius, the startup time of a java application is not an indication of how well java performs when an application is actually running. When a java application starts up the virtual machine and all the core java libraries have to be loaded, so of course it’s going to take longer to launch than a native application without a VM whose libraries are already loaded. Java 1.5 will probably have JVM sharing, as the Apple JVM does, which will enable instantaneous startup times since the VM will be already loaded.
And java performance is already very good, better than gcc 3.2 in many areas. You might be surprised by some benchmarks. For example:
http://www.visi.com/~khuber/java/JavaC.pdf
You can find more with Google (but don’t be fooled by benchmarks from 1997).
On my machine it takes 5 seconds for the splash screen to appear. This is a Linux system AMD 1200Mhz 512MB Ram
There’s something wrong with your setup. I see the splash screen in less than a second on my linux box with an 800MHz athlon and 384MB of RAM. (Do you not have DMA enabled for your hard drive?)
Machine (yes this is my nome desktop):
Dual AMD Athlon MP 2000+
1 gig RAM
SCSI drive
Windows XP Pro SP 1
I rebooted the machine for each test.
UltraEdit – ~3 seconds to start
JEdit 4.1 with JDK 1.4.1_02 – ~4 seconds to start
JEdit 4.1 with JDK 1.4.2 beta – ~3 seconds to start
So the time is essentially the same (note those are rough numbers with a stop watch…).
How exactly are you getting that Java is slow?
I have DMA on
hdparm -tT /dev/hde
/dev/hde:
Timing buffer-cache reads: 128 MB in 0.76 seconds =167.98 MB/sec
Timing buffered disk reads: 64 MB in 2.86 seconds = 22.40 MB/sec
I was using Jedit 4.0.3 but I just upgraded it to 4.1 Final
It now takes 3 seconds for the splash screen to appear.
Konqueror takes 2 seconds to load fully.
My Java is Sun Java 1.4.0_02
ps I think Java is good but it does really really need a speed boost.
This is hardly the kind of benchmark that is going to convince anyone that hates Java performance that it can be as fast or even faster than C. I am more even keeled on Java, I’ve used if for rapid problem solving and will test it periodically to see if its useable. Right now I am on BeOS so its a no go. I love the language, I don’t like what happens when I call the libs and my performance leaks away.
The FFT, Fibonacci, Life, Queens, Primes apps are the simplest compute problems that can show the JVM working on a very small piece of 1 page code. I am sure very little use is made of new and memory allocation, garbage collection and probably no use of any of the infamous libs that do slow Java to a crawl.
If all the worlds computer users sat in front of these codes, its not too difficult for any language compiler or JIT VM to get close to the best an asm coder could do. But when I run the slower Java apps, they are usually dying somewhere in the endless code in the libs performing new(), GC delete and maybe even using some seriously flawed simplistic algorithms.
A more convincing test app would be for something like a word proc performing some serious complex formatting etc but only if it uses the same algorithm as the C equivalent. Thats something users can experience.
One thing that C allows for is for coders to do things that are perfectly safe if you know what you are doing, but considered to be dangerous to Java devs. My fav is the macro preprocessor, in C I can write a x lang compiler that is direct and extremely fast and reads like the EBNF of x. In Java I am forbidden a long list of things, preproc, ptrs, self modyifying code, ignoring types, direct memory management, asm insertion, I could go on.
My suspician is that any Java code that can easily be converted into equiv C will be so so faster. Then in addition any really skilled expert can do things to obtain even more speed in ways Java just does not permit or make easy.
Java is in essence a nanny language, thats great for rad code or safe code or large complex code or newbie code, sometimes though I just gotta think in terms of the cpu internals.
I could probably bet that UltraEdit and other natives do a fair no of things directly in x86 asm or atleast mindfull of cpu that Java does good a job of covering up. For those that don’t know x86, its nowhere near as bad as it once was to write decent risc asm, and most commercial apps are probably using it.
Not to rain on Java, but I just wish Sun would trash the religion and allow what works best to rule. If I could easily mix Java & ‘managed’ C++, I’d probably be in heaven, but then I’d have to deal with JNI.
By compiling at runtime, JITs are able to make more optimizations than are possible with a static compiler using things such as method devirtualization, method inlining, and variable to constant conversions. Java itself might not perform better than native code on average (it’s an old architecture, not optimized for JIT compilation), but VM code can in principle outperform native code.
I am so tired of ignorant Java zealots continuing to insist that you can’t perform optimizations of compiled code based upon information gathered at run-time.
It’s called Profile Guided Optimization, a feature of the Intel C/C++ Compiler and one which will soon be a feature of gcc.
To quote the ICC manual:
http://www.intel.com/software/products/compilers/c60l/resources/c_u…
“Profile-guided optimization creates an instrumented program from your source code and special code from the compiler. Each time this instrumented code is executed, the compiler generates a dynamic information file. When you compile a second time, the dynamic information files are merged into a summary file. Using the profile information in this file, the compiler attempts to optimize the execution of the most heavily travelled paths in the program.”
While this does have the downside of requiring developer intervention, it’s superior to Java’s approach in that the optimizations are persistent, whereas Java must start from scratch every time, including re-JIT compiling all Java bytecode back to native code.
However, there is no inherent flaw in the nature of compile code that prevents run-time optimization.
“While this does have the downside of requiring developer intervention, it’s superior to Java’s approach in that the optimizations are persistent, whereas Java must start from scratch every time, including re-JIT compiling all Java bytecode back to native code.”
Not true – from a theoretical point of view (not sure if there are any existing JITs that actually do it in practice).
The Java Class File Format was designed to be extensible – one thought was to cache the JITed code in the .class file thus avoiding the re-do of all the work. Symantec did have a VM that basically did this… but it was buggy and I am not sure if it ever reached any customers.
Also Profile Guided Optimizations cannot inline virtual methods – in the case of Java it is possible (HotSpot does do this AFAIK). If the VM knows that a non-final method is not overridden by any currently loaded subclasses then the method can be inlined. If a class is loaded later that breaks that the method can be un-inlined. Of curse this requires the time to do the housekeeping. It is not possible for C++ to do this – any dll/so could be loaded that would break that if it was done statically.
1. I run the application once and use it for hours.
2. The hw is getting faster and faster.
3. If you can’t live without native applications, just download a free Java to Native compiler (such as Excelsior Jet, or GCJ), and cool your balls with faster startup (the execution does not get really really fast though, since Java is optimized enough.)
1. I run the application once and use it for hours.
And what is “the application”? Are you saying that people who close applications and start them again several times a day are foolish?
Have you not noticed that this issue comes up every time Java is discussed? There’s a large and vocal group trying to get the message across that “We are tired of waiting for Java applications to start.”
2. The hw is getting faster and faster.
Not fast enough. 2.4GHz isn’t enough to get a reasonable startup time out of Limewire. (10 seconds?!) Also, remember, a lot of people aren’t on high-end hardware, and what executes nicely on your > 1GHz system isn’t usable on my friend’s Pentium 233MHz. Not everyone can afford new computers, and for many people it certainly isn’t a priority. Using native code alleviates this problem.
3. If you can’t live without native applications, just download a free Java to Native compiler (such as Excelsior Jet, or GCJ), and cool your balls with faster startup (the execution does not get really really fast though, since Java is optimized enough.)
This is a technical solution, available only to those with the know-how necessary to make it work. For the majority of computer users, this goes well beyond the scope of their knowledge.
Not true – from a theoretical point of view
Meanwhile, back in reality, .NET caches compiled native code already.
Also Profile Guided Optimizations cannot inline virtual methods
Did I mention I’m an advocate of C, not C++? But regardless, templates can be used to avoid the overhead of virtual functions by using a templated class in place of inheritance. A templated class does not use the vptr table because the type of class is known at compile-time instead of having to be determined at run-time. Also, the non-virtual methods in a templated class can be inlined.
While it’s true that Java can do certain optimizations not possible with pre-compiled code, it also can’t do certain optimizations that *are* possible. JIT has to be quick. Thus, there are many optimizations that can’t be done because of time constraints. For example, in C++, a compiler can do a full alias analysis, so it can optimize code even in situations where multiple pointers pointing to the same variable can make optimization dangerous. It’s rather unfeasible for a JIT compiler to do this. The performance of the JIT in Java is helped by the fact that Java is a relatively simple language, and thus easier to optimize than something like C++. However, this is still a clear limitation in the JIT approach. The situation will become even more interesting if IA-64 becomes popular. IA-64 is extremely dependent on good compiler optimizations to get decent performance and this might hurt a JIT approach. Another major weakness of the JIT approach lies in the type of code it’s good at running. JIT’s are good at optimizing small, repetitive loops. That’s why the benchmarks the benchmarks an earlier poster linked to show Java in such a good light: once the first iteration of the loop is complete, the entire benchmark has been compiled to native code and is sitting inside the cache. A far different situation is more general purpose code: code that meanders through short loops, tons of branches, and hits lots of different code pages. It’s this type of code that JITs don’t cope as well with.
Now, this said, I think the whole concept of the JVM is a little gimicky. Java programs aren’t portable because of the JVM. They’re portable because of the standard Java libraries. If you use nothing but the C++ standard library, your program will be portable to a whole lot more architectures than a Java program (because the JVM itself is a huge task to port). If it has a GCC port (and pretty much everything does
it will run your program with nothing more than a quick recompile. Of course, the C++ standard library is a whole lot more limited than the Java standard library, but the VM has little to do with it.
Now, as the arguement goes, hardware keeps getting faster. While that’s true, I don’t see a giant JVM as the best place to throw those extra hardware resources. Java (as a language, we’re not taking the library into account) is still fairly low level. Semanticaly, the language isn’t a whole lot different than C with classes. Going forward, I’d rather see additional hardware resources going to support really higher level languages. The other night, I decided to do a graph evaluation program in python. Hacked the thing together in a couple of hours, with only 200 lines of code. The thing parsed XML, dynamically loaded objects, the works. Many features worked the first time I tried them, without any debugging required. Right now, Python is still too slow for serious application development. But going forward, it’s going to be these high level languages dominating in the future, not rehashes of the 1980s like Java.
Very well said, and good points all around.
i’m a java developer and use jedit everyday, here’s what i’ve noticed on my machine (p4 2.4ghz, 512mb ram, windows xp) with 1.4.2 beta
* startup time is faster. smaller apps startup almost instantly (see the “notepad” demo). in larger apps i only see a slight difference.
* starting jedit 4.1 (swing) with 28 plugins is about the same as starting eclipse 2.1 (SWT) with the default install. this is counting time until main window appears, not splash screen. ~4 seconds for both.
* using the windows xp theme isn’t perfect. menus don’t look like xp. jedit toolbars look strange. most widgets look great though.
* In SwingSet, on windows xp, “GTK look and feel” menu item is grayed out. however, GTK lnf code is in is runtime jar.
* UIManager.getInstalledLookAndFeels() returns metal, motif, and windows. no gtk. and there is only one windows lnf. i wonder if the old windows lnf is shown on windows 9x/2000?
* both the SDK and JRE download for windows increased by 6MB. that means the windows JRE is 14MB. is this because of the new look and feels?
* the server VM uses SSE and SSE2. if i’m reading this right, hotspot writes SSE/SSE2 code for you as an optimization. if so, this is really amazing.
* java plug-in control panel has a “automatically check for updates” option that is selected by default. nice.
all in all, except for the 6MB extra download size, i’m impressed.
“you have to make up all of these lame-ass excuses of why performance isn’t that important. “
People moaned and moaned about how nobody would ever use C because it was so slow compared to Assembly. Then people moaned that C++ was too clumsy and slow compared to C. Now people are moaning that Java is too slow compared to C++.
Recognise the pattern? Anyway, Java speed issues are a little bit of a myth. Sure, some programs are just written so damn bad that they suck speed wise but a ‘tweaked’ Java app isn’t really that much slower, and in some cases faster than the equivalent C/C++ app.
Check out
http://www.rolemaker.dk/articles/evaljava/“>for .
The truth of the matter is, in the real world, if you are developing in a company such as mine, where you need real world programmes developed quickly that are going to run on P2 500s then your first choice is Java and your last is C++.
Throw in the fact that you’ve got to deal with multiple incompatible platforms (Win95, Win 98, Win NT, Win 2K, Mac OS 8-9 and OS X) then C++/C just isn’t an option and neither is .NOT.
Just face it – right now Java is the only tool that does most of the job, sure if MS ever ports .NET to another platform and allows it to run on Win 95 then maybe they’ll be a little competition – but I don’t see that happening.
“And what is “the application”? Are you saying that people who close applications and start them again several times a day are foolish?”
No, i tend to say, in general, applications are run once and used for a long time.
“Have you not noticed that this issue comes up every time Java is discussed? There’s a large and vocal group trying to get the message across that “We are tired of waiting for Java applications to start.””
You are bringin up the same issue again and again. Have you noticed that lots of people, even in this forum says that it is not like that, and they are not much disturbed with the lag? If you didn’t here you have: The lag of initializing VM is not disturbing me much. You are exaggerating it. Hopefully, you got it now.
2. The hw is getting faster and faster.
“Not fast enough. 2.4GHz isn’t enough to get a reasonable startup time out of Limewire. (10 seconds?!) Also, remember, a lot of people aren’t on high-end hardware, and what executes nicely on your > 1GHz system isn’t usable on my friend’s Pentium 233MHz. Not everyone can afford new computers, and for many people it certainly isn’t a priority. Using native code alleviates this problem.”
No. If you have 10 sec startup for Limewire, it is the problem of Limewire, or your computer, or you. I use lots of swing based programs, and none takes 10 secs. Even if it would, 10 secs is nothing when compared with the time for using it. How long does it take on Win box to start up wonderful MS Outlook? 1 sec? ha ha.
3. If you can’t live without native applications, just download a free Java to Native compiler (such as Excelsior Jet, or GCJ), and cool your balls with faster startup (the execution does not get really really fast though, since Java is optimized enough.)
“This is a technical solution, available only to those with the know-how necessary to make it work. For the majority of computer users, this goes well beyond the scope of their knowledge.”
I agree, but this was targetted to the techical people, such as “you”. It is possible to make a Java VM, which can do the same thing as .NET VMs can. That is, compiling to the native platform on the runtime. Which, is not necessary for me, and for many people anyway.
Oh, besides, program sharing VM is on the way, it is already available on Mac, and Sun’s Java 1.5 release will have it.
While it’s true that Java can do certain optimizations not possible with pre-compiled code, it also can’t do certain optimizations that *are* possible. JIT has to be quick. Thus, there are many optimizations that can’t be done because of time constraints. For example, in C++, a compiler can do a full alias analysis, so it can optimize code even in situations where multiple pointers pointing to the same variable can make optimization dangerous. It’s rather unfeasible for a JIT compiler to do this. The performance of the JIT in Java is helped by the fact that Java is a relatively simple language, and thus easier to optimize than something like C++. However, this is still a clear limitation in the JIT approach.
Mabey in the dark ages.
With Hotspot the JIT is a separate low-priority thread that does not directly degrade performance, and allows the original code to execute in interpreted mode at the same time the JIT is recompiling the code. The swap out takes place when the method being recompiled is not currently in use, and involves changing the address of a pointer.
That’s why the benchmarks the benchmarks an earlier poster linked to show Java in such a good light: once the first iteration of the loop is complete, the entire benchmark has been compiled to native code and is sitting inside the cache.
Not necessairly. The optimization may not be done until the 3rd or 4th time through the loop. And yes, the code that is repetitively called and expensive is compiled first. More often than not this isn’t just short little loops, but the larger more expensive parts that are run 3 or 4 times. Event handlers are often optimized very early on in Swing applications.
And yes, Swing is -not- slow. It’s the programmers who don’t know how to use it that make it slow. LimeWire is probably the prime example of crappy coding giving the gross public a terrible misconception of Java.
Excuse me now, I’m going to go hack some Java in JEdit with my antialiased fonts now.
Well, I’ll throw out my opinion for hell of it. What that hell is the relevance of start up times? I guess if something took 30 seconds to load that would be a problem, but I have never experienced that with any app. Java/Swing apps are fast enough for me, I don’t think anything takes more than a few seconds to load, and more importantly the performance is fast enough for me to be productive.
I could give a crap less about Java vs .NET vs whatever. I hold no loyalty to any camp, and use what works for me. I will admit that Swing apps don’t quite feel as “snappy”, but the difference is so small it’s irrelevant.
For you all that think that Java is going away or is going to die, you need to follow business/development news a bit more. Java is so entrenched in business, it’s going to be around for a long time. Also, it stands as the main solution on the back end when teamed with Unix or GNU/Linux for organizations to avoid the MS .NET lock-in.
>Not fast enough. 2.4GHz isn’t enough to get a reasonable >startup time out of Limewire. (10 seconds?!) Also, >remember, a lot of people aren’t on high-end hardware, and >what executes nicely on your > 1GHz system isn’t usable on >my friend’s Pentium 233MHz. Not everyone can afford new >computers, and for many people it certainly isn’t a >priority. Using native code alleviates this problem.
There has got to be something wrong there. Is your Hard drive near dead???
When I execute limewire it loads instantly. I near thought that app was slow. There is no wait. This is on a 1.8 Athlon running Mandrake 9.1
“That’s why the benchmarks the benchmarks an earlier poster linked to show Java in such a good light: once the first iteration of the loop is complete, the entire benchmark has been compiled to native code and is sitting inside the cache.”
If you are going to try and argue with facts it is probably a good idea to make sure your facts are correct.
http://java.sun.com/docs/hotspot/VMOptions.html
-XX:CompileThreshold=10000
number of method invocations/branches before (re-)
compiling [10,000 -server, 1,500 -client]
-XX:+PrintCompilation traces methods as compiled
The java library is protable because it is written in java. To suggest all C++ needs to be portable is a robust standard library (a library with more features than containers and basic algorithms, which took years in C++) that has been ported to every platform under the Sun is a bit naive. If such a library were practical it would have been done by now. The cost of porting such a C++ library must far out weigh the cost of porting the JVM (or it would have been done by now). Also, the library is less stable (changes much more frequently) than the JVM. You always want any code you have to port to be stable, because porting is such a pain. Finally, it is easy to add new and distribute new libraries for java. Just write it and distribute the .class files. Writing a new library for C++ is a huge pain if you want it to work on more than one platform. To suggest that you can really write a portable non-trivial system in C++ is analogous to saying you can write everything in assembly – possible in theory but practically impossible.
The java library is protable because it is written in java. To suggest all C++ needs to be portable is a robust standard library (a library with more features than containers and basic algorithms, which took years in C++) that has been ported to every platform under the Sun is a bit naive. If such a library were practical it would have been done by now. The cost of porting such a C++ library must far out weigh the cost of porting the JVM (or it would have been done by now)…
It’s called Qt
You said let java die only because java sometime can not outperform NATIVE applications.
You said performance does matter.I agree with you.
But performance is not the whole thing.
Why not you shout against windows 1.x or 2.x ‘to die’?
Why not you compare windows against high-end unix server?
Why not you bound yourself with a rocket to gain highest move performance?
I hope you can understand you always need other things beside performance.
If you are young, you still have hope, and you can hold hope for young things, for example, your baby/babies.
Yep, all those floating point intensive routine are gonna get a speed boost.
http://www.javalobby.org/threadMode3.jsp?message=58889099&thread=73…
Probably nobody reading this thread anymore, but – I love QT. And all the parts of your application written in QT are portable across all the major platforms. For a price. But there will always be some functionality you need that isn’t in QT. Witness KDE. A great desktop environment based on QT, but still has to solve all the same old portability problems because it uses so much non qt code. You may find a great library that implements some functionality not in QT, but is that library also portable across all major platforms? Probably not. You can port the library, if you can get the code, and the license allows. Or you can re-write the functionality your self, which means you have yet another component to design, write, debug, test, port, and maintain before you can ship when bomb proof code is out there. The fundamental problem with “portability” in compiled languages is that it doesn’t scale. The problem grows as the amount of code grows. Every line of code written for that language must be written with portability in mind from now to the end of time. A VM solves this problem neatly.
how does an average user add the gtk theme to jedit 4.1 with jre1.4.2. i’ve tried modifying the swing.properies file as well as adding the command line option, but nothing happens.
do i need to set custom classpaths or something.