2019/09/18

JEPでは語れないJava SE 13

このエントリーをはてなブックマークに追加

アメリカ西海岸時間の9月17日にJava SE 13がリリースされました。

ちょうどサンフランシスコではOracle Code Oneが開催されていて、櫻庭も参加しています。OC1に参加しているのでなかなか書く時間がとれないのですが、恒例となっているのでJEPで提案されている以外のJava SEの変更をまとめておきます。

Java SE 13も変更はかなり少ないです。提案されたJEPは5個。ライブラリに関するJEPはなく、言語使用に関するJEPが2つです。

1つがswitchが文から式になるということ(JEP 354)。Java SE 12でもPreview機能で入っていましたが、再検討されて新たにPreview機能として入っています。値を返す時のyieldが一番の違いです。

もう1つが、テキストブロック(JEP 355) こちらはJava SE 12で入らなかったJEP 326 Raw String Literalの再検討版です。もちろん、テキストブロックもpreview機能なので、今後変更される可能性があります。

 

さて、本題のAPIの方です。こちらもそれほど変更は大きくありません。

今回もABC順にならんでいます。同じように、セキュリティ系のAPIはちゃんと理解していないので、省略してます。

 

廃止になったAPI

Java SE 13では2つのメソッドが廃止になっています。

いずれも、Java SE 9で@DeprecatedのforRemovalがtrueになったメソッドです。

  • java.lang.Runtime.traceInstructions(boolean)
  • java.lang.Runtime.traceMethodCalls(boolean)

Java SE 12以前のJavadocを見ていただければ分かりますけど、この2つのメソッドの説明は"Not implemented, does nothing." なぜ、今まで残していたのか不思議なくらいですねw

 

廃止予定のAPI

廃止予定APIの追加は多いです。

パッケージ

  • javax.security.cert

クラス

  • javax.security.cert.Certificate
  • javax.security.cert.X509Certificate

例外

  • javax.security.cert.CertificateEncodingException
  • javax.security.cert.CertificateException
  • javax.security.cert.CertificateExpiredException
  • javax.security.cert.CertificateNotYetValidException
  • javax.security.cert.CertificateParsingException

メソッド

  • java.lang.String.formatted
  • java.lang.String.stripIndent
  • java.lang.String.translateEscapes
  • javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain
  • javax.net.ssl.SSLSession.getPeerCertificateChain

javax.security.certパッケージは、java.security.certパッケージを使うようにということです。javax.security.certパッケージはJava SE 9で@Deprecatedになったのですが、Java SE 13でforRemoval=trueになったということで、廃止することが決まったということです。

Stringクラスの3つのメソッドはJava SE 13で追加されたメソッドです。Java SE 13で追加されたのに、forRemoval=trueというのは、どういうこと?という感じですね。

これらのメソッドの機能については後述しますが、いずれもテキストブロックに関連しているメソッドなのです。つまり、テキストブロックがpreviewから正式な仕様に変更される時に、これらのメソッドも変更されるかもということを示しているわけです。

javax.net.sslパッケージの2つのメソッドもjavax.security.certパッケージに関連したメソッドです。HandshakeCompletedEvent.getPeerCertificateChainメソッドは返り値がX509Certificateクラスの配列なのです。今後はgetPeerCertificateChainメソッドではなく、同じクラスのgetPeerCertificatesメソッドを使うようにします。

SSLSession.getPeerCertificateChainメソッドも同じで、代わりにgetPeerCertificatesメソッドを使うようにします。

 

追加されたAPI

java.langパッケージ

JEPにはなっていないのですが、Java SE 13ではUnicode 12.0をサポートしています。その関連で2つのクラスに定数が増えました。

Character.UnicodeBlockクラス

UnicodeBlockクラスはその名の通り、Unicodeのブロックを表す定数を定義しているクラスです。Unicode 12.1で導入されたブロックが追加になりました。

  • EGYPTIAN_HIEROGLYPH_FORMAT_CONTROLS
  • ELYMAIC
  • NANDINAGARI
  • NYIAKENG_PUACHUE_HMONG
  • OTTOMAN_SIYAQ_NUMBERS
  • SMALL_KANA_EXTENSION
  • SYMBOLS_AND_PICTOGRAPHS_EXTENDED_A
  • TAMIL_SUPPLEMENT
  • WANCHO

Character.UnicodeScript列挙型

enumのUnicodeScriptにもUnicode 12.0で導入されたスクリプトが追加になりました。

  • ELYMAIC
  • NANDINAGARI
  • NYIAKENG_PUACHUE_HMONG
  • WANCHO

 

追記

Oracleの佐藤さんに、Java 13が対応しているUnicodeのバージョンが12.0ではなく、12.1と教えていただきました。本文は修正してあります。

なお、対応しているUnicodeのバージョンはjava.lang.CharaccterクラスのJavadocに記述してあるそうです。Java 13の場合は以下のように表記されています。

Character information is based on the Unicode Standard, version 12.1.

(Java 13 CharacterクラスのJavadocより引用)

 

Stringクラス

前述したように、Stringクラスにはテキストブロック関連のメソッドが3つ追加されました。しかも@DeprecatedのforRemoval=trueなので、コンパイル時に警告が出ます。

  • String formatted(java.lang.Object... args)
  • String stripIndent()
  • String translateEscapes()

J2SE 5でstaticメソッドのformatメソッドが導入されましたが、formattedメソッドはそれのインスタンスメソッド版です。

jshell>  import java.time.*

jshell> "%s%n".formatted(LocalDate.now())
|  警告:
|  java.lang.Stringのformatted(java.lang.Object...)は推奨されておらず、削除用にマークされ ています
|  "%s%n".formatted(LocalDate.now())
|  ^--------------^
$1 ==> "2019-09-17\r\n"

jshell>

formatメソッドもformattedメソッドも内部ではjava.util.Formatterクラスのformatメソッドをコールしています。

stripIndentメソッドは複数行からなる文字列の先頭文字がホワイトスペースだった場合、前詰めした文字列に変換するためのメソッドです。

jshell> var text = "  abc\n" +
   ...> "   def\n" +
   ...> "    ghi"
text ==> "  abc\n   def\n    ghi"

jshell> System.out.println(text)
  abc
   def
    ghi

jshell> System.out.println(text.stripIndent())
abc
 def
  ghi
|  警告:
|  java.lang.StringのstripIndent()は推奨されておらず、削除用にマークされています
|  System.out.println(text.stripIndent())
|                     ^--------------^

jshell>

なお、テキストブロックを使用すると、勝手に前詰めされます。コンパイル時にこのメソッドを使用しているかどうかまでは調べていないので、ぜひ調べてみてください。

