JDK-4511971 : RFE: create Font directly from File: java.awt.Font.create(int fontFormat, File)
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2001-10-08
  • Updated: 2003-04-08
  • Resolved: 2003-04-08
Related Reports
Duplicate :  
Description

Name: bsT130419			Date: 10/08/2001


java version "1.4.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta2-b77)
Java HotSpot(TM) Client VM (build 1.4.0-beta2-b77, mixed mode)


java.awt.Font has the following method:
static Font createFont(int fontFormat, InputStream fontStream)

If the font is packed in a JAR, this is a convenient signature.
However, often a font exists as a file, or one can cache the font as a file
(i.e., would cache if advantageous).

In the current implementation, createFont(InputStream) always fully reads the
InputStream to create a File.  If the font already exists as a file, a new
createFont(int fontFormat, File) method would be:
* slightly more convenient in this case
* much more efficient - vs creating a new file when a file already exists.
I have two applications that need to create many fonts fast, so speed is
important.
* trivial to implement - just a method definition line and a call from
near the end of the existing createFont to the new one
* free of a temporary file, which requires write permission,
and needs to be deleted later, which has led to a bug.

The disadvantage would be an increase in the size of the API by one method.
(Review ID: 133277) 
======================================================================

Comments
WORK AROUND Name: bsT130419 Date: 10/08/2001 Font.createFont(new FileInputStream(File)) ======================================================================
11-06-2004

EVALUATION Font issues are typically handled by 2D. ###@###.### 2001-10-08 =============================== The API that is currently implemented used InputStream as it was most flexible and no file permissions were needed (the requirement to have permission to write to a temp file was an implementation bug that was fixed). The primary benefit of implementing this new RFE is that there would be no need to copy the font for this case. However it would need some work in the implementation layer which presently assumes that font files do not disappear. The implementation does not hold an open handle to all font files as the JRE would run out of file descriptors very quickly. Just because Java code has a reference to a font based on this underlying file does not mean that file is held open. So if the application removed the font while Java references to the Font were still live then there would be some way to fall back to some other font and application behaviour would be undefined. These complexities are also part of the reason for the current implementation making a copy of the font. Since new APIs can't be considered anyway until the next API release then we will defer deciding whether this is something that can be made workable until that release. ###@###.### 2002-02-07 ============================ We are addressing this under RFE 4468862 ###@###.### 2003-04-07 ===========================
07-02-2002