Autoboxing could be very useful for some TextAttribute APIs, but since the current TextAttribute spec is too restrictive about the types some TextAttributes accept, autoboxing actually causes problems instead of being a convenience. Consider the following code:

import static java.awt.font.TextAttribute.*;
[...]
Map m = new HashMap(0);
m.put(FAMILY, "Lucida Sans");
m.put(SIZE, 18);
m.put(TRACKING, 1.2);
Font f = Font.getFont(m);

One might reasonably expect to get an 18 point Lucida Sans font with slightly loose tracking. But one would be mistaken...

Autoboxing will promote the native types to their corresponding Java objects. In this case, the size value, 18, becomes Integer(18), and the tracking value, 1.2, becomes Double(1.2). The TextAttribute spec currently requires that the values for SIZE and TRACKING be instances of Float, otherwise the attributes will be ignored. Thus one actually ends up with a 12 point Lucida Sans font with no tracking.

There is no good reason to impose such a strict requirement on the type of the value for these attributes. Float's supertype Number will work just as well, and will handle these cases appropriately.

All TextAttributes that currently require their value types to be Float should loosen the restriction to take Number instead. This will avoid user confusion, and enable clean use of autoboxing in a situation that is otherwise perfectly suited to it. It is compatible with existing uses of Float.
###@###.### 2005-06-16 16:54:58 GMT