translateEscapesメソッドはエスケープシーケンスを変換するメソッドです。

たとえば、"\n"という2文字で表されているエスケープシーケンスをU+000Aに置き換えます。

とはいうものの、このメソッドの使い道がイマイチよく分からないんですよね。文字列を出力する時には、置き換えられていたので、意識することはなかったのですが... どういう時に使うんだろう?

なお、このメソッドではUnicodeのエスケープは置き換えを行わないそうです。

 

java.nioパッケージ

Buffer系のクラスにメソッドがいろいろと追加されました。

Bufferクラス

Bufferクラスにはsliceメソッドがオーバーロードされました。

  • Buffer slice(int index, int length)

今まで使われていたsliceメソッドは引数なしでcurrent positionとlimitの間を切り出すメソッドでした。

オーバーロードされたのは明示的にインデックスと長さを指定して切り出すために使用されます。

実際には内部で、引数なしのsliceと同じような処理行っているので、使い勝手をよくするためのメソッドということですね。

jshell> var buffer = ByteBuffer.allocate(5)
buffer ==> java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]

jshell> buffer.position(2)
$3 ==> java.nio.HeapByteBuffer[pos=2 lim=5 cap=5]

jshell> var buffer2 = buffer.slice()
buffer2 ==> java.nio.HeapByteBuffer[pos=0 lim=3 cap=3]

jshell> var buffer3 = buffer.slice(2, 3)
buffer3 ==> java.nio.HeapByteBuffer[pos=0 lim=3 cap=3]

jshell>

同じ切り出しを引数なしのsliceメソッドと、引数ありのsliceメソッドでやってみました。

なお、Bufferクラスはアブストラクトクラスなので、ByteBufferクラスを使用しています。

もちろん、他のCharBufferクラスなどでも引数ありsliceメソッドがオーバーロードされています。

ByteBuffer/CharBuffer/DoubleBuffer/FloatBuffer/IntBuffer/LongBuffer/ShortBufferクラス

それぞれのクラスにgetメソッドが2つ、putメソッドが2つオーバーロードされています。

Bufferクラスに追加されたsliceメソッドは返り値の方がBufferクラスなのですが、ByteBufferクラスなどでオーバーロードされたメソッドは返り値の型がそれぞれのクラスなので、Bufferクラスでは定義できないのでした。

ただ、使い道はどのクラスでも同じなので、ここではByteBufferクラスで説明します。

  • ByteBuffer get(int index, byte[] dst)
  • ByteBuffer get(int index, byte[] dst, int offset, int length)
  • ByteBuffer put(int index, byte[] src)
  • ByteBuffer put(int index, byte[] src, int offset, int length)

今までのgetメソッドはpositionの位置から読み込みを行うか、インデックスを指定して1バイト読み込むかのどちらかしかありませんでした。新しくオーバーロードされたgetメソッドはインデックスを使用して第2引数のバイト配列に読み込みを行います。

jshell> var b = new byte[]{0, 1, 2, 3, 4, 5}
b ==> byte[6] { 0, 1, 2, 3, 4, 5 }

jshell> var buffer = ByteBuffer.wrap(b)
buffer ==> java.nio.HeapByteBuffer[pos=0 lim=6 cap=6]

jshell> var bytes = new byte[2]
bytes ==> byte[2] { 0, 0 }

jshell> buffer.get(2, bytes)
$13 ==> java.nio.HeapByteBuffer[pos=0 lim=6 cap=6]

jshell> bytes
bytes ==> byte[2] { 2, 3 }

jshell>

ここでは、インデックス2から2バイト読み込んでます。

putメソッドも同じで、今まではpositionから書き込みを行うか、インデックスを使用して1文字の書き込みを行うだけだったのが、インデックスを使用してバイト配列で書き込みが行えるようになりました。

MappedByteBufferクラス

MappedByteBufferクラスにはforceメソッドがオーバーロードされました。

  • MappedByteBuffer force(int index, int length)

今までのforceメソッドは引数なしで、メモリにマップされた内容を強制的にファイルに書き出すというメソッドでした。オーバーロードされたforceメソッドはインデックスと長さを指定して強制的にファイルに書き出しを行います。

 

java.nio.fileパッケージ

FileSystemsクラス

FileSytemクラスでは、3種類のnewFileSystemメソッドがオーバーロードされています。

  • FileSystem newFileSystem(Path path)
  • FileSystem newFileSystem(Path path, Map env)
  • FileSystem newFileSystem(Path path, Map env, ClassLoader loader)

newFileSystemメソッドはFileSystemクラスのファクトリメソッドなのですが、今までは場所を指定するのにURIを使用していました。Pathインタフェースも使えたのですが、クラスローダ―を指定する必要がありました。

Java 13で追加された3種類はどれもPathインタフェースで場所を指定します。

ZIPファイルやJARファイルをファイルシステムとみなして扱うような時に使用するメソッドなのですが、パスで指定できるようになったので、少しだけ扱いやすくなりました。

jshell> var path = Paths.get("C:\\Program Files\\Java\\jdk-13\\lib\\src.zip")
path ==> C:\Program Files\Java\jdk-13\lib\src.zip

jshell> var fileSystem = FileSystems.newFileSystem(path)
fileSystem ==> C:\Program Files\Java\jdk-13\lib\src.zip

jshell> Files.list(fileSystem.getPath(".")).forEach(System.out::println)
./jdk.zipfs
./jdk.xml.dom
./jdk.unsupported.desktop
./jdk.unsupported
./jdk.security.jgss
./jdk.security.auth
./jdk.sctp
./jdk.scripting.nashorn.shell
./jdk.scripting.nashorn
./jdk.rmic
./jdk.pack
./jdk.net
    <<以下、省略>>

jshell>

 

java.time.chronoパッケージ

JapaneseEraクラス

日本の元号を表すクラスですが、令和が定数として追加されました。メジャーバージョンとしてはJava 13からということです。

  • REIWA

javax.annotationパッケージ

ProcessingEnvironmentインタフェース

アノテーションの処理を行う時に使用するインタフェースがProcessingEnvironmentインタフェースです。

  • boolean isPreviewEnabled()

プレビュー機能を使用する時にはコンパイル/実行時に--enable-previewオプションを使用します。isPreviewEnabledメソッドは--enable-previewが指定されていればtrue、いなければfalseを返します。

 

javax.lang.modelパッケージ

SourceVersion列挙型

毎度のお約束ですが、定数にJava 13が追加されました。

  • RELEASE_13

 

javax.lang.model.elementパッケージ

ExecutableElementインタフェース

