Почему нет javafx.scene.text.Font Serializable?

Question

Старый java.awt.Font удобно Serializable - однако несколько досадно, JavaFX font class нет. Еще более раздражающе, это неудобно сериализовать вручную, поскольку объекты FontPosture и FontWeight, указанные в конструкторе, не доступны после строительства (вместо этого нужно прибегать к вызову и разбору getStyle().) Я изо всех сил пытаюсь понять, почему это так, на по крайней мере, на поверхности я, конечно, не вижу никакой функциональности, присутствующей на шрифте JavaFX, отсутствующего на шрифте AWT, который будет неудобным для сериализации.

Есть ли какая-либо техническая причина, почему это так, что мне не хватает, или это аномалия API, которая может быть исправлена ​​в будущем выпуске?

Answer 1

Очень мало вещи в JavaFX сериализуются. Вы можете узнать все, что сериализуется, просмотрев страницу serialized-form javadoc. При этом вы можете видеть, что в значительной степени единственными вещами, которые могут быть сериализованы, являются события, основанные на старом сериализуемом java.util.EventObject и JFXPanel, который интегрируется с Swing. Все остальное не является сериализуемым. Таким образом, для шрифтов Font было бы совершенно нетипичным, если почти ничего не было.

Сам JavaFX в значительной степени опирается на механизм динамических свойств и связанные с ним привязки и изменение прослушивателей. Сама базовая система свойств (в настоящее время) не сериализуема, так что это одна из причин, почему JavaFX не имеет в себе много сериализации.

Это говорит о том, что объект Font встречается редко в JavaFX в том смысле, что он кажется неизменным, с предоставленными только конструкторами и методами геттера и без использования свойств. Поэтому теоретически можно было бы сделать сериализуемым довольно легко. Вы можете указать feature request, предлагая это. Его можно рассматривать как низкий приоритет, хотя сам JavaFX не очень сильно полагается на сериализацию. Сериализационный подход в реализации JavaFX, по-видимому, не сериализуется, если только не требуется интегрироваться с существующими apis или фреймами.

Если у вас есть дополнительные вопросы о сериализации в JavaFX, и аргументация, лежащая в основе структуры, не использующей ее много, вы можете задать вопрос по адресу openjfx-dev mailing list.Мое предположение (похоже на предупреждение Nick в его ответе), что было принято решение о том, что полная поддержка сериализации в рамках была плохой идеей по многим причинам, поэтому было преднамеренное решение не поддерживать ее (но это всего лишь предположение).

Answer 2

Я подозреваю, что это связано с сериализуемыми классами, которые обычно не совместимы между версиями. Если приложение полагается на пользовательский интерфейс, который может быть сериализуемым, у вас могут возникнуть серьезные проблемы между выпусками. Вы можете увидеть warning on swing components об использовании сериализации.

Предупреждение. Сериализованные объекты данного класса не будут совместимы с будущими версиями Swing. Текущая поддержка сериализации подходит для краткосрочного хранения или RMI между приложениями, использующими ту же версию Swing. Начиная с версии 1.4, в пакет java.beans добавлена ​​поддержка долгосрочного хранения всех JavaBeansTM. См. XMLEncoder.

При этом я также выскажу свое мнение. Для меня это связано с разделением MVC на сериализацию пользовательского интерфейса. Конечно, есть и другие архитектуры - MVC - не золотая пуля. Кажется более простым поставить вещи, о которых вы заботитесь в отдельном объекте; Вы уже написали код для выполнения пользовательского интерфейса - если есть определенные координаты x/y, в которых он должен быть, или объект должен быть сфокусирован на загрузке, имеет смысл просто сохранить эту информацию вместо каждого цвета по умолчанию, слушателя , скин, связанный с узлом.

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