2009-11-17 8 views
7

Der folgende Code funktioniert, hinterlässt jedoch bei jeder Ausführung Kopien der Schriftartdatei im temporären Verzeichnis. Diese Dateien heißen + ~ JF7154903081130224445.tmp, wobei die Nummer für jede erstellte Datei zufällig erscheint.Font.createFont hinterlässt Dateien im temporären Verzeichnis

InputStream fontStream = this.getClass().getResourceAsStream("handsean.ttf"); 
Font baseFont = Font.createFont(Font.TRUETYPE_FONT, fontStream); 
fontStream.close(); 

Ich habe festgestellt Jahre alte Diskussionen in Foren auf sun.com und andere Ressourcen im Internet, wo dies als Fehler in JDK erkannt wird, wo von 1.5.0_06 auf 1.5.0_08 aktualisieren das Problem lösen würde ; Die Version, die ich verwende, ist jedoch eine spätere Version (1.6.0_13).

Ich habe versucht, das Problem zu lösen, indem Sie die Dateien löschen, nachdem die Schriftarten-Operationen abgeschlossen sind, aber die Dateien sind zu diesem Zeitpunkt gesperrt. Die Dateien können nur gelöscht werden, nachdem die Webanwendung beendet wurde.

Hat jemand eine Lösung dafür?

Antwort

1

Wenn Ihr ttf-Dateien nicht in einem Archiv sind, können Sie Create (File) aufrufen, statt Create (Input)

In Bezug auf die nach meinem besten Wissen, dieser Fehler in Java existiert 6, es ist genug, um Sehen Sie sich die Quellen der Font-Klasse an.

+0

Ein guter Vorschlag, sich die Quellen anzusehen, sieht mit createFont (File) vielversprechend aus, da es keine temporäre Datei verwendet. Werde es versuchen und dich wissen lassen. –

+0

Ich habe den Code geändert, um createFont (File) aufzurufen, wodurch verhindert wurde, dass temporäre Dateien überhaupt erstellt wurden. –

1

Mit JDK1.6.0_16 scheint der Font-Manager die temporäre Datei als eine Art Cache zu verwenden und liest Glyphen nur dann aus der Schriftart, wenn sie benötigt werden. Es fügt auch einen Shutdown-Hook hinzu, der die Datei löscht, wenn die JVM normalerweise beendet wird. Abhängig von der VM wird das Font-Rendering möglicherweise auch an nativen Code delegiert, der Zugriff auf die Datei benötigt. Daher scheint es mir sinnvoll, die Datei zu sperren.

Werden die Dateien tatsächlich beibehalten, selbst wenn Ihr Servlet-Container (Sie erwähnen eine Webanwendung) regelmäßig beendet wird oder Sie ihn löschen, ohne ihm zu erlauben, seine Ressourcen ordnungsgemäß zu bereinigen?

+0

Ja, die Dateien werden auch nach der normalen Beendigung behalten. –

+0

Es tut mir leid, aber ich kann Ihr Problem mit 1.6.0_13 auch nicht reproduzieren. Die Schriftartdateien werden tatsächlich beibehalten und gesperrt, aber ein Shutdown-Hook wird zum Löschen der Datei verwendet. Machst du etwas anderes, um das Ausführen von Shutdown-Hooks zu verhindern, oder kannst du es mit einem Remote-Debugger anhängen und wirklich bestätigen, dass der sun.font.FontManager.fileCloser-Hook wirklich nicht ausgeführt wird? Theoretisch kann die Delete-Invokation in Zeile 2302 automatisch fehlschlagen, wenn etwas anderes die Datei offen hält (nativer Code?). – jarnbjo

+0

Danke, dass Sie sich die Zeit genommen haben, mein Problem zu reproduzieren. Wenn man berücksichtigt, dass man es nicht reproduzieren kann, könnte es mit meiner Umgebung zusammenhängen. Ich entwickle auf Tomcat, der in XP läuft, und das Testen mit dem Markieren anderer Dateien mit deleteOnExit zeigt, dass der Prozess wahrscheinlich nie auf eine Weise beendet wird, die das Bereinigen erlaubt, weil diese Dateien ebenso behalten werden. –