ExecutableElementインタフェースは、クラスやインタフェースのメソッド、コンストラクタなど実行できる要素を表すためのインタフェースです。

  • TypeMirror asType()

ExecutableElementインタフェースで表している実行要素がメソッドなのか、コンストラクタなのか、初期化子なのかを判別するために使用します。

 

javax.toolsパッケージ

StandardJavaFileManagerインタフェース

javax.toolsパッケージはコンパイラ系のクラスが定義されているのですが、そこで使用するファイルマネージャがStandardJavaFileManagerインタフェースです。

  • Iterable<? extends JavaFileObject> getJavaFileObjectsFromPaths​(Collection<? extends Path> paths)

これまで使われていたgetJavaFileObjectsFromPathメソッドは引数の型がIterableインタフェースだったのですが、Collectionインタフェースを引数にとるメソッドがオーバーロードされました。

逆に引数の型がIterableインタフェースの方は@Deprecatedになっています。

 

javax.xml.parsersパッケージ

DocumentBuilderFactoryクラス

まさか、この期におよんでDOMパーサーに機能が追加されるとは思いもよりませんでしたw

  • DocumentBuilderFactory newDefaultNSInstance()
  • DocumentBuilderFactory newNSInstance()
  • DocumentBuilderFactory newNSInstance​(String factoryClassName, ClassLoader classLoader)

いずれも名前空間を認識したDocumentBuilderFactoryオブジェクトを生成するファクトリクラスです。

 

他にもセキュリティ系のAPIに追加がありますが、よく分からないので省略します。

ということで、Java 13のAPIの変更をまとめてみましたが、やっぱり変更は少ないですね。

 

2019/06/15

JJUG CCC 2019 Spring

このエントリーをはてなブックマークに追加

もう1月も前ですが、5月18日にJJUG CCC 2019 Springが開催されました。Oracle Codeの次の日ですね。

今回はProject LoomのFiberについてプレゼンしました。資料はこちら。

Fiberはいわゆる軽量スレッドです。

プレゼンではなぜ軽量スレッドが必要なのかという部分について、かなり時間をかけて説明しました。

OSに強く結びついたThreadを使った場合、コンテキストスイッチにコストがかかります。時間もかかるし、メモリも多く使用します。

これは、スレッドごとに用意されるJVM Stackをすべて退避させたり、もどしたりする必要があるからです。JVM Stackは、そのスレッドでコールされているメソッドコールのスタックで、メソッドで使われるローカル変数やオペランドスタックも含みます。

また、OSがスレッドのスケジューリングを管理しているため、コンテキストスイッチがいつ行われているかもJava側からは管理することができません。

そのために求められているのが、JVMで管理する軽量スレッド、つまりFiberというわけです。

これに対し、Fiberを使えば、ワーカースレッド上で動作するため、スケジューリングはJVMで管理でき、状態の退避用のメモリも少なくてすみます。

Fiberでは、スケジューリングには既存のFork/Join Frameworkが使用されます。コンテキストスイッチには処理の中断、再開のための仕組みが必要ですが、これはContinuationで行います。Continuationはいわゆる継続を実現させるための仕組みですが、JavaのContinuationは限定継続になります。

プレゼンの中ではContinuationをかなり強引にwait-notifyAllと同じようなものと説明してしまったため、誤解させてしまったのではないかと反省しています。もちろん、Continuationもwait-notifyAllも処理の中断・再開をするという機能はありますが、一般的なContinuationでできることは処理の中断・再開だけではありません。ちょっと説明不足でした。

しかし、今のところProject LoomではContinationを積極的に活用するようなシナリオはないように見えます。現状は、I/O待ちのためにパフォーマンスが落ちていることに対して、Fiberを使ってI/O待ちをなるべく解消することがメインの目的のようです。

これは、処理の中断・再開を行うFiberのparkメソッド、unparkメソッドがデフォルトのアクセス制御であることからも分かります。park/unparkを使用しているのは、ReentrantLockクラスなどのロック系のクラスや、java.nio.channelパッケージのソケット通信などのクラスなどです。

プレゼンの中では前日に行ったOracle Codeのデモについても説明しました。JDKに含まれているHTTPサーバーであるcom.sun.net.httpserver.HttpSErverクラスを使用して、Fiberを指定しているだけです。これだけで、既存のExecutorServiceインタフェースを使用した場合よりもスレッド数やスループットが向上しました。

とはいうものの、現状Fiberはそこまで速くありません。

コンテキストスイッチが起きないようにうまくタスク分けして、I/O待ちも多重化するなどして待たなければいけないスレッドを最小化するなどのチューニングを行えば、Fiberより高いパフォーマンスを得ることができます。

ただ、それをするには設計やチューニングなどの高度な知識や経験が求められます。Fiberを使うことで誰でも簡単にパフォーマンスを向上させられるということが、Fiberの意義の1つなのではないかと感じています。

また、Fiberのさらなるパフォーマンス向上のためにJVM Stackを操作することも考えられているようなので、今後に期待したいですね。

 

さて、以下は会場やsli.doでの質問とその回答です。

Q Fiberの中断前と再開後でワークスレッドが変わることがあるのか?

A. あります。

キターーーーーーー 「この分野は素人なのですが」な質問!!!

なんとか答えられてよかったですw

さて、現状はFiberはシリアライザブルではないのですが、シリアライザブルにする計画があります。このため、ワークスレッドが変化することもありますし、処理途中のFiberを他のCPUに移動させてそこで再開というシナリオも考えられます。

質問した伊藤さんも心配されていますが、ロガーのようにスタックトレースを保持させるようなものは、Fiberにするとやばいかもしれません。

Q. ある時点の処理で中断していたものを複数回再実行することはできるか?

A. 一般的な継続だとこれができるのですが、今のところJavaのFiberでは計画されていないようです。

Fiberは継続を行うための状態管理に既存のJVM Stackをそのまま使っています。そのため、再実行を行うには、JVM Stackを操作するバイトコードが必要になるはずですが、そこまでやるとかなり大がかりになってしまうためかもしれません。

Q. ワークスレッドは自動的に用意されるのか?

A. されます。

デフォルトではForkJoinPoolを利用してワークスレッドの割り当てを行っています。もちろん、他のスレッドプールに置き換えることもできます。

Q. OSによらないThreadがFiberだとしたら、Green Threadのようなもの?

A. まさにGreen Threadです。

Javaの初期のころ、Solaris向けのJavaはネイティブのスレッドではなく、JVMが管理するスレッドを使用していたのですが、それがGreen Threadです。

Q. Kotlinのcoroutineと何が違うのか?

