java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O-release, 1.3beta-O-release,
interpreted mode)

When no java.awt.fonts property is defined, initializing the
sun.java2d.SunGraphicsEnvironment calls a native method that builds a
font path by scanning the whole /var/sadm/install/contents file for directories
containg .ttf, .pfa or .pfb files.  The /var/sadm/install/contents pkg database
file can get quite large (5.5mbyte on this system with a full solaris 7
installation + the workshop 6 EA release).  Obviously this increases the memory
footprint during startup of a gui java application by the size of the pkg
database file /var/sadm/install/contents.  In the worst case - when the pkg
database file is not cached in main memory - this could add ~ a second to the
startup time of a java application (assuming a disk/filesystem that is capable
of reading files at 5mbyte/sec).  In the best case - when the file is completely
cached in main memory already - it still adds one or two  tenth of a second to
the startup time of the awt.

Since the pkg database file typically doesn't change very often (only when
a new software package or a patch is installed/uninstalled by the administrator)
time can be saved and the memory footprint can be reduced during startup the
AWT by caching the fontpath result determined by scanning the
/var/sadm/install/contents file beween invocations of the jvm.


The suggested solution caches the fontpath in the file
$HOME/.java-awt-fonts-<hostname>   On a subsequent run of a java gui application
the cached fontpath is used instead of scanning the /var/sadm/install/contents
file.  When the pkg database changes because some software was added/removed to
the system, the fontpath cache file is automatically rebuilt.

//Test Case
import java.awt.*;

public class fnt2 {

    public static void main(String[] args) {
        new Font("monospaced", Font.ITALIC, 12);
        System.exit(0);
    }
}


Run "ptime java fnt2" with and without the suggested solution.
(Review ID: 101185) 
suggested_val: 
see attachment for users fix.
  xxxxx@xxxxx    2000-03-14

======================================================================

N/A

Some code changes and the use of an "appendedfontpath" key in the 
font.properties file allows a "hardwiring" of the location of the fonts needed
for start-up and resolving of font.properties specified logical fonts.
Thus the full search is deferred  and occurs only if there is no
appendedfontpath, or the application invokes (either directly or indirectly)
a GraphicsEnvironment.getAllFonts() call. The benefit to start-up tine is
significant (perhaps 25% for a minimal GUI app).
The benefits can be extended to other locales by ediiing their appropriate
font.properties files.

  xxxxx@xxxxx   2002-10-04
============================