Michael Nascimento Santos's Blog

March 2005 Archives

First draft for Common Annotations is out

The first early draft for JSR-250, Common Annotations for the Java Platform, has been published. There are less than 10 annotations specified in this version, most of them related to security.

Although many other annotations will probably be added for the next versions, as part of the expert group I would like to request your feedback. Download the early draft and send us your comments. The best time to change a spec is at its early stages. Don't miss this opportunity.

UPDATE: please send your feedback to jsr-250-comments@jcp.org instead of posting a comment to this entry. Thanks!

A tricky issue with java.awt.Font

If your code or code you use relies on loading fonts by name, you may face severe limitations when trying to use your application in a different environment than the one you performed your tests. Although many of us are aware of the fact specific fonts may not be installed on a machine, trying to work around this problem may prove to be more difficult as it seems at first.

Most code that loads fonts by name use either the getFont(String name) or the getFont(String name, Font defaultFont) method from the java.awt.Font class. What happens when there is no font registered in the OS whose name is name? In the first case, null is returned; for the second method, the defaultFont parameter is returned. This will probably lead to unexpected results. Even when the font exists in the OS, it may not be the same font you were expecting. Yes, that is right: there are different font files for "common" fonts. So, how can you load a specific font and make sure the one you expect will be used to render text?

The Font API allows you to programatically load a font from a java.io.InputStream using the createFont(int fontFormat, InputStream fontStream) method. Although the only font format supported is Font.TRUETYPE_FONT, this should be enough for most situations, since if you are not using a TrueType font, there is no guarantee it will render the same in different platforms and/or devices. Unfortunately, there is a problem that prevents this solution from working most of the times: there is no way to associate a loaded font with a name. This is somewhat surprising, since the loaded instance even returns the correct name when its getName() method is called.

So, how to solve this problem? If you wrote the code or can modify its source, you simply need to rewrite the parts that load a font by name so that they delegate to a method that looks up the instance in a "registry", such as a Map. The problem gets worse, though, when you are working with third-party software. If you can modify the binaries in runtime, using AOP to work around this problem is a possible solution. However, sometimes the third-party license prohibits this kind of modification and then there isn't much the developer can do besides asking the vendor to rewrite the API.

The long term fix for this issue would be to add a register(String name, Font font) method to Font in Mustang. Should I propose an enhancement about this? I would like to know what you think.

The JCP EC (and the community) did the right thing: JDO 2.0 approved

I have to say I'm really happy. As I woke up today, and visited the results

What is really interesting about it is this vote is not only the result of all efforts made by the JSR 243 EG - which certainly made a difference -, but also is due to the "noise" made by the community. Many people said they had previous investments on JDO, couldn't wait for a spec (JSR 220, EJB 3.0) that wouldn't be available for a long time, wouldn't trust the JCP itself if it rejected a spec that complied to its original request etc., and it seems these claims had a positive effect on the decision after all.

So, what is the point of this entry? Make noise! :-) Express your concerns about JSRs and the evolution of the platform, join the JCP, nominate yourself as an expert to JSRs you are interested in, do something! It does matter.

This work is licensed under a Creative Commons License.