A. Kotlinのことをよく知らないのですが、同じような機能のようですね。

Q. Continuationのscopeがよく分からない。コンテキストスイッチを行いたい複数のFiberからなるグループのようなもの?

A. 継続処理を行いたい範囲をしめすものです。

どこからでも自由に中断・再開を行うのは難しいので、継続ができる範囲を決めているという感じです。Fiberも内部でスコープを持っていて、Fiberのタスク処理の中だけで継続を行っています。

Q. ThreadとFiberの使い分け指針が知りたい

A. I/Oの待機やロックの取得を含む非同期処理であればFiberを使うのがよいと思います。

計算処理だけであるならパラレルストリームやFork/Join Frameworkを使いましょう。それ以外だったらThreadになると思いますが、今でもExecutorServiceにタスクを渡すのが主で、Threadを直接使うことはまずないはずです。

Q. 既存のThreadをFiberに置き換えるイメージがつかめません。ExecutorServiceでThreadを使うようなことはFiberでもできるのでしょうか。

A. Fiber.scheduleメソッドがExecutorService.submitメソッドのような感じです。

Fiber.scheduleメソッドはstaticメソッドなので、ExecutorServiceのようにExecutorsクラスでExecutorServiceインスタンスを生成して、それからsubmitするまでを行っているような感じです。

Q. Loom入りのJDKを含んだDocker Imageは公開されているか?

A. 私が調べたときにはなかったです。

Docker上でLoomのJDKをビルドしようとするとなぜか落ちてしまうので、私はローカルな環境でビルドしてからそれをコピーするDockerfileを作ってDockerのイメージを作ってました。

Q. Loomのリリース予定は未定だとしても、現時点での目標とかはあるのでしょうか?

A. 明確なリリース予定時期がFiberを作っている人たちの間ではあるのかもしれませんが、私には分からないです。

少なくとも、Windowsで動作できるようにならないとリリースはできないので、そこが最低限の目標となるのではないでしょうか。

2019/05/22

Oracle Code Tokyo 2019

このエントリーをはてなブックマークに追加

5月17日にシェラトン都ホテルで開催されたOracle Code Tokyoのキーノートで、@bitter_foxさんと一緒にデモをしてきました。

キーノートは2部構成で前半がOracleのGeorges Saabさん、後半がウルシステムズの漆原さんがモデレータのパネル。
私たちは前半のGeorgesのキーノートの中でデモを行いました。

 

当初、Oracle側からはJava SE 12か13の新機能についてデモをしてくれということだったのですが... switch文がswitch式になって書き方が変わったよとデモしてもつまらないですよね。

そこで、12もしくは13ではなく、今後登場する機能のデモでもいいかと聞いてみたら、OKが出たのです。

そこで、@bitter_foxさんと検討して、Project PanamaのVector APIとProject LoomのFiberのデモを行うことにしました。

 

デモのシナリオとしては以下の通り。デモの題材は画像処理のソフトフォーカスエフェクトです。

  1. デスクトップアプリで、Vector APIと従来のループを使った画像処理を比較
  2. デスクトップアプリはJavaFXで記述しているが、REST APIとしても画像処理できるようにする
  3. 画像処理を行うインスタンスを複数起動して、それらをコールするフロントのWebサーバーをFiberを使用して実装する
  4. 従来のThreadを使ったサーバーと、Fiberを使ったサーバーに対し負荷テストを行い、スループットなどの違いをリアルタイムで見せる

見てすぐわかるというところに、かなりこだわってみました。

上の写真がデスクトップアプリのスクリーンショットです。上部に24枚の写真のサムネイルが並んでおり、順々に画像処理していきます。だいたい、3倍から4倍ぐらいパフォーマンスが向上しました。

負荷テストの結果はGrafanaを使って表示させています。ちょっと条件を作りこんでいる部分はあるのですが、2倍程度のスループット向上が実現できました。

まぁ、お分かりだとは思いますけど、Vector APIの部分を櫻庭が作り、Fiberの部分を@bitter_foxさんが作っています。サーバーサイドがまったく分からない櫻庭の実力の低さが露呈してしまいましたw Grafanaを使ったモニタリングの仕組みなども、全部@bitter_foxさんにおまかせです 😅

それでも、見ていただいた方には結構好評だったようで、ほんとよかったです!

デモのコードについては、近日公開予定です。公開したら、解説のエントリーを書きます。

 

ところで、このデモで使った写真ですが、今までのJavaOneなどで撮った写真を使ってます。すべての人物が分かるのであれば、それはJavaの歴史にかなり精通しているといえると思いますよ。歴史的瞬間もあったりします。

ところで、土下座している人は何を謝っているんですかねぇw

 

2019/04/04

Java SE 12: Not Mentioned in JEP

このエントリーをはてなブックマークに追加

Java SE 12 was released in 19th March!

So, I'll show updates in Java SE 12. But, I don't explain about the new features mentioned in JEPs.

In general, the updates in Java SE 12 are fewer than other Java SE releases. In the point of syntax, switch statement changes to switch expression (JEP 325). It's big change! But, the API updates are not big.

 

Removed APIs

There are 5 removed methods in Java SE 12.

All are the methods that forRemoval of @Deprecated set true in Java SE 10.

  • java.io.FileInputStream.finalize()
  • java.io.FileOutputStream.finalize()
  • java.util.zip.Deflater.finalize()
  • java.util.zip.Inflater.finalize()
  • java.util.zip.ZipFile.finalize()

Because these methods are only finalize methods, so you feel no difficulty for coding. If you have difficulty, the design may be wrong.

 

In addition, 4 methods were removed.

All of them are override getCause methods, and these classes use getCause method of super class after removing.

  • java.lang.FileNotFoundException.getCause()
  • java.lang.ExceptionInInitializerError.getCause()
  • java.lang.reflext.UndeclaredThrowableException.getCause()
  • java.security.PrivilegedActionException.getCause()

 

APIs proposed for Removal

There are no APIs that are added for removal in Java SE 12.

 

Added APIs

java.lang.constant package

A package was added to java.base module!

But, most of developer seem never to use the package. Because, the pacakge was introduced for "Condy." Cody is for dynamic constant loading as an equivalent to Indy for dynamic method invocation.

APIs included in new package are based on JEP 334: JVM Constants API.

In addition, some interfaces/class and methods are introduced in java.lang.invoke package.

Added interfaces/class are shown below:

  • TypeDescriptor interface
  • TypeDescriptor.OfField interface
  • TypeDescriptor.OfMethod interface
  • VarHandle.VarHandleDesc class

