4.1における新機能と注目すべき変更点

このドキュメントでは、Netty 4.1と4.0の間の注目すべき変更点と新機能の一覧について説明します。

4.0との後方互換性を維持するために最善を尽くしましたが、4.1には4.0と完全な後方互換性がない可能性のある複数の追加が含まれています。新しいバージョンに対してアプリケーションを再コンパイルしてください。

アプリケーションを再コンパイルすると、非推奨の警告が表示される場合があります。次のバージョンにアップグレードする際に問題が発生しないように、提案されている代替手段を使用してすべて修正してください。

以下の点を考慮して、

• モバイルデバイスがますます強力になっていること、
• ADKのNIOとSSLEngineに関する既知の問題のほとんどがIce Cream Sandwich以降で修正されていること、そして
• ユーザーがモバイルアプリケーションでコーデックとハンドラーを再利用したいと考えていることは明らかであるため、

Android（4.0以上）を公式にサポートすることにしました。

ただし、Android用の自動テストスイートはまだありません。 Androidで問題が発生した場合は、お気軽に問題を報告してください。また、Androidテストをビルドプロセスの一部にするために、プロジェクトに貢献することを検討してください。

ChannelとChannelHandlerContextはどちらも、ユーザーが1つ以上のユーザー定義属性をアタッチできるようにするために、AttributeMapインターフェースを実装しています。ユーザーを混乱させることがあったのは、ChannelとChannelHandlerContextがユーザー定義属性用に独自のストレージを持っていたことです。たとえば、Channel.attr(KEY_X).set(valueX)を介して属性 'KEY_X'を設定しても、ChannelHandlerContext.attr(KEY_X).get()を介して見つけることはできず、逆もまた同様です。この動作は混乱を招くだけでなく、メモリの無駄遣いでもあります。

この問題に対処するために、Channelごとに1つのマップのみを内部に保持することにしました。 AttributeMapは常にAttributeKeyをキーとして使用します。 AttributeKeyは各キー間の一意性を保証するため、Channelごとに複数の属性マップを持つ意味はありません。ユーザーが独自のAttributeKeyをChannelHandlerのプライベート静的最終フィールドとして定義する限り、キーが重複するリスクはありません。

属性が存在するかどうかを効率的に確認できるようになりました。

以前は、バッファリークが発生した場所を見つけるのが容易ではなく、リークの警告はあまり役に立ちませんでした。現在、オーバーヘッドの増加を犠牲にして有効にすることができる高度なリーク報告メカニズムがあります。

詳細については、参照カウントオブジェクトを参照してください。この機能は、その重要性から4.0.14.Finalにもバックポートされています。

4.xでは、UnpooledByteBufAllocatorはその制限にもかかわらずデフォルトのアロケーターでした。 PooledByteBufAllocatorがしばらくの間使用されており、高度なバッファリーク追跡メカニズムが導入されたため、新しいデフォルトにする時期が来ました。

すべてのChannelは、以下から生成されるグローバルに一意のIDを持つようになりました。

• MACアドレス（EUI-48またはEUI-64）、できればグローバルに一意のもの、
• 現在のプロセスID、
• System#currentTimeMillis()
• System#nanoTime()
• ランダムな32ビット整数、および
• シーケンシャルにインクリメントされる32ビット整数。

ChannelのIDは、Channel.id()メソッドを使用して取得できます。

EmbeddedChannelのreadInbound()とreadOutbound()は、アドホック型パラメータを返すため、戻り値をダウンキャストする必要はありません。これにより、ユニットテストコードの冗長性がかなり軽減されます。

EmbeddedChannel ch = ...;

// BEFORE:
FullHttpRequest req = (FullHttpRequest) ch.readInbound();

// AFTER:
FullHttpRequest req = ch.readInbound();

一部のアプリケーションでは、ユーザーが指定されたExecutorでタスクを実行する必要があります。 4.xでは、イベントループを作成するときにThreadFactoryを指定する必要がありましたが、今は必要ありません。

この変更の詳細については、プルリクエスト＃1762を参照してください。

AttributeKeyなどの一部のタイプは、コンテナ環境で実行されるアプリケーションにとって不親切でしたが、今はそうではありません。

拡張されたByteBufの新しい容量を計算するロジックは、AbstractByteBufからByteBufAllocatorに移動されました。これは、ByteBufAllocatorが管理するバッファの容量計算をよりよく理解しているためです。

• バイナリmemcacheプロトコルコーデック
• 圧縮コーデック
  • BZip2
  • FastLZ
  • LZ4
  • LZF
• DNSプロトコルコーデック
• HAProxyプロトコルコーデック
• MQTTプロトコルコーデック
• SPDY / 3.1のサポート
• STOMPコーデック
• バージョン4、4a、および5をサポートするSOCKSxコーデック。 socksxパッケージを参照してください。
• XMLドキュメントのストリーミングを可能にするXmlFrameDecoder。
• JSONオブジェクトのストリーミングを可能にするJsonObjectDecoder。
• IPフィルタリングハンドラー

AsciiStringは、1バイト文字のみを含む新しいCharSequence実装です。 US-ASCIIまたはISO-8859-1文字列を扱う場合に、このクラスが役立ちます。

たとえば、NettyのHTTPコーデックとSTOMPコーデックは、ヘッダー名を表すためにAsciiStringを使用します。 AsciiStringはByteBufにエンコードするときに変換コストがかからないため、Stringを使用するよりも優れたパフォーマンスが保証されます。

TextHeadersは、HTTPヘッダーのような文字列マルチマップの汎用データ構造を提供します。 HttpHeadersもTextHeadersを使用して書き直されました。

MessageAggregatorは、HttpObjectAggregatorと同様に、複数の小さなメッセージを大きなメッセージに集約する汎用機能を提供します。 HttpObjectAggregatorもMessageAggregatorを使用して書き直されました。

4.0では、100-continueヘッダーが存在する場合でも、クライアントがコンテンツを送信する前に oversized なHTTPメッセージを拒否する方法はありませんでした。

このリリースでは、handleOversizedMessageと呼ばれるオーバーライド可能なメソッドが追加され、ユーザーが好みのタスクを実行できるようになりました。デフォルトでは、「413 Request Entity Too Large」レスポンスで応答し、接続を閉じます。

ChunkedInputには、転送の進行状況とストリームの全長をそれぞれ返す2つの新しいメソッド、progress()とlength()があります。 ChunkedWriteHandlerはこの情報を使用してChannelProgressiveFutureListenerに通知します。

これら2つのクラスの名前がSnappyFrameEncoderとSnappyFrameDecoderに変更されました。古いクラスは非推奨としてマークされており、実際には新しいクラスのサブクラスです。