カスタム変換

次の Spring Converter 実装の例は、String からカスタム Email 値オブジェクトに変換します。

@ReadingConverter
public class EmailReadConverter implements Converter<String, Email> {

  public Email convert(String source) {
    return Email.valueOf(source);
  }
}

ソースとターゲットの型がネイティブ型である Converter を記述した場合、それを読み取りコンバーターと見なすか、書き込みコンバーターと見なすべきかを判断できません。コンバーターインスタンスを両方として登録すると、望ましくない結果が生じる可能性があります。例: Converter<String, Long> があいまいですが、書き込み時にすべての String インスタンスを Long インスタンスに変換しようとしても意味がありません。インフラストラクチャーにコンバーターを一方向にのみ登録させるために、コンバーターの実装で使用される @ReadingConverter および @WritingConverter アノテーションを提供します。

インスタンスはクラスパスまたはコンテナースキャンから取得されないため、コンバーターは明示的な登録の対象となります。変換サービスへの不要な登録と、そのような登録に起因する副作用を回避するためです。コンバーターは、ソースおよびターゲットの型に基づいて、登録されたコンバーターの登録および照会を可能にする中央機能として CustomConversions に登録されます。

CustomConversions には、事前に定義された一連のコンバーター登録が付属しています。

  • java.time、java.util.Date、String 型間の変換用の JSR-310 コンバーター。

ローカルテンポラル型（LocalDateTime から java.util.Date など）のデフォルトコンバーターは、システムデフォルトのタイムゾーン設定に依存して、これらの型間で変換します。独自のコンバーターを登録することにより、デフォルトのコンバーターをオーバーライドできます。

コンバーターの明確化

一般に、Converter の実装は、変換元と変換先のソース型とターゲット型をインスペクションします。これらの 1 つが、基になるデータアクセス API がネイティブに処理できる型かどうかに応じて、コンバーターインスタンスを読み取りまたは書き込みコンバーターとして登録します。次の例は、書き込みコンバーターと読み取りコンバーターを示しています（違いは Converter の修飾子の順序にあることに注意してください）。

// Write converter as only the target type is one that can be handled natively
class MyConverter implements Converter<Person, String> { … }

// Read converter as only the source type is one that can be handled natively
class MyConverter implements Converter<String, Person> { … }