There are 3 methods added:

  • Optional<MethodHandleDesc> MethodHandle.describeConstable()
  • String MethodType.describeString()
  • Optional<MethodTypeDesc> describeConstable()

Moreover, there are 4 methods added in java.lang.Class class:

  • Class<?> arrayType()
  • Class<?> componentType()
  • Optional<ClassDesc> describeConstable()
  • String descriptorString()

 

Besides these, Enum class implements Constable interface, and Enum.EnumDesc inner class is added. Integer/Long/Float/Double/String classes are updated to implement ConstantDesc insterface. These classes are added describeConstant method and resolveConstantDesc method.

However, most of developers seems not to use these new condy APIs for usual software development.

 

java.io package

InputStream class

InputStream class has skip method, and a related method is added:

  • void skipNBytes(long n)

skip method javadoc said "The skip method may, for a variety of reasons, end up skipping over some smaller number of bytes." For this reason, skip methods return actual number of skipping over.

Comparatively, skipNBytes method skip over and discards exactly n bytes. Because of exactly skipping over, type of skipNBytes return value is void.

 

java.lang package

I listed condy related updates of java.lang package, so I'll show other updates.

 

Character.UnicodeBloch/UnicodeScript class

Java SE 12 starts to support Unicode 11.0, but this update is not described in JEP. Java SE 11 supports Unicode 10.0.

For this update, some Unicode blocks and scripts are added. For example, CHESS_SYMBOLS that means chess pawns is added.

 

String class

As previously described, String class added two condy related methods. In addition, a method is added:

  • String indent(int n)

indent method inserts specified number of white spaces into head of line, and inserts new line (\n) into end of string.

jshell> var text = "Hello\nWorld!"
text ==> "Hello\nWorld!"

jshell> System.out.println(text)
Hello
World!

jshell> text = text.indent(4)
text ==> "    Hello\n    World!\n"

jshell> System.out.println(text)
    Hello
    World!


jshell>

If argument is minus value, indent method removes specified number of white spaces. In this case, indent method only remove white spaces.

jshell> text = text.indent(-2)
text ==> "  Hello\n  World!\n"

jshell> text = text.indent(-3)
text ==> "Hello\nWorld!\n"

jshell>

Originally, Java SE 12 planed to introduce JEP 326 Raw String Literals, but gave it up.

JEP 326 includes some String class methods definition. However, these methods were also abandoned.

Only indent method was added to String class. I don't know why.

 

java.net package

SecureCacheResponse class

A method to get SSL/TLS session is added to SevureCacheResponse class.

  • Optional<SSLSession> getSSLSession()

 

ServerSocket class

A constructe is added to ServerSocket class!

  • protected ServerSocket(SocketImpl impl)

However, this constructer is proteced method, so we don't use it in normal software development.

 

java.nio.file package

Files class

A method for finding mismatch points of two fiels is introduced:

  • static long mismatch(Path path, Path path2)

 

mismatch method finds the first difference between path and path2, and returns the position of the first difference of two.

If two files are same, mismatch method returns -1.

C:\demo>cat hello1.txt
Hello, World!

C:\demo>cat hello2.txt
Hello, Java!

C:\demo>cat hello3.txt
Hello, World!

C:\demo>jshell
|  Welcome to JShell -- Version 12
|  For an introduction type: /help intro

jshell> import java.nio.file.*

jshell> var hello1 = Paths.get("hello1.txt")
hello1 ==> hello1.txt

jshell> var hello2 = Paths.get("hello2.txt")
hello2 ==> hello2.txt

jshell> var hello3 = Paths.get("hello3.txt")
hello3 ==> hello3.txt

jshell> Files.mismatch(hello1, hello2)
$5 ==> 7

jshell> Files.mismatch(hello1, hello3)
$6 ==> -1

jshel>

 

java.text package

CompactNumberFormat class

We occasionally want to show numbers using K or M like 10K (10,000). But, Java didn't have such number formatter API before.

Then, Java SE 12 introduced CompactNumberFormat class.

CompaceNumberFormat is a subclass of NumberFormat class, so usage is same. There is a constructor, but it is convenient for us to use factory methods of NumberFormat class.

jshell> import java.text.*

jshell> var formatter = NumberFormat.getCompactNumberInstance()
formatter ==> java.text.CompactNumberFormat@73cf7357

jshell> formatter.format(10000)
$3 ==> "10K"

jshell> formatter.format(12345)
$4 ==> "12K"

jshell> formatter.format(15678)
$5 ==> "16K"

jshell>

The method to get CompactNumberFormat object is NumberFormat.getCompactNumberInstance method. If you use it without argument, you get CompactNumberFormat object of default locale.

In above example, the default locale is English, so the result of formatting 10,000 was 10K.

It's to be noted that default rounding is RoundingMode.HALF_UP. So, CompactNumberInstance method returns 16K when formatting 15,678.

If you'd like to use RoundingMode.FLOOR, you should use setRoundingMode method.

When formatting the number more than 1,000,000, CompactNumberFormat object uses M.

jshell> formatter.format(12_345_678)
$3 ==> "12M"

jshell>

It's also to be noted that the return type of getCompactNumberInstance method is not CompactNumberFormat class but NumberFormat class.

We, Japanese count number by 104not 103. Number unit of 104 is "万" and 108 is "億".

If you'd like to use "万" or "億", you chage locale.

jshell> var formatter = NumberFormat.getCompactNumberInstance(new Locale("jp"), NumberFormat.Style.SHORT)
formatter ==> java.text.CompactNumberFormat@952071d5

jshell> formatter.format(100_000)
$5 ==> "10万"

jshell> formatter.format(123_456)
$6 ==> "12万"

jshell>

Second argument type of getCompactNumberInstance method is Number.Style enum. It is introduced in Java SE 12.

There are two constants defined in Number.Style: LONG and SHORT. No argument getCompactNumberInstance method uses SHORT by default.

When locale is jp (Japanese), 100,000 is formatted to "10万" and 123,456 is formatted to "12万".

 

In case of LONG;

jshell> var formatter = NumberFormat.getCompactNumberInstance(new Locale("en"), NumberFormat.Style.LONG)
formatter ==> java.text.CompactNumberFormat@952071d5

jshell> formatter.format(10000)
$7 ==> "10 thousand"

jshell> formatter.format(12345)
$8 ==> "12 thousand"

jshell>

"10 thousand" is compact, isn't it 🤔.

 

NumberFormat class

As previously explained, two static factory methods are introduced:

  • static NumberFormat getCompactNumberInstance()
  • static NumberFormat getCompactNumberInstance(Locale locale, NumberFormat.Style formatStyle)

java.text.spi.NumberFormatProvider were also added getCompactNumberInstance method.

 

