Font.createFont оставляет файлы во временном каталоге

Приведенный ниже код выполняет свою работу, но при каждом запуске оставляет копии файла шрифта во временном каталоге. Эти файлы называются +~JF7154903081130224445.tmp, где число кажется случайным для каждого созданного файла.

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

Я нашел многолетние обсуждения на форумах на sun.com и других ресурсах в Интернете, где это распознается как ошибка в JDK, где обновление с 1.5.0_06 до 1.5.0_08 решит проблему; однако я использую более позднюю версию (1.6.0_13).

Я попытался решить проблему, удалив файлы после завершения операций, связанных со шрифтами, но в это время файлы были заблокированы. Файлы можно удалить только после остановки веб-приложения.

У кого-нибудь есть решение для этого?


java fonts temporary-files graphics2d
person Community    schedule 17.11.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Если ваши файлы ttf не находятся в архиве, вы можете вызвать createFont(File) вместо createFont(InputStream)

Насколько мне известно, эта ошибка существует в Java 6, достаточно посмотреть исходники класса Font.

person Dmitry    schedule 17.11.2009
comment
Хорошее предложение посмотреть исходники, использование createFont(File) выглядит многообещающе, так как не использует временный файл. Попробую это и дам вам знать. - person ; 18.11.2009
comment
Я изменил код для вызова createFont(File), что вообще предотвратило создание временных файлов. - person ; 19.11.2009

arrow_upward
1
arrow_downward

В JDK1.6.0_16 диспетчер шрифтов, похоже, использует временный файл в качестве своего рода кеша и будет считывать глифы из шрифта только тогда, когда они требуются. Он также добавляет ловушку отключения, которая удалит файл, когда JVM завершит работу в обычном режиме. В зависимости от виртуальной машины рендеринг шрифтов, возможно, также делегируется собственному коду, которому требуется доступ к файлу, поэтому сохранение блокировки файла кажется мне разумным.

Сохраняются ли файлы на самом деле, даже если ваш контейнер сервлета (вы упоминаете веб-приложение) регулярно завершает работу, или вы убиваете его, не позволяя ему должным образом очищать свои ресурсы?

person jarnbjo    schedule 17.11.2009
comment
Да, файлы также сохраняются после нормального завершения. - person ; 18.11.2009
comment
Извините, но я также не могу воспроизвести вашу проблему с 1.6.0_13. Файлы шрифтов действительно сохраняются и блокируются, но для удаления файла используется ловушка отключения. Вы делаете что-то еще, чтобы предотвратить запуск обработчиков завершения работы, или вы можете подключиться с помощью удаленного отладчика и действительно подтвердить, что обработчик sun.font.FontManager.fileCloser действительно не запущен? Теоретически, вызов удаления в строке 2302 может молча завершиться ошибкой, если что-то еще удерживает файл открытым (собственный код?). - person jarnbjo; 18.11.2009
comment
Спасибо, что нашли время, чтобы попытаться воспроизвести мою проблему. Учитывая, что вы не смогли воспроизвести его, это может быть связано с моей средой. Я разрабатываю на tomcat, работающем в XP, и тестирование с маркировкой других файлов с помощью deleteOnExit показывает, что процесс, вероятно, никогда не завершается таким образом, чтобы можно было выполнить очистку, поскольку эти файлы также сохраняются. - person ; 18.11.2009