Can you write Java code that compiles across several platforms but still performs as fast as native code? This is a problem that has vexed Java developers, particularly when it comes to applications with complex UIs. This article proposes an interesting solution to this problem. You’ll learn how to use JNI to access SLIK, a cross-platform C API that offers native performance on both Windows and UNIX. The JNI APIs demonstrated in this article will help you write skinned GUIs that run under both Linux and Windows with no code changes.
Design cross-platform Java UIs with native performance
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Ahh, why don’t they just write a back end code generator for Java that compiles the byte code to executeable code on *install*, then the Java code itself can run at native speeds. I always wondered when Java would get this capability, but it never happened. Instead we got C# and .Net.
Wake up Java folks!
why not use SWT ?
theses JNI wrapping a GTK+ Wrapper looks like a summary of error possibilities…
could be hard to debug…
ok, its a way doing it…
All compiling on install will give you is the code won’t have to be JIT’d at runtime. This still doesn’t solve the GUI problem. I think the real problem with something like Swing is that it does all the painting of widgets on its own. All it really asks of the OS is a handle to a brush so it can do its painting. A windows control is the result of years of hand optimized c/assembly and graphics driver 2d acceleration. Look at gtk2.x as an example of how even a c-based toolkit suffers performance problems on modest to slow systems.
Yeah, I also found it funny that this was an IBM developer site and it was introducing another toolkit. I guess the main difference is the skin thingie.
Native compilation has been around for many years but the lack of interest has pretty much killed of most development (see http://www.bearcave.com/software/java/comp_java.html#AllDead). Java has its place and purpose, but the desktop hasn’t been it. But who knows what the future holds
steveq
…to fix a problem caused by the failure of design and implimentation. Another layer on top of Java isn’t going to make it better. Is the result worth the effort?
Is this even truely cross platform any more or just cross Windows/Unix?
Meh…
Yup, that’s why some of us are working on a proper solution: http://www.xwt.org
(The lack of site updates is soon to be remedied as we’ve been hard at work behind the scenes.)
with 1.4.2, the look and feel has been extended to winXP and GTK+ (there’s also Aqua and normal windows), the gtk+ look and feel actually has the ability to parse gtkrc files. i wonder why there isn’t a look and feel class for qt…
Isn’t this what Webstart is supposed to do? the application is only chached as a web page I believe.
The sooner java is retired, the sooner more programs will run faster.
When a programmer cannot program in native code, that programmer needs to get another job !!
Java free and proud of it !!
The JVM brings the code house together, but the GUI re-divides it against itself. Can’t Java see the sharp object pointed at it?
as a unified solution.
why we just not improve the VM?
(the Swing implementation in the JVM)
if Swing is slow because it tries to draws everything by itself, so just change the way Swing draws.
— not invent another UI toolkit, that way will suffers developers.
look at the Java 3D, at first it is really slow.
now it offers a VM option for Direct 3D and OpenGL, on Windows, Linux and Solaris.
— to get benefits from hardware accelaration card and optimized code for each os. With NO changes in API.
if user want a better performance, just choose the runtime/VM that suits their OS/hardware. and Java 3D developers don’t have to change anything in their codes.
may be it’s also more or less similar to VCL in OpenOffice.org.
VCL is a GUI toolkit in OO.o. like Swing, it tries to draws evething by itself. many people also complain to its performance and intregration to the native look & feel.
instead of introduce new API/toolkit,
somebody come up with the “Native Widget Framework”
http://people.redhat.com/dcbw/
(btw, NWF target is mainly on native L&F, not performance. but as it leverage some native functionalities, one can expect a slightly better performance.)
the general concept is, no need to change anything in the rest of OO.o code, all of them still call VCL as it is. (i.e. no change in VCL API). and virtually all the changes will be done only under VCL implementation.
hmm… open source Java? so people can help improve Swing implementation? hmm… I have no idea.
Anyway, i think the article targets the use of “non-standard” UI. which is more than just “skinned” widget/window.
For example, Winamp v2 skin vs newer Winamp/Sonique/Windows Media Player/etc skins.
for the first one, the size, position, every properties of widget are the same .. only ‘color’ changes. for the later, you can change their size, position.. add/remove widget, have a non-regtangular window, etc.
does I understand it correctly?
cheers
When a programmer cannot program in native code, that programmer needs to get another job !!
Way to completely miss the issue. They are writing native code, native to the Java Machine. Then there are virtual software implementations of this for other architectures.
This is not an issue of incapable programmers, to waste time on things like manual memory management in this day and age is crazy.
If it has to be cross-platform and fast, why not use wxWindows? There’s a java wrapper for that one, too http://www.wx4j.org/
With all the MONEY IBM is making off JAVA,
maybe they could actually learn to be a TEAM PLAYER here and Fix SWING.
I’m starting to question IBM’s Management here.
Looks like they are making a concerted effort to Kill Java.
Did Microsoft Pay Them off Too( SCO )
IBM already has a big investment in SWT, showcased by Eclipse. It’s Sun that needs to come around. The funny thing is that Swing apps really aren’t that slow on a modern machine, but there’s a lot of perception floating around – and perception is reality. The bigger problem is that until recently Swing apps looked like crap on the desktop and also that Swing is a big, complex beast. Sun fumbles around for years, not really knowing what to do with Java and now it’s too late for anything to be done on the desktop. Why the hell can’t anybody redistribute the JRE? That alone, is a huge reason why Java never really took off with FOSS developers.
This is not an issue of incapable programmers, to waste time on things like manual memory management in this day and age is crazy.
Yes, I’m sure your end-users are grateful that you could save a few days worth of development, and in return they get an application that will always be slow.
… my application when using something like SLIK or SWT.
Carsten
You’re ignoring all the other benefits of a Java implementation. Get a clue!
Plus to say a ‘few days’ of extra time to use C++ instead is just plain stupid.
SWT is impossibly slow on my computer, compared to Swing. Just scrolling a text window up and down in SWT, I can see it visibly refreshing frame-by-frame as it does so. Its better on Windows, but then SWT isn’t really “cross-platform”, because it has horrible performance on other platforms (and is slower than Swing on windows too).
I was extremely amused by the latest Eclipse betas though. The whole argument of the SWT zealots is that SWT is better cos it looks more native – then they go and make Eclipse adopt a completely different l&f to windows itself. WTF? Perhaps soon they are going to find out how difficult and a pain in the arse it is to do this kind of theming with native widgets, and they’ll end up with the justification for Swing in the first place.
I agree. The eclipse team is going away from the thing that made them popular in the first place. And to do what? Something that SWING does better and more elegantly. The only thing SWT did for Java was create a schism. Well, it did foster competition. Netbeans 3.6b is just as fast as eclipse M7. I am trying my darndest to get the JGoodies stuff into the UI builder as well. That would be awesome.
My experience with SWT is that a user has no idea *whatsoever* that he/she is running a Java app. It is that fast, and it doesn’t require any native interfaces.
“The funny thing is that Swing apps really aren’t that slow on a modern machine, but there’s a lot of perception floating around – and perception is reality.”
Funny how some people keep saying that. I use several swing programs now (jedit, etc) both in JDK 1.4.2 and the Tiger beta. Swing is STILL SLOW.
Actually, Swing will ALWAYS BE SLOWER than native code. It’s computer science 101: as an extra layer on top of the native drawing code, it will always use MORE instructions to do the same thing. More instructions = more CPU time.
(btw, SWT is also an extra layer on top of the native code, but it is a very small layer because in the main it just delegates drawing widgets to the native code, i.e fewer extra instructions).
“The bigger problem is that until recently Swing apps looked like crap on the desktop and also that Swing is a big, complex beast.”
Swing still LOOKS LIKE CRAP. The default l&f is crap, even in SDK 1.5 (Ocean). The “platform” look and feels aren’t. There are so many VISUAL differences between Swing Windows XP L&F and actual XP look and feel, but an OS project was started to remedy this, providing a patched and correct native L&F based on SUN’s original.
But the worst problem is that Swing, even with the nicest look and feel, doesn’t FEEL native. Stuff behaves differently. For example, in Swing’s Open File dialog, you don’t have the same options as in the native platform (context-menu, etc.).
On top of all this, Swing has a very ammateurish class design (“overengineered”, probably by people who have just saw the Object Orientation and Patterns light).
Add to all these that the layout classes are extremely messy and inconsistent, which is probably the reason noone has come up with a decent GUI editor like QT Designer or even Glade, yet. (NetBeans etc, don’t even come close, and
Eclipse form editor -currently in beta-, doesn’t look much).
It was also plagued with severe bugs (most are corrected now).
SWING must die a slow, horrible, death.
Check the Swing Connection (as SUNs site) to see what passes off as “elegant swing gui”. Run these programs.
Sorry to all those Java developers, but anything written in Python and using the wxWindows libraries runs *much* faster and more responsive than anything Java app / UI toolkit combo I’ve ever tried (on my PII 333 at least).
My experience with Swing has been that properly written code is plenty fast, but it generally looks mediocre at best and really only attempts to superficially look like the native environment.
One case for opening up Java is to rewrite the native foundation classes to use the native environment to draw it. The person said that all Java demands from the host environment is a paintbrush and a canvas was dead on. There’s no need for that to be the case, however. The native Java APIs could easily be boilerplate for a native implementation. I’d like to see a QT-based Java that loaded the L&F as defined by the system L&F settings. The backends would be different (as they are now), but much more of what Swing does internal to Java could be moved out into the host space and: run faster, be cognizant of the native L&F, and reuse UI components.
I do have several Java applications that I use, but it kills me to see them use the awful fonts, or L&F that looks nothing like my desktop.