NumberFormat.Field class

Two constants are added:

  • static final NumberFormat.Field PREFIX
  • static final NumberFormat.Field SUFFIX

 

NumberFormat.Style enum

Style enum is also explained previously. It is for constructing CompactNumberFormat object.

There are two constants: LONG and SHORT.

 

java.util.concurrent package

CompletionStage class

5 similar methods to exceptionally method are introduced.

  • default CompletionStage<T> exceptionallyAsync(Function<Throwable, ? extends T> fn)
  • default CompletionStage<T> exceptionallyAsync(Function<Throwable, ? extends T> fn, Executor executor)
  • default CompletionStage<T> exceptionallyCompose (Function<Throwable, ? extends CompletionStage<T>> fn)
  • default CompletionStage<T> exceptionallyComposeAsync(Function<Throwable, ? extends CompletionStage<T>> fn)
  • default CompletionStage<T> exceptionallyComposeAsync(Function<Throwable, ? extends CompletionStage<T>> fn, Executor executor)

exceptionally method is called when an exception is thrown in the previsou stage. If no exception in the previous stage, exceptionally method are skipped, and then next stage are executed.

exceptionallyAsync methods are called asynchronously as can be seen by method name.

jshell> import java.util.concurrent.*;
  
jshell> CompletableFuture.runAsync(() -> {
   ...>     System.out.println(Thread.currentThread());
   ...>     throw new RuntimeException();
   ...> }).
   ...> exceptionally(ex -> {
   ...>     System.out.println(Thread.currentThread());
   ...>     return null;
   ...> }).get();
Thread[ForkJoinPool.commonPool-worker-3,5,main]
Thread[main,5,main]
$2 ==> null

jshell> CompletableFuture.runAsync(() -> {
   ...>     System.out.println(Thread.currentThread());
   ...>     throw new RuntimeException();
   ...> }).
   ...> exceptionallyAsync(ex -> {
   ...>     System.out.println(Thread.currentThread());
   ...>     return null;
   ...> }).get();
Thread[ForkJoinPool.commonPool-worker-3,5,main]
Thread[ForkJoinPool.commonPool-worker-3,5,main]
$3 ==> null

jshell>

Executing by JShell, you can see exceptionally method is executed in main thread, but exceptionallyAsync method is executed in worker thread managed by ForkJoinPool.

 

The Argument of exceptionally method is a lambda expression that gets Throwable object as argument and return something value. On the other hand, the return value tyep of exceptionallyCompose method is CompletionStage class.

thenCompose method returns also CompletionStage object, so exceptionallyCompose is similar to thenCompose. As you may know, exceptionallyComposeAsync method is asynchronous version of exceptionallyCompose.

 

java.util.stream package

Collectors class

A method that execute two terminal operations and gathers these return values is introduced:

  • static <T,R1,R2,R> Collector<T,?,R> teeing(Collector<? super T,?,R1> downstream1, Collector<? super T,?,R2> downstream2, BiFunction<? super R1,? super R2,R> merger)

First and second argument is objects implicated Collect interface (usually we use static methods of Collectors class.) Third argument is a lambda expression for combining first and second Collect objects return values.

The following shows string concatination and couting number of characters, and then combining these two operations return values.

jshell> var text = List.of("a", "b", "c", "d", "e")
text ==> [a, b, c, d, e]

jshell> text.stream().
   ...> collect(Collectors.teeing(Collectors.joining(), 
   ...> Collectors.counting(), 
   ...> (x, y) -> x + " : " + y))
$1 ==> "abcde : 5"

jshell>

It seems very useful!

 

javax.lang.model package

SouceVersion class

Every version up, SouceVersion add a constant:

  • static final SourceVersion RELEASE_12

On the other hand, SourceVersion class is now implementing Constable interface.

 

Others

javax.naming.ldap.spi package is introduced for LDAP service provider. The package includes two class: LdapDnsProvider and LdapDnsProviderResult.

javax.net.ssl.HttpsURLConnection class is added getSSLSession method.

 

Swing is also added a method.

getChooserShortcutPanelFiles method is introduced in javax.swing.filechooser.FileSystemView class. But, usually we don't use the method. It is for internal use.

 

That's all.

2019/03/16

JEPでは語れないJava SE 12

このエントリーをはてなブックマークに追加

アメリカ西海岸時間の3月19日にJava SE 12がリリースされます。

恒例となっているJEPで提案されている以外のJava SEの変更をまとめておきましょう。

全般的にいえるのが、Java SE 12の変更がかなり小規模だということ。言語仕様的にはswitchが文から式になったことが大きいですが、APIの変更はほんとにちょっとしかありません。

今回もABC順にならんでいます。同じように、セキュリティ系のAPIはちゃんと理解していないので、省略してます。

 

廃止になったAPI

Java SE 12では5つのメソッドが廃止になっています。

いずれも、Java SE 10で@DeprecatedのforRemovalがtrueになったメソッドです。つまり、forRemovalがtrueになってから1年で廃止ということです。

  • java.io.FileInputStream.finalize()
  • java.io.FileOutputStream.finalize()
  • java.util.zip.Deflater.finalize()
  • java.util.zip.Inflater.finalize()
  • java.util.zip.ZipFile.finalize()

finalizeメソッドですから、なくても何ら問題はないはず。というか、逆にfinalizeメソッドを使っていたとしたら、その設計の方が問題です。

 

これら以外に、4つのクラスの4メソッドが廃止されました。

いずれもスーパークラスをオーバーライドしていたメソッドで、スーパークラスのメソッドを使うようになったというだけです。

  • java.lang.FileNotFoundException.getCause()
  • java.lang.ExceptionInInitializerError.getCause()
  • java.lang.reflext.UndeclaredThrowableException.getCause()
  • java.security.PrivilegedActionException.getCause()

 

廃止予定のAPI

Java SE 12での廃止予定APIの追加はありませんでした。

 

追加されたAPI

java.lang.constantパッケージ

なんと、java.baseモジュールにパッケージが追加されました!

とはいうものの、普通の開発者がjava.lang.constantパッケージを使うことはまずないと思います。というのも、Java SE 11で導入されたindyの定数版であるcondyで使われるためのクラス群だからです。

このパッケージはJEP 334: JVM Constants APIに基づくパッケージです。

また、このパッケージの追加にともない、java.lang.invokeパッケージのクラス群にもクラスの追加やメソッドの追加があります。

追加されたクラス群は

  • TypeDescriptorインタフェース
  • TypeDescriptor.OfFieldインタフェース
  • TypeDescriptor.OfMethodインタフェース
  • VarHandle.VarHandleDescクラス

