Эффективно ли GWT сериализует java.lang.Longs?

Question

Я отправляю идентификаторы объектов от клиента к серверу через механизм GWT RPC.Идентификаторы выходят из хранилища данных как длинные (8 байт).Я думаю, что все мои идентификаторы будут нуждаться только в 4 байтах, но может произойти что-то случайное , которое даст мне 5-байтовое (или любое другое) значение.эти значения в некоторой кодировке переменной длины, которая сэкономит место в среднем?Могу ли я указать, что это где-то так?Или я должен написать свой собственный код, чтобы копировать Longs в целые и следить за этими исключительными ситуациями?

Спасибо ~

Answer 1

Как указано в документации GWT .

long : JavaScript не имеет 64-битного целочисленного типа, поэтому long требует особого рассмотрения. До GWT 1.5 тип long был просто сопоставлен с целочисленным диапазоном 64-битного значения JavaScript с плавающей точкой, давая длинным переменным фактический диапазон, меньший, чем полные 64 бита. Начиная с GWT 1.5, длинные примитивы эмулируются как пара 32-битных целых и надежно работают во всем 64-битном диапазоне. Переполнение эмулируется для соответствия ожидаемому поведению. Есть несколько предостережений. Интенсивное использование длинных операций будет влиять на производительность из-за базовой эмуляции. Кроме того, длинные примитивы нельзя использовать в коде JSNI, поскольку они не являются собственным числовым типом JavaScript.

Если ваши идентификаторы могут вписаться в целое число, вам будет лучше с этим. В противном случае, если вы используете DTO, сделайте идентификаторы двойными, что на самом деле существует в Javascript.

Answer 2

GWT использует сжатие gzip для ответов с полезной нагрузкой 256 байтов или более. Это должно хорошо работать, если в вашем ответе много нулевых байтов.

С RemoteServiceServlet.shouldCompressResponse:

Определяет, является ли ответ на данный запрос сервлета должен или должен не быть сжатым GZIP. Этот метод вызывается только в тех случаях, когда запрашивающая сторона принимает кодировку GZIP.

Эта реализация в настоящее время возвращает истина, если строка ответа расчетная длина байта больше, чем 256 байтов. Подклассы могут переопределить это логика.

Итак, сервер сначала проверяет, принимает ли запрашивающая сторона (обычно браузер) кодировку GZIP. Внутри используется java.util.zip.GZIPOutputStream - см. RPCServerUtils. На стороне клиента браузер распаковывает полезную нагрузку gzipped - поскольку это делается в нативном коде, оно должно быть довольно быстрым.