The Source for Java Technology Collaboration
User: Password:
Register | Login help    

Search

Online Books:
java.net on MarkMail:

The Engine Driver

Posted by editor on October 10, 2008 at 7:54 AM PDT

Overhauling OpenJDK's FontManager

It's safe to say that you don't want to see comments like this, but probably do, all the time: 


/* This is implemented only on windows and is called from code that
* executes only on windows. This isn't pretty but its not a precedent
* in this file. This very probably should be cleaned up at some point.
*/

That's actually from OpenJDK's FontManager, and in a very interesting blog, Roman Kennke describes the contents of class as being more or less a total mess:

In the current OpenJDK code, this class is huge kitchen sink for all kinds of things that have no other place (or so it seems): it's a final class with all static methods, with platform independent font code, utility functions, platform dependend code (windows and solaris mixed), fontconfig code, all nicely packaged in one big class. To make it even worse, there's a bunch of similar font related methods in SunGraphicsEnvironment.

What's different from the usual case -- where we leave junky code in place because it seems to work and we have management jumping on our backs for new features and not cleanups of the old code -- is that Roman and his colleagues went in and cleaned it all up, as described in The Big FontManager Refactoring. They reduced FontManager to an interface, provided platform-specific implementations, created a factory to hand out a suitable manager for the current platform, and doled out the other important parts to sensible helper classes. Roman writes:

The scope of this change is quite huge, I don't envy the guy who eventually will have to review it :-/ OTOH, I really would like to get this into OpenJDK as soon as possible, because maintaining this big change and keeping in sync with upstream is a nightmare. When everything goes as planned, it should be possible to implement a completely different font backend (i.e. based on GNU Classpath's 100% Java fonts) based on this internal API. Yay!

Sounds great. Now what's the next piece of OpenJDK that needs an overhaul?

Also in Java Today, the SDN offers a feature article summary of Project Wonderland in Project Wonderland: Go Ahead, Make a Scene. "Project Wonderland is a toolkit of open-source software for creating 3D virtual worlds. But it's not what it is that excites people; it's what it does. Project Wonderland allows developers to create highly interactive environments where people can collaborate, conduct real business, and learn through immersive media. It takes virtual worlds to a whole new level of scalability, reliability, and extensibility."

As announced in the forums earlier in the week, the Final Review for GlassFish v3 Prelude Documentation is underway. The final drafts of the GlassFish v3 Prelude documentation are available now from the GlassFishDocumentation Comments Wiki, and members of the GlassFish documentation team have asked subject matter experts individually to review sections of the documentation that apply to their area of expertise. The deadline for comments is Monday, October 13.

Apropos of nothing at all but idle wondering, the latest java.net Poll asks "How many active buttons are on the mouse you're using right now?" Cast your vote on the front page, then visit the results page for current tallies and discussion.

Tomas Brandalik announces the release of Java ME Platform SDK Early Access in today's Weblogs. "Java ME Platform SDK Early Access has been released yesterday. Have a look [...] and don't forget to read what's new first, because a lot of cool features are waiting for you. My personal favorites are on-device features. One click on-device deployment and on-device debugging."

Masood Mortazavi shares his thoughts Reminiscing on Micro-Kernels and Group Communications. "Yes, I have to admit that, in my opinion, JGroups is probably the best early example of the "micro-kernel" concept in Java, aesthetically speaking. The Group Communications stack can simply be specified by literally stacking micro-protocols into a group communications stack -- each micro-protocol can be considered a micro-kernel with its own "up" and "down" threading system."

We're working through some server problems with the Forums, and they may be intermittently unavailable as we work with Jive to fix the issues. We apologize for any inconvenience. Among recent interesting messages, LWUIT user mrjansa reports success Re: Painting an image on a form "I solved the problem by putting the drawImage()in a Painter and then adding the painter to the form the following way: this.getContentPane().getStyle().setBgPainter(painter); The reason why I want to put the image in a paint method is that I want to draw other things on the image."

mikephoenix explains a configuration and deployment issue in Re: deploying into production web services developed on NB 6. "OK, I figured out what happened. Here's the scoop for other newbies. When you deploy and undeploy you can run tests and see the WSDL on your local application server. In order to port the application to remote application server, you actually need to do a build to properly create the .war file. I was under the implession that deploy and undeploy also did the build automatically. This is not the case. Once I did the build which properly created the .war file, I was able to move it to the production server and access the services and WSDL on my remote app server."

rfagalde has some concerns to work through, in Re: How to build?? "I have three questions: 1# My application run in Symbian(E61i), accessing the JBOSS using Web Services, but it don't run in windows mobile, and returns NoClassDefFoundError only in the class that contains Web Service's call(new WS4JMEPortType_Stub()). 2# I'd like to confirm that the library phoneME Feature M3 used with cyg4me, will rebuild my application with JSR-172 support, and not conflicting with windows Mobile. 3# What variables are wrong when I use command "make -C..." to rebuild?"

Finally, jodeen complains of some Issues getting Fast Infoset working. "I'm having some issues getting Fast Infoset working in general. I'm assuming that there's something simple missing. Everything I've found on the web implies that setting up FI should be as simple as setting a property on my client-side stub (http://www.j2ee.me/webservices/docs/2.0/jaxrpc/fastinfoset/manual.html). But that doesn't seem to be working. When I use wsmonitor to look at the messages being sent, the requests don't have the application/fastinfoset in the HTTP accept header."

Current and upcoming Java Events :

Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.

Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.



Overhauling OpenJDK's FontManager
»
Comments
Comments are listed in date ascending order (oldest first)




 

Feedback  | FAQ  | Terms of Use
Privacy  |  Trademarks | Site Map
 
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
 
Copyright © 1995-2008 Sun Microsystems, Inc.
Collabnet Logo Cognisync Communities
Powered by Sun Microsystems, Inc.,
CollabNet and Cognisync