の4つです。

メソッドの追加は3つ。

  • Optional<MethodHandleDesc> MethodHandle.describeConstable()
  • String MethodType.describeString()
  • Optional<MethodTypeDesc> describeConstable()
さらに、java.lang.Classクラスにも以下のメソッドが追加されています。
  • Class<?> arrayType()
  • Class<?> componentType()
  • Optional<ClassDesc> describeConstable()
  • String descriptorString()

他にも、EnumクラスがConstableインタフェースを実装するようになり、サブクラスとしてEnum.EnumDescクラスが追加されています。

また、Integerクラス、Longクラス、Floatクラス、Doubleクラス、StringクラスがConstableインタフェースとConstatntDescインタフェースを実装しています。

これらのクラスはdescribeConstantメソッドとresolveConstantDescメソッドが追加されています。

いずれも、普通の開発では使わないと思います。

java.ioパッケージ

InputStreamクラス

InputStreamクラスにはskipメソッドがありましたが、それに関連したメソッドが追加されました。

  • void skipNBytes(long n)

skipメソッドは "さまざまな理由から、skipメソッドは指定よりも少ないバイト数しかスキップしないことがあります" とJavadocに書いてあります。このため、返り値として実際にスキップしたバイト数が返ります。

これに対し、skipNBytesメソッドは必ず指定したバイト数をスキップします。このため、返り値はありません。

 

java.langパッケージ

java.lang.Classクラスのメソッド追加に関しては上述したので、それ以外の追加分です。

Character.UnicodeBloch/UnicodeScriptクラス

JEPにはなっていないのですが、Java SE 12はUnicode 11.0をサポートしています。Java SE 11はUnicode 10.0でした。

この変更に伴って、ブロックとスクリプトの定数が追加されています。たとえば、チェスの駒の絵文字を表すブロックとしてCHESS_SYMBOLSなどがあります。

 

Stringクラス

Stringクラスは前述したようにcondy関連のメソッドが2つ追加されていますが、それ以外にもう1つメソッドが追加されました。

  • String indent(int n)

indentメソッドは指定した数だけ行頭に空白を埋め込む処理を行います。さらに、文字列の最後に\nが挿入されます。

jshell> var text = "Hello\nWorld!"
text ==> "Hello\nWorld!"

jshell> System.out.println(text);
Hello
World!

jshell> text = text.indent(4);
text ==> "    Hello\n    World!\n"

jshell> System.out.println(text)
    Hello
    World!


jshell>

なお、負の数を指定すると、行頭のホワイトスペースが指定した数だけ削除されます。削除されるのはホワイトスペースだけです。

jshell> text = text.indent(-2)
text ==> "  Hello\n  World!\n"

jshell> text = text.indent(-3)
text ==> "Hello\nWorld!\n"

jshell>

もともとJava SE 12はJEP 326 Raw String Literalsが導入される予定だったのですが、結局スリップしてしまいました。

このJEP 326にともなって、Stringクラスにはalignメソッドなどのメソッドが追加予定だったのです。しかし、JEP 326がスリップしてしまったことにより、これらのメソッドも追加されないことになっていました。

ところが、indentメソッドだけは生き残ったというわけです。

 

java.netパッケージ

SecureCacheResponseクラス

SecureCacheResponseクラスにはSSLセッションを取得するメソッドが追加されました。

  • Optional<SSLSession> getSSLSession()

 

ServerSocketクラス

ちょっと珍しいのですが、コンストラクタが追加されました。

  • protected ServerSocket(SocketImpl impl)

追加されたといっても、protectedメソッドなので普通は使わないでしょう。

 

java.nio.fileパッケージ

Filesクラス

2つのファイルの相違点を見つけるメソッドが追加されました。

  • static long mismatch(Path path, Path path2)

引数のpathとpath2のファイルの相違点を見つけて、はじめの相違点までのバイト数を返します。

相違点がない場合、-1が返ります。

C:\demo>cat hello1.txt
Hello, World!

C:\demo>cat hello2.txt
Hello, Java!

C:\demo>cat hello3.txt
Hello, World!

C:\demo>jshell
|  JShellへようこそ -- バージョン12
|  概要については、次を入力してください: /help intro

jshell> import java.nio.file.*

jshell> var hello1 = Paths.get("hello1.txt")
hello1 ==> hello1.txt

jshell> var hello2 = Paths.get("hello2.txt")
hello2 ==> hello2.txt

jshell> var hello3 = Paths.get("hello3.txt")
hello3 ==> hello3.txt

jshell> Files.mismatch(hello1, hello2)
$5 ==> 7

jshell> Files.mismatch(hello1, hello3)
$6 ==> -1

jshel>

 

java.textパッケージ

CompactNumberFormatクラス

数字の10,000を10Kとか1万とか記述することがありますね。ところが、今までJavaでは数字をこのようにフォーマットする標準のAPIがありませんでした。

そこで、Java SE 12で導入されたのがCompactNumberFormatクラスです。

CompactNumberFormatクラスはNumberFormatクラスのサブクラスなので、使い方は一緒です。コンストラクタも用意されていますが、手っ取り早いのはNumberFrmatクラスのファクトリメソッドを使用する方法です。

jshell> import java.text.*

jshell> var formatter = NumberFormat.getCompactNumberInstance()
formatter ==> java.text.CompactNumberFormat@73cf7357

jshell> formatter.format(10000)
$3 ==> "1万"

jshell> formatter.format(12345)
$4 ==> "1万"

jshell> formatter.format(15678)
$5 ==> "2万"

jshell>

CompactNumberFormatオブジェクトを取得するためのメソッドがgetCompactNumberInstanceメソッドです。引数なしでコールすると、デフォルトロケールのCompactNumberFormatオブジェクトを返します。

そのため、10,000をフォーマットすると"1万"となるわけです。

それにしても、万の単位より小さいところが四捨五入といいうのは...

四捨五入にするか切り捨てにするかは、NumberFormatクラスのsetRoundingModeメソッドで変更できますが、デフォルトが四捨五入というのはどうなんですかね。

万の次は億なので、100,000,000より大きい数になると億より小さいところも四捨五入です。1億2345万とかにはならないです。

setMaximumFractionDigitsメソッドで四捨五入された部分を小数点で出せますけど、あまり意味ないかも。

ついでに、気をつけなくてはいけないのが、getCompactNumberInstanceメソッドの返り値の型がCompactNumberFormatクラスではなく、NumberFormatクラスだということです。

 

"1万"ではなくて"10K"と表示したい場合は、ロケールを指定します。

