Information and pictures of the new Swing on Java 1.4.2. Elsewhere, this article examines some of these urban performance legends and ‘sets the record straight’ regarding Java’s performance.
Bug Fixes and Upgrades in the Upcoming Java 1.4.2
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Do the GTK and XP ‘look and feel’ updates do their job correctly (pulling the XP manifest, matching the GTK user selected theme)? Or are we going to have a case of e.g. XP users running with win2k look/feel seeing the M$ Tonka-Toy XP interface?
Nothing on the release eludes that these are no more than some ‘extra themes’.
If that is indeed the case then this is indeed as stupid as their previous non-compliant (and ugly) swing interfaces.
That is quite significant, if it is true.
15-20% Swing speed improvement is also good (though 15-20% faster than ‘runs like a dog with two broken legs’ means at least one of the dogs legs is still broken.) Seriously, this is much needed and very welcome.
Nice work on the sound front too.
This is by far the most encouraging changelog I have ever read for a Java release.
However, to nitpick, I think their GTK+ theme looks like ass.
I will, of course, eat my words if the GTK+ theme picks up whatever settings and window manager decorations you have made in the ‘native’ GTK environment, but I can’t imagine there are more than 20 people who use those Metacity window decorations, so apps using this theme will just end up looking even more out of place than with the standard Swing look n feel.
I don’t understand why Sun don’t implement an API extension to GTK+ which allows them to easily bind Java to native GTK widgets when this is possible, to pick up look n feel settings from the native enviroonment, and of course fall back to the standard Swing stuff in other cases. It’s not like they don’t have the source, and they did at one point actually commit to using GTK for their widget set.
If anything is going to improve both Linux/Solaris and Java’s prospects on the desktop, this would be it.
I recently testet the 1.4.2 beta, and while the GTK look’n’feel were nice, it had bits and pieces missing. Stock icons didn’t look similar, the info/warning dialogs looked odd. Quite a few other minor thing making it not look “right”.
Hope much of it is fixed in 1.4.2, cause the Motif look is just plain ugly and the Metal look is not much better.
Time for some new nice default looks in Java/Swing on *nix
Does anybody know how can i enable antialias for fonts in Linux/Java/Swing applications? So far i have figured out how to use microsoft ttf fonts in Linux/Java/Swing, but these fonts are not antialiased.
The article states:
The recently released version 1.4.2
I know the beta’s out but that phrase sounds like the FCS has been released. If only it were true…
From the forums:
http://forum.java.sun.com/thread.jsp?forum=57&thread=141821
“Do the GTK and XP ‘look and feel’ updates do their job correctly (pulling the XP manifest, matching the GTK user selected theme)? Or are we going to have a case of e.g. XP users running with win2k look/feel seeing the M$ Tonka-Toy XP interface?”
I tried it on XP: if you choose the classic look you don’t get the toy look – it also updates automatically when you switch classic/XP. It feels faster too.
A lot of those things in the java performance article can also be solved by a good obfuscator, since obfuscation is only one of their tasks.
Though I don’t know if there are any free ones, unless IBM put its alphaworks one back into the free world.
Since it uses native widgets it looks like whatever is native on the platform. No attempts to emulate the look-n-feel.
java.text.*
what a mess. look at the code, and you’ll find the guys who wrote it agree.
However, to nitpick, I think their GTK+ theme looks like ass.
Maybe… It’s the default theme though.
Maybe not a perfect clone but very close.
I will, of course, eat my words if the GTK+ theme picks up whatever settings and window manager decorations you have made in the ‘native’ GTK environment, but I can’t imagine there are more than 20 people who use those Metacity window decorations, so apps using this theme will just end up looking even more out of place than with the standard Swing look n feel.
It does! Or plans to do. If I understand it correctly, what they have working already are the Gtk engines Defautl, BlueCurven and Pixmap (which means that all pixmap themes are supported). To support new theme engines, they have to be supported by Java though, so new engines wouldn’t automatically work with Java (understandable).
As for Metacity, I think they had a few different styles working already (hard coded) and are planning on actually using and interpreting the Metacity XML theme files in a later version. MDI is horrible though.
The GTK themes are emulated to a degree. Bluecurve and the default theme are both emulated, the pixmap theme will pick up pixmaps from the native GTK theme though.
If you want you’re Java apps to really look like native apps then you need to use something like the SWT toolkit from Eclipse. It’s faster than Swing for most things as well.
Using 1.4.1 the JFileChooser took around 30-60 seconds to load but right now it takes 2-3 seconds with 1.4.2 beta, this is really good, I don’t know how could they have these bugs for so long time.It’s good they”ve done it!
Sun are discussing how to proceed with speeing up swing even more. It’s obviously the “threath” from SWT as used in the eclipse platform that makes sun be more agressive on the client side for this release.
The problems are quite fundamental for the java platform though. I run netbeans as my IDE, and i easily goes into the 250MB memory usage range for a medium to large size project. I think most of this is due to models used for the various parts of the GUI, eg. the explorer is very capable, with the possibility to expand a java class files’ node to see the members, methods and field for the class. Such a tree model takes up a lot of memory, and even worse, when it’s rendered with swing there are a lot of short lived objects being created, which has to be gc’ed.
If you try to run a medium to large application in eclipse, it doesn’t really run that much faster though. Some gui updates are a bit faster, since they are done with native code, but the temporary object creation problem is still there. And you cannot solve that problem by moving all of the models for your gui into native code either, or you’d fast end up with a non-java application.
For the next jdk release (1.5) sun will hopefully deliver a means of shared jdk data between multiple java vm’s. This can at least bring down the static size of java apps, since each vm will no longer need to jit (just-in-time) compile it’s own copy of the base jdk classes.
What would be interesting to see in addition, is the possibility to run swing on a different implementation for Java2D. Such an implementation could either be OpenGL (see eg. http://www.cs.umd.edu/hcil/agile2d/ , such an approach could potentially provide subpixel antialiased font rendering), or the RENDER extension (unlikely, as long as RENDER runs unaccelerated on most hardware using XFree86 drivers). Sun mentions these things here: http://developer.java.sun.com/developer/community/chat/JavaLive/200… .
I will, of course, eat my words if the GTK+ theme picks up whatever settings and window manager decorations you have made in the ‘native’ GTK environment, but I can’t imagine there are more than 20 people who use those Metacity window decorations, so apps using this theme will just end up looking even more out of place than with the standard Swing look n feel.
I don’t understand why Sun don’t implement an API extension to GTK+ which allows them to easily bind Java to native GTK widgets when this is possible, to pick up look n feel settings from the native enviroonment, and of course fall back to the standard Swing stuff in other cases. It’s not like they don’t have the source, and they did at one point actually commit to using GTK for their widget set.
Well, from what i see, they don’t actually “integrate” GTK theming, they just make swing look like a GTK application. As soon as you change the default theme for the rest of the desktop, the swing application will stay the same.
As for the native Java binding, that is what SWT is for and from what I see, I would love to see it eventually replace Swing/AWT and any other TLA that is floating around. SWT already has a number of bindings, namely, GTK2, OpenMotif/Motif, Carbon and hopefully in the not to distance future there will be a Cocoa version, win32 and photon. So, in a nutshell, SWT is already “there”, it is just a matter of IBM and a significant number of java programmers willing to jump on their soap box and demand that SUN include it into the Java specification and include it in their own java virtual machine.
Does anybody know how can i enable antialias for fonts in Linux/Java/Swing applications? So far i have figured out how to use microsoft ttf fonts in Linux/Java/Swing, but these fonts are not antialiased.
Apparently there is one of SUN’s reasons for writing STSF ( stsf.sf.net ), which should provide anti-aliasing capabilities to Swing.
Since it uses native widgets it looks like whatever is native on the platform. No attempts to emulate the look-n-feel.
is is more of a wrapper that still allows WORA, however, as you pointed it, it directly links back to the native widget sets.
The folks claiming that Sun should replace Swing with SWT apparently haven’t done much Swing or SWT programming. I’d suggest looking at how interfaces are created in SWT vs Swing and the Swing toolset vs SWT before making such claims. SWT doesn’t come close to Swing for most things. Yes it is faster because its native-based but programmed properly Swing can be just as quick. For example: JEdit or IntelliJ IDEA. You’d have a tough time convincing me that the Eclipse GUI is significantly faster than IDEA (I’ve used both extensively but use Eclipse day-to-day). I’ll gladly take the trade-offs involved with Swing to get what it offers. I have several Swing apps in use here at work (using the Metal theme) and haven’t yet had someone complain about the look or the speed. People want to get their work done. If the application looks similar enough I’ve found that people just don’t care about the bits that developers argue about (like the font for menus). They just care that the app does what they want and works.
RE:antialiased fonts
By Pete (IP: —.vic.bigpond.net.au) – Posted on 2003-05-28 07:22:10
From the forums:
http://forum.java.sun.com/thread.jsp?forum=57&thread=141821
That works for JTextArea’s and JTextField’s but not for JButton’s
…Actually, there already are Win32 and Photon versions of SWT (how do you think Eclipse runs on Windows and QNX?). As for Cocoa, I doubt it. Evidently Apple does not expose the bottom level of the UI event loop and so you can’t get the low-level event processing that the SWT needs. It was the original route they where going to take but it ended up being a dead-end.