GWT RPC メカニズムを介して、クライアントからサーバーにオブジェクト ID を送受信しています。ID は、Long (8 バイト) としてデータストアから出力されます。私のIDはすべて4バイトしか必要ないと思いますが、5バイト（またはその他）の値を与えるランダムなことが起こる可能性があります。
GWT は、平均してスペースを節約する可変長エンコーディングでこれらの値をパックすることについて賢明になるでしょうか? どこかでそうするように指定できますか？それとも、Long を int にコピーして例外的な状況に注意する独自のコードを作成する必要がありますか?
ありがとう〜
GWT のドキュメントに記載されているとおりです。
long : JavaScript には 64 ビット整数型がないため、 long には特別な考慮が必要です。GWT 1.5 より前では、long 型は単純に 64 ビット JavaScript 浮動小数点値の整数範囲にマップされ、long 変数に完全な 64 ビットよりも小さい実際の範囲を与えていました。GWT 1.5 では、long プリミティブは 32 ビット整数のペアとしてエミュレートされ、64 ビット範囲全体で確実に動作します。予想される動作に一致するように、オーバーフローがエミュレートされます。いくつかの注意事項があります。長い操作を頻繁に使用すると、基礎となるエミュレーションが原因でパフォーマンスに影響を与えます。さらに、長いプリミティブは JavaScript のネイティブな数値型ではないため、JSNI コードでは使用できません。
ID が Integer に収まる場合は、そのほうがよいでしょう。それ以外の場合は、DTO を使用している場合は、ID を実際に Javascript に存在する double にします。
GWT は、ペイロードが 256 バイト以上の応答に対して gzip 圧縮を使用します。応答にゼロバイトがたくさんある場合、これはうまくいくはずです。
からRemoteServiceServlet.shouldCompressResponse:
特定のサーブレット リクエストへの応答を GZIP 圧縮する必要があるかどうかを決定します。このメソッドは、リクエスターが GZIP エンコーディングを受け入れる場合にのみ呼び出されます。
この実装は現在、応答文字列の推定バイト長が 256 バイトより長い場合に true を返します。サブクラスは、このロジックをオーバーライドできます。
そのため、サーバーは最初にリクエスター (通常はブラウザー) が GZIP エンコーディングを受け入れるかどうかを確認します。内部的にjava.util.zip.GZIPOutputStream使用されます - を参照してくださいRPCServerUtils。クライアント側では、gzip されたペイロードを解凍するのはブラウザーの仕事です。これはネイティブ コードで行われるため、かなり迅速に行われます。