jshell> var formatter = NumberFormat.getCompactNumberInstance(new Locale("en", "US"), NumberFormat.Style.SHORT)
formatter ==> java.text.CompactNumberFormat@952071d5

jshell> formatter.format(10000)
$6 ==> "10K"

jshell> formatter.format(12345)
$7 ==> "12K"

jshell>

getCompactNumberInstanceメソッドの第2引数は、新しく追加された列挙型のNumber.Style列挙型です。

Number.Style列挙型の定数としてLONGとSHORTがあります。もちろん、CompactNumberFormatオブジェクトを取得するにはSHORTを指定します。

ロケールがen_USだと、10,000が"10K"とフォーマットされます。こちらもKより小さい桁は切り捨てです。

ところで、SHORTでなくて、LONGにしてみたらどうなるでしょう。

jshell> var formatter = NumberFormat.getCompactNumberInstance(new Locale("en", "US"), NumberFormat.Style.LONG)
formatter ==> java.text.CompactNumberFormat@952071d5

jshell> formatter.format(10000)
$7 ==> "10 thousand"

jshell> formatter.format(12345)
$8 ==> "12 thousand"

jshell>

なんとLONGだとthousandですよw

ちなみに、ロケールをja_JPにして、LONGにしても表示は変わりません。

 

NumberFormatクラス

前述したように、CompactNumberFormatオブジェクトを取得するためのstaticメソッドが追加されました。

  • static NumberFormat getCompactNumberInstance()
  • static NumberFormat getCompactNumberInstance(Locale locale, NumberFormat.Style formatStyle)

これに伴い、java.text.spi.NumberFormatProviderクラスにもgetCompactNumberInstanceメソッドが追加されています。

 

NumberFormat.Fieldクラス

プレフィックスとサフィックスを表す定数が追加されています。

  • static final NumberFormat.Field PREFIX
  • static final NumberFormat.Field SUFFIX

 

NumberFormat.Style列挙型

こちらも前述したようにCompactNumberFormatクラスの生成時に指定するための列挙型です。

LONGとSHORTの定数が定義されています。

 

java.util.concurrentパッケージ

CompletionStageクラス

exceptionallyメソッドの亜種が5種類増えました。

  • default CompletionStage<T> exceptionallyAsync(Function<Throwable, ? extends T> fn)
  • default CompletionStage<T> exceptionallyAsync(Function<Throwable, ? extends T> fn, Executor executor)
  • default CompletionStage<T> exceptionallyCompose (Function<Throwable, ? extends CompletionStage<T>> fn)
  • default CompletionStage<T> exceptionallyComposeAsync(Function<Throwable, ? extends CompletionStage<T>> fn)
  • default CompletionStage<T> exceptionallyComposeAsync(Function<Throwable, ? extends CompletionStage<T>> fn, Executor executor)

exceptionallyメソッドは前段のステージで例外がスローされた時にコールされるメソッドです。前段で例外がスローされていなければ、exceptionallyメソッドはスキップされて、次段のステージが実行されます。

exceptionallyAsyncメソッドは、その名の通りexceptionallyメソッドと同様の処理を非同期に行うメソッドです。

jshell> import java.util.concurrent.*;
  
jshell> CompletableFuture.runAsync(() -> {
   ...>     System.out.println(Thread.currentThread());
   ...>     throw new RuntimeException();
   ...> }).
   ...> exceptionally(ex -> {
   ...>     System.out.println(Thread.currentThread());
   ...>     return null;
   ...> }).get();
Thread[ForkJoinPool.commonPool-worker-3,5,main]
Thread[main,5,main]
$2 ==> null

jshell> CompletableFuture.runAsync(() -> {
   ...>     System.out.println(Thread.currentThread());
   ...>     throw new RuntimeException();
   ...> }).
   ...> exceptionallyAsync(ex -> {
   ...>     System.out.println(Thread.currentThread());
   ...>     return null;
   ...> }).get();
Thread[ForkJoinPool.commonPool-worker-3,5,main]
Thread[ForkJoinPool.commonPool-worker-3,5,main]
$3 ==> null

jshell>

JShellで実行してみるとexceptionallyメソッドはメインスレッドで実行されていますが、exceptionallyAsyncメソッドはForkJoinPoolが管理しているワーカースレッドで実行されていることが分かります。

exceptionallyメソッドの引数はThrowableオブジェクトを受け取って、何らかの値を返すラムダ式です。これに対してexceptionallyComposeメソッドの場合、返り値の型がCompletionStageクラスになっています。

同じようなメソッドにthenComposeメソッドがありますが、それの例外版だと考えればいいと思います。

で、exceptionallyComposeAsyncメソッドはそれの非同期版です。

 

java.util.streamパッケージ

Collectorsクラス

2種類の終端処理を行って、それをまとめるためのメソッドが追加されました。

  • static <T,R1,R2,R> Collector<T,?,R> teeing(Collector<? super T,?,R1> downstream1, Collector<? super T,?,R2> downstream2, BiFunction<? super R1,? super R2,R> merger)

第1引数と第2引数がそれぞれCollectインタフェースのオブジェクト(実際にはCollectorsのstaticメソッドを使用します)、第3引数が2つの終端処理の結果を引数にとるBiFunctionインタフェースのラムダ式です。

たとえば、文字列を連結する処理と、要素数を数える処理を行い、最後に結果をコロンでつなげた文字列にするには、次のように記述します。

jshell> var text = List.of("a", "b", "c", "d", "e")
text ==> [a, b, c, d, e]

jshell> text.stream().
   ...> collect(Collectors.teeing(Collectors.joining(), 
   ...> Collectors.counting(), 
   ...> (x, y) -> x + " : " + y))
$1 ==> "abcde : 5"

jshell>

これはけっこう便利かもしれません。

 

javax.lang.modelパッケージ

SouceVersionクラス

バージョンアップのたびに定数が増えるのはお約束。

  • static final SourceVersion RELEASE_12

また、このクラスもcondy対応でConstableインタフェースを実装するように変更されています。

 

その他

LDAPのサービスプロバイダー用のパッケージjavax.naming.ldap.spiが追加されました。このパッケージにはLdapDnsProviderクラスと、LdapDnsProviderResultクラスが含まれています。

また、javax.net.sslパッケージのHttpsURLConnectionクラスに、getSSLSessionメソッドが追加されています。

最後にSwing。

ファイルチューザー用のjavax.swing.filechooser.FileSystemViewクラスにgetChooserShortcutPanelFilesメソッドが追加されました。とはいうものの、このクラスを直接使うことはまずないはずです。

 

ということで、標準で提供されているモジュールをすべて合わせても、変更は少ないですね。