The new version of Cacao called “Tomclipse” relesed. This GPL-licensed JVM uses GNU Classpath 0.16 as its class library. You can find it here and here are some screenshots. Also, JTree of GNU Classpath made good progress. Have a look here.
The phrase “You can find it here and here are some screenshots” should have been written as something like “Screenshots are available”, with the word “Screenshots” linked to:
Your interest in Sun’s JVM font rendering borders on the obsessive. Some could write an application in Java that would provide a solution to end world hunger and then display the instructions on screen and your only observation would likely be that, “Cleartype is much easier to read”.
Yeah, well every other toolkit around solved the shitty font problems years ago. Sun’s half-assed attempt at its own subpixel rendering has failed because they refuse to use superior native solutions. But I guess Swing apologists would be happy if the fonts looked like something from an Amiga circa ’88.
Oh well, we have SWT now and hopefully Classpath at some point in time.
Someone may write some Java app that promises worldwide utopia. But there would be footnote that would say something like “Requires Lifetime IBM Platinum Service Contract”.
No matter what Java app we are talking about — the mythical Java world hunger solution or the many Java implementations of globalization dsytopias — when it comes to the readability of the fonts…
Lumbergh would be right.
ClearType is much easier to read. I have every system, Linux, FreeBSD, Mac, and WinXP, and ClearType is way ahead, especially on small font sizes. It makes other systems look incredibly crude.
Ultimately if you have to use the computer for any length of time, ClearType will likely add 10+ years onto the time you can read the screen. The eye has to strain much more if you use Mac or Linux.
And if didn’t have ClearType, you couldn’t read that little footnote about lifetime bondage to IBM. Now wouldn’t that be a shame?
Cleartype is definitely superior, but I would be happy with Swing fonts that were on par with freetype or OSX. Sun still hasn’t even got that far yet; even post Mustang B39.
I wanted to use the Jedit ruby plugin (which is very nice), but even with a post B39 build it looks like crap and way too much eyestrain for everyday use. Sun has failed to make Swing a viable client-side option.
Seems like the oldest build I’ve ever seen in a screenshot… we’ve surely come a long way since then.
On a side note, I’m glad to see the OSS Java VMs finally get to the point where real, everyday Java apps are starting to run well on them. Seems like Jetty is starting to work well with them as well.
Is there an option to use the X11 bitmapped fonts in your Java apps? It’s tough to beat hand-crafted pixel-perfect bitmapped fonts for clarity — especially for these tired old eyes on this nice flatpanel.
johnMG: Yes and no. While I believe that currently, GNU Classpath’s AWT does support X bitmap fonts; I don’t think there’s any code yet which filters them out, so to speak.
However the status of this is a bit tricky; the AWT API doesn’t really allow for bitmapped fonts, since the vector outline path is retrievable through TextLayout.getOutline().
So the question here is if one should allow for bitmapped fonts and not support the above parts of the API in all cases; or if one should always support the above API calls and restrict support to non-bitmap fonts.
I’d side with the latter, but it’s probably best to allow for both through some system property setting.
I like the Swing screenshots of Cacao. They look like nearly like running with Suns Java.
Only the width of the scrollbar is bigger and some minor differences.
I like it. 🙂
It seems harmony is trying to do what these guys are doing ? I understand the need of an open source JVM but 2 ?
There are *MANY* projects to make Free virtual machines:
See the list of JVMs using GNU Classpath:
http://www.gnu.org/software/classpath/stories.html
i scream, you scream, we all scream for “here” links. so last century it is.
Quite right about the links. I really wish more people would write properly for the web.
For reference:
The word “Cacao” should have been linked to:
http://www.cacaojvm.org/
– not the word “here”.
The phrase “You can find it here and here are some screenshots” should have been written as something like “Screenshots are available”, with the word “Screenshots” linked to:
http://www.complang.tuwien.ac.at/cacaojvm/screenshots.html
– not the word “here”.
Finally, “JTree of GNU Classpath made good progress” should have linked to:
http://gnu.wildebeest.org/diary/index.php?p=100
– not the word “here”.
Notice how the Classpath Swing fonts look way better than even post Java Mustang B39 (the subpixel rendering build).
http://www.complang.tuwien.ac.at/cacaojvm/screenshots/gcjappletview…
This new capability of rendering dialogs is amazing.
There will be amazing boosts of productivity.
Within months, I predict there will be a 7 year old girl from Pakistan who gets certified as a Cacao Professional.
Your interest in Sun’s JVM font rendering borders on the obsessive. Some could write an application in Java that would provide a solution to end world hunger and then display the instructions on screen and your only observation would likely be that, “Cleartype is much easier to read”.
Yeah, well every other toolkit around solved the shitty font problems years ago. Sun’s half-assed attempt at its own subpixel rendering has failed because they refuse to use superior native solutions. But I guess Swing apologists would be happy if the fonts looked like something from an Amiga circa ’88.
Oh well, we have SWT now and hopefully Classpath at some point in time.
Someone may write some Java app that promises worldwide utopia. But there would be footnote that would say something like “Requires Lifetime IBM Platinum Service Contract”.
No matter what Java app we are talking about — the mythical Java world hunger solution or the many Java implementations of globalization dsytopias — when it comes to the readability of the fonts…
Lumbergh would be right.
ClearType is much easier to read. I have every system, Linux, FreeBSD, Mac, and WinXP, and ClearType is way ahead, especially on small font sizes. It makes other systems look incredibly crude.
Ultimately if you have to use the computer for any length of time, ClearType will likely add 10+ years onto the time you can read the screen. The eye has to strain much more if you use Mac or Linux.
And if didn’t have ClearType, you couldn’t read that little footnote about lifetime bondage to IBM. Now wouldn’t that be a shame?
Cleartype is definitely superior, but I would be happy with Swing fonts that were on par with freetype or OSX. Sun still hasn’t even got that far yet; even post Mustang B39.
I wanted to use the Jedit ruby plugin (which is very nice), but even with a post B39 build it looks like crap and way too much eyestrain for everyday use. Sun has failed to make Swing a viable client-side option.
Seems like the oldest build I’ve ever seen in a screenshot… we’ve surely come a long way since then.
On a side note, I’m glad to see the OSS Java VMs finally get to the point where real, everyday Java apps are starting to run well on them. Seems like Jetty is starting to work well with them as well.
Is there an option to use the X11 bitmapped fonts in your Java apps? It’s tough to beat hand-crafted pixel-perfect bitmapped fonts for clarity — especially for these tired old eyes on this nice flatpanel.
johnMG: Yes and no. While I believe that currently, GNU Classpath’s AWT does support X bitmap fonts; I don’t think there’s any code yet which filters them out, so to speak.
However the status of this is a bit tricky; the AWT API doesn’t really allow for bitmapped fonts, since the vector outline path is retrievable through TextLayout.getOutline().
So the question here is if one should allow for bitmapped fonts and not support the above parts of the API in all cases; or if one should always support the above API calls and restrict support to non-bitmap fonts.
I’d side with the latter, but it’s probably best to allow for both through some system property setting.