Как я удаляю типы реализации из политики Сериализации GWT?
Противоположность этого вопроса: Как я добавляю тип к белому списку политики Сериализации GWT?
GWT добавляет нежелательные типы к политике сериализации и чрезмерно увеличивает размер моего JS. Как я обрезаю свой белый список GWT вручную? Или должен я вообще?
Например, если бы я поместил интерфейс List на класс обслуживания RPC GWT, то GWT должен генерировать JavaScript, который обрабатывает ArrayList, LinkedList, Стек, Вектор... даже при том, что моя команда знает, что мы только когда-либо собираемся возвратить ArrayList. Я мог просто заставить возврат метода ввести ArrayList, но мне нравится полагаться на интерфейс, а не определенную реализацию. В конце концов, возможно, однажды мы переключим его и возвратимся, например, LinkedList. В этом случае я хотел бы вызвать политику сериализации GWT скомпилировать только для ArrayList и LinkedList. Никакие Стеки или Векторы.
Эти неявные ограничения имеют одну огромную оборотную сторону, о которой я могу думать: новый член команды начинает возвращать Векторы, которые будут ошибкой периода выполнения. Таким образом помимо вопроса в заголовке, что Ваш опыт разрабатывает на основе этого?
2 ответа
Существует свойство, которое может вносить этот класс в черный список. Например, чтобы внести в черный список коллекции, не входящие в список ArrayList, добавьте эти строки в свой * .gwt.xml:
<extend-configuration-property name="rpc.blacklist" value="java.util.HashSet"/>
<extend-configuration-property name="rpc.blacklist" value="java.util.LinkedHashSet"/>
<extend-configuration-property name="rpc.blacklist" value="java.util.LinkedList"/>
<extend-configuration-property name="rpc.blacklist" value="java.util.Stack"/>
<extend-configuration-property name="rpc.blacklist" value="java.util.TreeMap"/>
<extend-configuration-property name="rpc.blacklist" value="java.util.TreeSet"/>
<extend-configuration-property name="rpc.blacklist" value="java.util.Vector"/>
Это было необходимо для меня, чтобы уменьшить размер JS при отправке встроенного в GWT com.google.gwt.user. client.ui.SuggestOracle $ Response по сети. Такие объекты содержат java.util.Collection, но я знал, что отправлю обратно только ArrayList.
Я по-прежнему уважаю преимущества проверок во время компиляции, о которых говорилось в других ответах, комментариях и моем первоначальном вопросе. В самом деле, это ненадежное решение, если GWT начинает собирать дополнительные реализации для сериализации (почему это не белый список?). Однако это свойство "rpc.blacklist" спасло меня от использования моего собственного SuggestOracle только для того, чтобы получить более конкретный тип коллекции.
Хотя ни один хороший фреймворк не должен пытаться изменить своих пользователей, позвольте мне попытаться объяснить, почему сериализация GWT работает именно так. Я не знаю точной механики этого, поэтому могу ошибаться, но это суть того, что я видел.
GWT уже удаляет лишний код вне интерфейсов RPC - например, если вы берете приложение без RPC, вы можете свободно использовать такие интерфейсы, как List и Map и Set, как вам нравится - GWT автоматически включит только реализации который вы на самом деле используете. Почему? Потому что у него есть доступ к вашему коду и он способен фактически проходить через все видимые изменения кода и сокращать неиспользуемые классы. Таким образом, GWT на самом деле не создает взрывы классов при использовании интерфейсов.
Проблема полностью в RPC. Суть службы RPC заключается в том, что серверу необходимо реализовать интерфейс RPC - это означает, что если интерфейс диктует, что метод должен возвращать список, сервер может возвращать любую реализацию списка, который он хочет, до тех пор, пока как его можно сериализовать.
Вот в чем проблема - GWT не имеет абсолютно никакого способа узнать, какую реализацию интерфейса будет использовать сервер, ни во время компиляции, ни в какой-то момент в будущем. Код сервера может и во многих случаях будет разрабатываться независимо от кода на стороне клиента. Таким образом, единственный способ безопасно получить объект типа List по сети - это заранее знать обо всех возможных его реализациях.