JEPでは語れないJava SE 15

恒例になってしまった半年ぶりのblog更新ですw

アメリカ西海岸時間の9月15日にJava SE 15がリリースされます。今年は21日じゃないんですね。ちょっと残念。

Javaとは関係ないのですが、今年から9月21日はセプテンバーの日になってます。分からない人はEarth Wind & Fireでググってみてくださいw

APIに関しては、Java 14でIncubator Moduleとして提案されたJEP 383 Forein-Memory Access APIがSecond Incubatorになっています。うまくいけば、Java 16で正式になって、次のLTSに含まれそうです。

Project Panamaに関してはJEP 389 Forien Linker APIも提案されていて、これがJava 17に入るとJNI要らなくなるんですよね。すでにPanamaで提供されているjextractを使えばJNIはいらないですけど、JEP 389を使えばjextractも要らなくなるはず。

また、JEP 371 Hidden ClassesもAPIに関するJEPです。

これについては、後述します。

追加されるAPIもあれば、削除されるAPIもあります。

Java 15で削除されたのがJavaScriptエンジンのNashorn (JEP 372 Remove the Nashorn JavaScript Engine)。また、Deprecatedになったのが、RMI Activation (JEP 385 Deprecate RMI Activation for Removal)。さすがに、RMIは役目を終えていると思います。

 

JEPに関する変更はまた別の機会に書くとして (書けるかどうかはわからないですけど)、本エントリーはJEPになっていないものも含めてAPIの変更についてまとめます。

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

 

廃止になったAPI

Java 15ではNashornが廃止されましたが、Nashornはjdkではじまるモジュール(jdk.scripting.nashorn)なので、標準API的には変化がありません。

その他の廃止にAPIは定数が1つ、コンストラクタが2つととても少ないです。

フィールド

JMX Remote関連の定数が1つ削除されました。

• javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPES

CREDENTIAL_TYPESの代わりにCREDENTIALS_FILTER_PATTERNを使うようにします。とはいうものの、JMXをRMIで接続するコードを書くことは、自分で監視用ツールを作るということでもない限り使わないでしょうね。

コンストラクタ

Java 14でforRemoval=trueになったコンストラクタが早々と削除されました。

• java.lang.invoke.ConstantBootstraps.<init>
• java.lang.reflect.Modifier.<init>

ConstantBootstrapsクラスはCONDYのブートストラップのためのユーティリティクラスですが、もともとstaticなクラスメソッドしか定義されていないので、コンストラクタがある方がおかしかったわけです。

Modifierクラスもモディファイアの定数と、クラスメソッドのisXXXメソッド群を定義しているクラスなので、コンストラクタは必要ありません。基本的にはClass.getModifiersメソッドやMember.getModifiersメソッドで返されるint値を引数にして、isXXXメソッドでチェックするという使い方です。

このため、これらのコンストラクタが削除されたとしても、影響はないでしょう。

 

廃止予定のAPI

Java 15で追加された廃止予定APIは、前述したRMI Activationに関するものです。

パッケージ

• java.rmi.activation

クラス/インタフェース

• java.rmi.activation.Activatable
• java.rmi.activation.ActivationDesc
• java.rmi.activation.ActivationGroup
• java.rmi.activation.ActivationGroup_Stub
• java.rmi.activation.ActivationGroupDesc
• java.rmi.activation.ActivationGroupID
• java.rmi.activation.ActivationID
• java.rmi.activation.ActivationInstantiator
• java.rmi.activation.ActivationMonitor
• java.rmi.activation.ActivationSystem
• java.rmi.activation.Activator

例外

• java.rmi.activation.ActivateFailedException
• java.rmi.activation.ActivateException
• java.rmi.activation.UnknownGroupException
• java.rmi.activation.UnknownObjectException

 

追加されたAPI

Java 14で追加されたAPIのほとんどがjava.baseモジュールで、その他はjava.compilerモジュールだけです。

しかも、一番追加が多かったパッケージはjava.langパッケージ。とはいうものの、恒例のUnicodeのブロックとスクリプトがあるせいですけど。

java.base/java.langパッケージ

java.langパッケージではクラス定義の変更や、前述したUnicode関連の変更、またJEP関連のメソッド追加があります。

Boolean/Byte/Character/Shortクラス

Java 12でCondyが導入されたため、新しく導入されたのがConstableインタフェースです。すでに、Java 12でIntegerクラスやDoubleクラスなどはConstableインタフェースを実装するように変更されていました。

Boolean/Byte/Character/Shortクラスはその時にもれていたプリミティブ型のラッパークラスで、Java 15でConstableインタフェースを実装するように変更されました。

Constableインタフェースの実装に伴い、以下のメソッドが追加されています。

• describeConstable()

まぁ、普通の開発者は使わないでしょうけど。

CharSequenceインタフェース

Stringクラスでは定義されていたisEmptyメソッドが、CharSequenceインタフェースで定義されるようになりました。

• boolean isEmpty()

isEmptyメソッドはデフォルトメソッドなので、CharSequenceインタフェースの実装クラスは変更なしです。また、その実装はStringクラスのそのままです。

Character.UnicodeBlockクラス

Java 14でサポートしていたUnicodeのバージョンは12.1ですが、Java 15ではUnicode 13をサポートするようになりました。

Unicode 13といえば、最近セブンイレブンでも売り出して話題のビャンビャン麺のビャンの文字が入るわけです。現時点で最も画数の多い漢字ですw

それはそうと、Unicodeのバージョンがあがると、当然のごとくブロックとスクリプトが追加されます。

追加されたブロックを示す定数は以下の8種類です。

• CHORASMIAN
• CJK_UNIFIELD_IDEOGRAPHS_EXTENSION_G
• DIVES_AKURU
• KHITAN_SMALL_SCRIPT
• LISU_SUPPLEMENT
• SYMBOLS_FOR_LEGACY_COMPUTING
• TANGUT_SUPPLEMENT
• YEZIDI

Character.UnicodeScript列挙型

スクリプトの定数は4種類追加されました。

• CHORASMIAN
• DIVES_AKURU
• KHITAN_SMALL_SCRIPT
• YEZIDI

Classクラス

Clsssクラスには2つのJEPに関連するメソッドが追加されました。

• boolean isHidden()
• boolean isSealed()
• ClassDesc[] permittedSubclasses()

isHiddenメソッドがJEP 371 Hidden Classに関連したメソッドで、他の2メソッドがJEP 360 Sealed Classes関連のメソッドです。

isHiddenメソッドは、クラスがHidden Classかどうかを調べるメソッドです。Hidden Classについては、後述するMethodHandlesクラスの時に説明します。

ここでは、Sealed Classについて簡単に説明しておきましょう。

Sealed Classは継承を限定できるクラスです。

Sealed Classを定義するにはclassの前にsealedをつけ、派生させるクラスをpermitsの後に列挙します。

たとえば、Shpaeクラスを派生できるのはCircleクラスとRectangleクラスだけとしましょう。

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

jshell> sealed class Shape permits Circle, Rectangle {}
|  次を作成しました: クラス Shape。しかし、 class Circle, and class Rectangleが宣言されるまで、参照できません

jshell> final class Circle extends Shape {}
|  次を作成しました: クラス Circle。しかし、 class Shapeが宣言されるまで、参照できません

jshell> final class Rectangle extends Shape {}
|  次を作成しました: クラス Rectangle

jshell> final class Triangle extends Shape {}
|  エラー:
|  クラスはシール・クラスShapeを拡張できません
|  final class Triangle extends Shape {}
|  ^-----------------------------------^

jshell>

ShapeクラスはCircleクラスとRectangleクラスのみ派生できるように定義したので、それ以外のTriangleクラスを派生させようとしてもコンパイルエラーになります。

なぜ、こんな機能が必要かというと、今後導入されるswitch式でのパターンマッチングなどに使えるからです。派生クラスが制限されていれば、default句が必要なくなるからです。

ちなみに、CircleクラスやRectangleクラスがfinal classなのは、Circleクラスをさらに派生させたクラスを作成できてしまうとsealする意味がなくなってしまうからです。

ただし、final classではなく、多重にsealed classにすることはできます。

さて、ここまでくれば、isSealedメソッドがSealed Classかどうかを調べるクラスだということはすぐにわかりますね。

jshell> Shape.class.isSealed()
$4 ==> true

jshell> Circle.class.isSealed()
$5 ==> false

jshell>

ShapeクラスはisSealedメソッドでtrueが返りますが、Circleクラスはfalseになります。

もう1つのpermittedSubclassesメソッドはSelaed Classを派生できるクラスの一覧を返すメソッドです。

jshell> Shape.class.permittedSubclasses()
$6 ==> ClassDesc[2] { ClassDesc[Circle], ClassDesc[Rectangle] }

jshell>

Sealed Classではない普通のクラスでpermittedSublassesメソッドをコールすると、空の配列が帰ります。

まぁ、Sealed Classを使うことはあっても、普通はpermittedSubclassesメソッドを使わないでしょうけど。

Mathクラス/StrickMathクラス

2つのクラスとも同じメソッドが追加されました。

• static int absExact(int a)
• static long absExact(long a)

どちらも実装は同じです。

普通のabsと何が違うかというと、引数がMIN_VALUEの時にArithmeticException例外がスローされるというところです。

 

java.base/java.lang.constantパッケージ

Java 12で追加されたcondy関連のパッケージですが、このパッケージのクラス群もよっぽどのことがないかぎり使わないと思います。とりあえず、追加されたところだけさらっと流します。

ConstantDescsクラス

ConstantDescsクラスはプリミティブ型などの定数に対するXXXDescを示す定数が定義されているクラスです。そこに、4種類の定数が追加されました。

• DirectMethodHandleDesc BSM_EXPLICIT_CAST
• DirectMethodHandleDesc BSM_GET_STATIC_FINAL
• DynamicConstantDesc<Boolean> FALSE
• DynamicConstantDesc<Boolean> TRUE

 

java.base/java.lang.invokeパッケージ

indy/condy関連のパッケージですが、JEP 371 Hidden Classに関するAPIが追加されています。

ConstantBootstrapsクラス

削除されたAPIのところで、コンストラクタが削除されたと書いたConstantBootstrapsクラスです。

ConstantBootstrapsクラスだけはHidden Classとは関係ないメソッドが追加されています。ConstantDescsクラスで追加された定数に対応するメソッドです。

• Object explicitCast(MethodHandles.Lookup lookup, String name, Class<?> dstType, Object value)

ようするにキャストをcondyで行う時のブートストラップです。これはMethodHandleクラスを使えば記述できるのですが、それを簡単に書けるようにしただけのメソッドです。

MethodHandles.Lookupクラス

LookupクラスはindyやcondyでメソッドなどをルックアップするためのfindXXXメソッドを定義しています。

他にラムダ式のように動的に生成したクラスを定義するためにdefineClassメソッドなどがあります。このdefineClassメソッドと同様なメソッドがHidden Class関連で追加されています。

• MethodHandles.Lookup defineHiddenClass(byte[] bytes, boolean initialize, MethodHandles.Lookup.ClassOption... options)
• Class<?> ensureInitialized(Class<?> targetClass)

defineClassメソッドのHidden Class版がdefineHiddenClassメソッドです。

defineClassメソッドでロードされたクラスは普通のクラスと同様に扱えますが、Hidden Classはその名の通り隠されたクラスなので普通のクラスとはいくつかの違いがあります。

たとえば、匿名クラスと違って名前があるとか、リフレクションでしかアクセスできないなどです。また、初期化は第2引数がtrueの場合にしか行いません。

後から初期化を強制的に行うようにするのが、ensureInitialziedメソッドです。返り値が初期化を行ったClassオブジェクトになります。

とはいうものの、これらのメソッドを使うことはないだろうなぁ...

MethodHandles.Lookup.ClassOption列挙型

LookupクラスのdefineHiddenClassメソッドで使用するenumが新規追加されました。

定義している定数は次の2種類です。

• NESTMATE
• STRONG

NESTMATEはネストしたクラスとしてHidden Classを扱うために使います。STRONGはクラスローダーと強い関係を持たせる場合です。強い関係というのは普通のクラスと同様にクラスローダーがGCされた時に、Hidden Classもアンロードされるということらしいです。

 

java.base/java.lang.reflectパッケージ

java.lang.reflectパッケージはリフレクションに関する情報を扱うために使用します。

AnnotatedTypeインタフェース

AnnotatedTypeインタフェースはアノテーションで修飾された型の情報を扱うためのインタフェースですが、メソッドが3つ追加されました。

• <T extedns Annotation> T getAnnotation(Class<T> annotationClass)
• Annotation[] getAnnotations()
• Annotation[] getDeclaredAnnotation()

これらのメソッドはデフォルトメソッドではなくて、普通のメソッドです。そんなことしたら、実装クラスが... と思うかもしれませんが、まったく問題ありません。というのも、これらのメソッドはAnnotatedTypeインタフェースの親インタフェースのAnnotatedElementインタフェースで定義されているメソッドだからです。

それを、なぜ今さらAnnotatedTypeインタフェースに定義しなおしたんですかねぇ。よくわかりません 🤔

 

java.base/java.nioパッケージ

java.langパッケージのサブパッケージは普通の開発者は、まず触れないパッケージでしたけど、ここからは使うかもしれないパッケージです。

CharBufferクラス

Bufferクラスのサブクラスはいろいろありますが、その中のCharBufferクラスだけメソッドが追加されました。

• boolean isEmpty()

StringクラスのisEmptyメソッドはlengthが0かどうかをチェックしますが、CharBufferクラスはちょっと違います。remainingが0かどうかをチェックします。

Bufferクラスのremainingはpositionとlimitの間にある要素数なので、読み込みを行った後、残りが空かどうかを調べるという使い方になります。

jshell> import java.nio.*

jshell> var buffer = CharBuffer.allocate(10)
buffer ==>

jshell> buffer.isEmpty()
$3 ==> false

jshell> buffer.append("ABC")
$4 ==>

jshell> buffer.isEmpty()
$5 ==> false

jshell> buffer.position(0)
$6 ==> ABC

jshell> buffer.isEmpty()
$7 ==> false

jshell> buffer.position(10)
$8 ==>

jshell> buffer.isEmpty()
$9 ==> true 

jshell>

CharBufferオブジェクトをアロケートしただけで、中身は空だとしても$3のようにisEmptyメソッドはfalseを返します。この時、positionは0、limitは10だからです。

結局、最後に示したようにpositionを10に進めると、isEmptyメソッドがtrueを返します。ほんとに文字があるかどうかではないので、注意が必要です。

 

java.base/java.nio.channelsパッケージ

NIOのチャネルもメソッドが追加されています。

SocketChannelクラス

ソケットチャネルにオープンのメソッドが追加でオーバーロードされました。

• static SocketChannel open(ProtocolFamily family)

引数の型のjava.net.ProtocolFamilyインタフェースはプロトコルのファミリーを表すわけですが、このままだとなんだかよくわかりません。実際に使用するのはProtocolFamilyインタフェースを実装したStandardProtocolFamily列挙型です。

このenumではINETとINET6という定数が定義されています。ようするに、IPv4かIPv6かということです。

今までSocketChannelクラスでは、使用されているIPアドレスによってIPv4とIPv6を自動的に使い分けていたのですが、新たにオーバーロードされたopenメソッドはそれを明示的に行うということです。

 

ServerSocketChannelクラス

ServerSocketChannelクラスもopenメソッドがオーバーロードされています。

• static ServerSocketChannel open(ProtocolFamily family)

返り値の型が違うだけで、SocketChannelクラスと一緒ですね。

 

java.base/java.nio.channels.spiパッケージ

java.nio.channels.spiパッケージはNIOのチャネルのプロバイダを定義しているパッケージですが、ここでもProtocolFamilyインタフェースに関連するメソッドが追加されました。

SelectorProviderクラス

通信を多重化して扱うSelectableChannelクラスのプロバイダがSelectorProviderクラスです。追加されたのは、SocketChannel/ServerSocketChannelクラスで追加されたopenメソッドと同様のメソッドです。

• SocketChannel openSocketChannel(ProtocolFamily family)
• ServerSocketChannel openServerSocketChannel(ProtocolFamily family)

 

java.base/java.utilパッケージ

java.utilパッケージに何が追加されたのかと思うかもしれませんが、肩透かしですw

NoSuchElementException例外

なんで今さら、コンストラクタが追加されたのかとても謎なのですが...

• NoSuchElementException(String s, Throwable cause)
• NoSuchElementException(Throwable cause)

 

java.compiler/javax.lang.modelパッケージ

毎度毎度のjavax.lang.modelパッケージです。

SourceVersion列挙型

Java 15に対応する定数が追加されました。

• RELEASE_15

 

java.compiler/javax.lang.model.elementパッケージ

java.compilerモジュールなので、普通の開発者はまず使わないとは思いますが...

Elementインタフェース

javax.lang.reflectパッケージのAnnotatedTypeインタフェースが変更されたのと同じく、Elementインタフェースもアノテーション関連のメソッドが追加されました。

• <A extends Annotation> A[] getAnnotationsByType(Class<A> annotationType)

 

Modifier列挙型

クラスなどを修飾する要素を定数として定義するModifier列挙型に、JEP 360 Sealed Classesに関する定数が2つ追加されました。

• NON_SEALED
• SEALED

 

TypeElementインタフェース

TypeElementインタフェースはクラスもしくはインタフェースに関する要素を取得するために使用するインタフェースです。ここでも、JEP 360 Sealed Classesに関連してSealed Classで派生することが許されているクラスの一覧を取得するメソッドが追加されています。

• List<? extends TypeMirror> getPermittedSubclasses()

 

ここで示した機能追加以外にセキュリティ関連でメソッドが追加されていることと、Project PanamaのForeign-Memory Access APIが追加されています。

Forein-Memory Access APIはSecond Incubatorで、何も問題がなければJava 16で正式なAPIになると思います。Forein-Memory Accessもそうですが、Forein-Function Interface関連はいろいろとおもしろいので、機会があれば取り上げてみようと思います。

それにしても、Java 15で追加された機能のうち、普通の開発者が使いそうなAPIはSealed Class関連とjava.nio.CharBufferクラスのメソッド追加ぐらいなのがちょっと寂しいですね。

JEPでは語れないJava SE 14

Javaのアップデートでしか更新しないようになってしまいましたが、半年ぶりのblog更新ですw

ということで、アメリカ西海岸時間の3月17日にJava SE 14がリリースされます。

今回もJEPに含まれていないAPIの変更をメインにJava 14についてまとめていきます。

とはいうものの、Java 14は16もJEPがあります。特にProject Amberがらみの文法変更や、ZGCがWindowsとOS Xに対応したことなどが注目されてますね。

そして、久しぶりにIncubator ModuleがJEPで提案されました!!

Project Panamaで策定されているForeign Funtion Interfaceに関連するモジュールで、ヒープではないメモリへのアクセスを行うためのAPIです。

JEPに関する変更はまた別の機会に書くとして、本エントリーはJEP以外のAPIの変更についてです。

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

 

廃止になったAPI

Java 14ではPack200関連の3つのクラスが廃止されました。

これらは、Java 11で@DeprecatedのforRemovalがtrueになったクラスです。

• java.util.jar.Pack200
• java.util.jar.Pack200.Packer
• java.util.jar.Pack200.Unpacker

クラス3つといっても、実際にはPack200クラスの内部クラスも含んでいます。Pack200はもう役目を終えましたね。

もう1つ、セキュリティのACL (Access Control List)関連のパッケージが廃止されました。

こちらは、Java 10でforRemovalがtrueになったものです。

• java.security.acl

java.security.aclパッケージに含まれていたインタフェース/例外は以下の通り。

• java.security.acl.Acl
• java.security.acl.AclEntry
• java.security.acl.Group
• java.security.acl.Owner
• java.security.acl.Permission
• java.security.acl.AclNotFoundException
• java.security.acl.LastOwnerException
• java.security.acl.NotOwnerException

これらのAPIはjava.security.Policyで置き換えができるはずです。

 

廃止予定のAPI

Java 14で追加された廃止予定APIは以下の通り。

メソッド

• java.lang.Thread.resume
• java.lang.Thread.suspend
• java.lang.ThreadGroup.allowThreadSuspension
• java.lang.ThreadGroup.resume
• java.lang.ThreadGroup.suspend

コンストラクタ

• java.lang.invoke.ConstantBootstraps
• java.lang.reflect.Modifier
• javax.tools.ToolProvider 

ThreadクラスとThreadGroupクラスのresumeメソッド、suspendメソッドは使うのははばかられていたので、廃止されてくれた方が分かりやすくていいですね。

ConstantBootstrapsクラスはCONDYのブートストラップのためのユーティリティクラスですが、もともとstaticなクラスメソッドしか定義されていないので、コンストラクタがある方がおかしかったわけです。

Modifierクラスもモディファイアの定数と、クラスメソッドのisXXXメソッド群を定義しているクラスなので、コンストラクタは必要ありません。基本的にはClass.getModifiersメソッドやMember.getModifiersメソッドで返されるint値を引数にして、isXXXメソッドでチェックするという使い方です。

ToolProviderクラスも同じくクラスメソッドしか定義していないので、コンストラクタがあるのがおかしかったわけです。

 

追加されたAPI

Java 14で追加されたAPIはjava.baseモジュール、java.compilerモジュール、java.xmlモジュールの3つです。とはいうものの、ほとんどがjava.baseモジュールです。

java.base/java.ioパッケージ

java.ioパッケージではメソッドの追加が2、アノテーションの追加が1つありました。

PrintStreamクラス

なぜ今になって追加されたのか全然理解できませんが、2つのメソッドが追加されました。

• write(byte[] buf)
• writeBytes(byte[] buf)

いずれも、内部ではthis.write(buf, 0, buf.length)をコールしています。唯一の違いは、writeメソッドがIOException例外をスローするのに対し、writeBytesメソッドは例外をスローしないという点です。

Serialアノテーション

古のJavaではオブジェクトをシリアライズ/デシリアライズする時にSerializableインタフェースを実装する必要がありました。しかし、Serializableインタフェースはマーカーインタフェースでメソッドは定義されていません。もし、シリアライズ/デシリアライズする時に特別な処理が必要な場合はwriteObject/readObjectメソッドなどを定義する必要があります。

@Serialアノテーションはそれを補うため、シリアライズ/デシリアライズに関連したメソッド/定数を修飾するために使われます。

@Serialアノテーションを使用すべきメソッドは下記の5種類です。

• private void writeObject(java.io.ObjectOutputStream stream) throws IOException
• private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
• private void readObjectNoData() throws ObjectStreamException
• ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
• ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException

定数は次の2種類。

• private static final ObjectStreamField[] serialPersistentFields
• private static final long serialVersionUID

Javadocにはここであげたメソッド/定数以外に@Serialアノテーションを使うことはセマンティックエラーだと書いてあるのですが、今のところコンパイル時にチェックすることはやっていないような気が... 今後のバージョンではコンパイル時のチェックに使われるのでしょうか?

 

java.base/java.langパッケージ

Java 14では新しいRecords型がプレビュー機能で導入されますが、それに伴ってAPIにも変更がありました。

Classクラス

後述しますが、Records型をリフレクションで扱うためのクラスが導入されており、Classクラスはそれに対応したメソッドが追加されています。

• RecordComponent[] getRecordComponents()
• boolean isRecord()

Records型とはいっていますが、実際にはちょっと特殊なクラスというだけなので、Classクラスで扱うことができます。isRecordメソッドはクラスがRecords型かどうかをチェックするためのメソッドですね。

もう1つのgetRecordComponentsメソッドはRecords型で定義されたフィールドを取り出すためのメソッドです。名前から分かると思いますが、RecordComponentクラスがRecords型で定義されたフィールドの情報を保持するクラスです。

jshell> record Data(int x, int y) {}
|  次を作成しました: レコード Data

jshell> var clzz = Data.class
clzz ==> class Data

jshell> var comps = clzz.getRecordComponents()
comps ==> RecordComponent[2] { int x, int y }

jshell> Stream.of(comps).forEach(System.out::println)
int x
int y

jshell>

Records型のDataはint xとint yを定義しているので、getRecordComponentsメソッドの返り値は要素が2つの配列になります。

そのまま出力してみると、フィールドの型と名前が表示されました。

RecordComponentクラスに関しては後ほどもうちょっと説明を加えます。

 

Recordクラス

ClassクラスのところでRecords型はちょっと特殊なクラスと言いましたが、Records型のスーパークラスとなるのがRecordクラスです。列挙型のスーパークラスがEnumクラスだというのと同じようなものですね。

たとえば、Records型のDataで試してみます。

C:\sample>cat Data.java
public record Data(int x, int y) {}

C:\sample>javac --enable-preview --release 14 Data.java
注意:Data.javaはプレビュー言語機能を使用します。
注意:詳細は、-Xlint:previewオプションを指定して再コンパイルしてください。

C:\sample>

Records型はまだプレビュー機能なので、コンパイルに--enable-previewオプションが必要です。また、Java 14以前では使えないので、--release 14を指定しておく必要があります。

これでData.classファイルが生成されたので、javapしてみましょう。

C:\sample>C:\sample>javap -p Data
Compiled from "Data.java"
public final class Data extends java.lang.Record {
  private final int x;
  private final int y;
  public Data(int, int);
  public java.lang.String toString();
  public final int hashCode();
  public final boolean equals(java.lang.Object);
  public int x();
  public int y();
}

C:\sample>

DataクラスがRecordクラスを派生させたクラスであることが分かります。また、xとyがフィールドとして宣言され、アクセッサ―メソッドも生成されています。

後は、おなじみのコンストラクタ、equalメソッド、hashCodeメソッド、toStringメソッドが作られていることも分かります。

ついでなので、もうちょっと見てみましょう。

C:\sample>javap -p -c Data
Compiled from "Data.java"
public final class Data extends java.lang.Record {
  private final int x;

  private final int y;

  public Data(int, int);
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Record."<init>":()V
       4: aload_0
       5: iload_1
       6: putfield      #7                  // Field x:I
       9: aload_0
      10: iload_2
      11: putfield      #13                 // Field y:I
      14: return

  public java.lang.String toString();
    Code:
       0: aload_0
       1: invokedynamic #18,  0             // InvokeDynamic #0:toString:(LData;)Ljava/lang/String;
       6: areturn

  public final int hashCode();
    Code:
       0: aload_0
       1: invokedynamic #22,  0             // InvokeDynamic #0:hashCode:(LData;)I
       6: ireturn

  public final boolean equals(java.lang.Object);
    Code:
       0: aload_0
       1: aload_1
       2: invokedynamic #26,  0             // InvokeDynamic #0:equals:(LData;Ljava/lang/Object;)Z
       7: ireturn

  public int x();
    Code:
       0: aload_0
       1: getfield      #16                 // Field x:I
       4: ireturn

  public int y();
    Code:
       0: aload_0
       1: getfield      #17                 // Field y:I
       4: ireturn
}

C:\sample>

バイトコードを眺めていると、コンストラクタとアクセッサ―メソッドはフィールドに対してのアクセスを行っているだけということが分かります。

おもしろいのが、equalsメソッドなどがINDYで実装されていることです。後述しますが、これに関連したクラスが追加されています。

ちなみに、Recordクラスを派生させたクラスを自作することはできません。

jshell> class Data extends Record {}
|  エラー:
|  クラスは直接java.lang.Recordを拡張できません
|  class Data extends Record {}
|  ^--------------------------^

jshell>

 

StrictMathクラス

StrictMathクラスには6つのメソッドが追加されました。

• static int decrementExact(int a)
• static long decrementExact(long a)
• static int incrementExact(int a)
• static long incrementExact(long a)
• static int negateExact(int a)
• static long negateExact(long a)

decrementExtractメソッドは引数の値を1減算するためのメソッド、incrementExactメソッドは1加算、negateExactメソッドが符号の反転を行うメソッドです。もし、int/longをオーバーフローする場合はArithmeticException例外をスローします。

jshell> int x = 0
x ==> 0

jshell> StrictMath.decrementExact(x)
$10 ==> -1

jshell> int y = Integer.MIN_VALUE
y ==> -2147483648

jshell> StrictMath.decrementExact(y)
|  例外java.lang.ArithmeticException: integer overflow
|        at Math.decrementExact (Math.java:1006)
|        at StrictMath.decrementExact (StrictMath.java:879)
|        at (#12:1)

jshell>

内部的にはMathクラスのdecrementExactメソッドをコールしているだけです。逆にいうと、Mathクラスに定義してあるのにStrictMathクラスにはなかったメソッドを追加したという感じでしょうか。

NullPointerException例外

これまでThrowable例外で定義されていたメソッドがオーバーロードされました。

• String getMessage()

「なぜ今になってgetMessageメソッドが」と思うかもしれません。その理由はJEP 358 Helpful NullPointerExceptionsにあります。試してみれば、今までよりは分かりやすいメッセージになっているはずですよ。

 

java.base/java.lang.annotationパッケージ

ElementType列挙型

Records型が導入されたので、ElementType列挙型の定数も追加されています。

• RECORD_COMPONENT

ElementType列挙型はTargetアノテーションの引数に使用します。Targetアノテーションはアノテーションを自作する時に使い、自作するアノテーションが何を修飾するものなのかを示します。

Records型のコンポーネントを修飾するアノテーションを作るときに、この定数を使うわけですね。

 

java.base/java.lang.invokeパッケージ

MethodHandles.Lookupクラス

普通に使う人には、どう考えても使わないクラスだと思いますが...

INDYで動的にコールするメソッドを定義する時に使用されるのがMethodHandleクラスです。そのMethodHandleオブジェクトをルックアップする時に使われるのが、MethodHandles.Lookupクラスです。ラムダ式などで使われています。

このLookupクラスに追加されたのが、以下の2メソッドです。

• boolean hasFullPrivilegeAccess()
• Class<?> previousLookupClass()

Lookupオブジェクトにはアクセス権が設定されています。この中で、privateアクセスされるかどうかをチェックするのがhasPrivateAccessメソッドです。

このhasPrivateAccessメソッドはJava 14でDeprecatedになりました(forRemovalは設定されていません)。

その代わりに追加されたのが、hasFullPrivilegeAccessメソッドです。

hasFullPrivilegeAccessメソッドはprivateアクセスとmoduleアクセスされるかどうかをチェックするメソッドです。

一方のhasPrivateAccessメソッドも動作が変更になり、privateアクセスとmoduleアクセスの両方をチェックするメソッドになりました(内部ではhasFullPrivilegeAccessメソッドをコールしています)。

さて、もう1つの方のpreviousLookupClassメソッドですが、Java 14でLookupクラスはクロスモジュールルックアップがサポートされたことに関連しています。

クロスモジュールルックアップは複数のモジュールに分かれている時に使われます。Javadocに記載されている例を見てもらうのが一番分かりやすいでしょうか。

    Lookup lookup = MethodHandles.lookup();   // in class C
    Lookup lookup2 = lookup.in(D.class);
    MethodHandle mh = lookup2.findStatic(E.class, "m", MT);

このlookup2変数が呼び出し元のlookup変数を返すために使われるのがpreviousLookupClassメソッドです。まぁ、そんなもんかと思っていただければいいかなw

 

java.base/java.lang.reflectパッケージ

RecordComponentクラス

前述したようにRecords型の導入に伴ってリフレクションでRecords型を扱うためのクラスがRecordComponentクラスです。Records型自身はClassクラスで扱えるので、Records型で定義するコンポーネントにリフレクションでアクセスするためのクラスです。

RecordComponentクラスは、他のリフレクション用のクラスと同様にAnnotatedElementインタフェースの実装クラスです。

定義されているメソッドは以下の通り。

• Method getAccessor()
• AnnotatedType getAnnotatedType()
• <T extends Annotation> T getAnnotation(Class<T> annotationClass)
• Annotation[] getAnnotations()
• Annotation[] getDeclaredAnnotations()
• Class<?> getDeclaringRecord()
• String getGenericSignature()
• Type getGenericType()
• String getName()
• Class<?> getType()
• String toString()

アノテーションに関するメソッドはAnnotatedElementインタフェースで定義されているメソッドです。

getNameメソッドやgetTypeメソッドはその名のとおりですね。おもしろいのが、自動生成されるアクセッサ―メソッドを取得するgetAccessorメソッドや、コンポーネントを定義しているRecords型を取得するgetDeclaringRecordメソッドが定義されているところなどですね。

getGenericSignatureメソッドはジェネリクス化されたコンポーネントの場合、そのシグネチャを文字列で返します。ジェネリクス化されていないとnullが返るようです。

getGenericTypeメソッドはコンポーネントの型を返します。ジェネリクスなコンポーネントであれば型パラメータも一緒に取得できます。ジェネリクスでなければgetTypeと同じ結果になります。

jshell> record Data(String text) {}
|  次を作成しました: レコード Data

jshell> var clz = Data.class
clz ==> class Data

jshell> var component = clz.getRecordComponents()[0]
component ==> java.lang.String text

jshell> System.out.println(component.getDeclaringRecord())
class REPL.$JShell$11$Data

jshell> System.out.println(component.getName())
text

jshell> System.out.println(component.getType())
class java.lang.String

jshell> System.out.println(component.getGenericSignature())
null

jshell> System.out.println(component.getGenericType())
class java.lang.String

jshell> record Data2(List<String> texts) {}
|  次を作成しました: レコード Data2

jshell> var clz2 = Data2.class
clz2 ==> class Data2

jshell> var comp2 = clz2.getRecordComponents()[0]
comp2 ==> java.util.List texts

jshell> System.out.println(comp2.getGenericSignature())
Ljava/util/List<Ljava/lang/String;>;

jshell> System.out.println(comp2.getGenericType())
java.util.List<java.lang.String>

jshell> System.out.println(comp2.getType())
interface java.util.List

jshell>

Stringクラスのコンポーネントの場合、getGenericSignatureメソッドはnullを返しています。また、getGenericTypeメソッドとgetTypeメソッドは両方ともjava.lang.Stringを返していることが分かります。

一方、List<String>クラスのコンポーネントだと、getGenericSignatureメソッドがLjava/util/List<Ljava/lang/String;>;になっています。シグネチャの読み方ですが、Lは参照型を表していて、そのクラスがLと;に挟まれた部分になっています。なので、これはList<String>を表しています。

これはgetGenericTypeメソッドで返る値と同じです。

一方でgetTypeメソッドは型パラメータがないListになっていることが分かります。

 

java.base/java.lang.runtimeパッケージ

なんとパッケージが1つ追加されていました。今のところ定義されているクラスは1つです。

ObjectMethodsクラス

ObjectMethodsクラスが定義しているメソッドは1つ。このメソッドを見ると、このクラスが何のためのクラスか分かりますw

• static Object bootstrap(MethodHandles.Lookup lookup, String methodName, TypeDescriptor type, Class<?> recordClass, String names, MethodHandle... getters)

bootstrapメソッドといえばINDYです。

Javadocを見ると、Object.equals/hashCode/toStringの3メソッドを生成するとあります。この3つのメソッドというと、先ほどのRecords型で生成されたメソッドがINDYを使っていましたね。どうやら、Records型のクラスを定義すると、このbootstrapメソッドで実行時にこれらのメソッドを生成するようです。ちゃんと追っていないので、もしかしたら違うかもしれませんが 😅

 

java.base/java.textパッケージ

CompactNumberFormatクラス

CompactNumberFormatクラスにコンストラクタが1つ追加されました。

• CompactNumberFormat(String decimalPattern, DecimalFormatSymbols symbols, String[] compactPatterns, String pluralRules)

これまでのコンストラクタと比べると、最後のpluralRulesが追加されています。Plural RuleはUnicodeで決められているLanguage Plural Rulesのことです。記述のしかたもUnicodeのドキュメントを見てください。

とはいうものの、CompactNumberFormatオブジェクトを自分でコンストラクタを使って生成することは、ほぼないと思うんですよね。

 

java.base/java.util.concurrent.locksパッケージ

LockSupportクラス

ロックのサポートのためのLockSupportクラスですが、スレッドのスケジューリングを行うためカレントスレッドを無効にするparkメソッドがあります。

parkメソッドには引数でブロッカーを指定することもできるのですが、引数なしのオーバーロードもあります。

引数なしのparkメソッドをコールする前に、ブロッカーを設定するためのメソッドが追加されました。

• statci void setCurrentBlocker(Object blocker)

 

java.compiler/javax.lang.modelパッケージ

SourceVersion列挙型

毎度のことですが、定数が追加されています。

• RELEASE_14

 

java.compiler/javax.lang.model.elementパッケージ

ElementKind列挙型

パターンマッチングとRecords型に対応するため定数が追加になっています。

• BINDING_VARIABLE
• RECORD
• RECORD_COMPONENT

BINDING_VARIABLEがinstanceofを使ったパターンマッチングに対応しています。

 

RecordComponentElementインタフェース

こちらもRecords型に対応するために追加されたインタフェースです。定義されているメソッドは3つ。

• ExecutableElement getAccessor()
• Element getEnclosingElement()
• Name getSimpleName()

getAccessorメソッドがコンポーネントのアクセッサ―メソッドに対する要素を返します。getEnclosingElementメソッドはコンポーネントを定義しているRecord型の要素を返します。

 

TypeElementインタフェース

こちらもRecords型に対応するためにメソッドが追加されました。

• List<? extends RecordComponentElement> getRecordComponents()

 

java.compiler/javax.lang.model.utilパッケージ

javax.lang.model.utilパッケージではコンパイル時に使用するプログラム要素の扱うためのビジターなどをいろいろと定義しているパッケージです。こちらもRecords型導入にともなってビジターなどが追加されています。

追加されたクラスだけを列挙しておきます。

• AbstractElementVisitor14
• AbstractTypeVisitor14
• ElementKindVisitor14
• ElementScanner14
• SimpleAnnotationValueVisitor14
• SimpleElementVisitor14
• SimpleTypeVisitor14
• TypeKindVisitor14

 

java.xml/org.xml.saxパッケージ

ContentHandlerインタフェース

XMLのSAXパーサーで使用するContentHandlerインタフェースにメソッドが追加されました。。

• void declaration(String version, String encoding, String standalone) throws SAXException)

逆に、今までなぜdeclarationを受け取るメソッドがなかったのかの方が不思議ですね。

ちなみに、このメソッドはdefaultメソッドで定義されていますが、defaultメソッドでは何も行っていません。

 

ということで、Java 14のAPIの変更をまとめてみました。Records型導入による追加が大きいですね。逆にいうと、それ以外のAPI追加はほとんどないのがちょっと寂しい...

 

Java SE 13: Unmentioned in JEPs

Java SE 13 was released on 17th Sep.

In that day, Oracle Code One was held in San Francisco, and Brian Goetz talked about new features of Java SE 13 in Code One keynote.

However, new features of Java 13 are a little. Only 5 JEPs are introduced in Java SE. There are no JEP about library.

2 JEPs are about language specification: one is switch expression (JEP 354) and other is text block (JEP 355).

switch expression was introduced as preview feature in Java 12. It was discussed again, and was re-proposed in Java 13.

Text block is originally JEP 326 Raw String Literal. Text block is also preview feature.

 

In this entry, I'll explain new features, mainly API updates. These are unmentioned in JEPs.

But, I have enough knowledge about security APIs, so I'll skip these updates.

 

Removed APIs

2 methods were removed in Java SE 13.

These are the methods that forRemoval of @Deprecated set true from Java SE 9.

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

As you can see in these methods Javadoc, descriptions of the methods are "Not implemented, does nothing." I don't know why the methods didn't removed until Java 13.

 

APIs Proposed for Removal

Many APIs are poposed for removal in Java 13. I listed APIs that forRemoval of @Deprecated were true.

Package

• javax.security.cert

Classes

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

Exceptions

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

Methods

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

With removal of javax.security.cert package, we should use java.security.cert package instead of javax.security.cert package.

3 methods of String class are new methods in Java 13. However, forRemoval variables are true. Why?

The answer is that these methods are associated with text bloch feature. Because text bloch is preview feature, these methods may be changed when text bloch becames official feature.

3 methods of String class are explained after.

2 methods of javax.net.ssl package are also associated with javax.security.cert package. Return type of HandshakeCompletedEvent.getPeerCertificateChain method is array of X509Certificate class. Insted of getPeerCertificateChain method, we can use getPeerCertificates method that return type is array of Certificate class.

In the same way, we can use SSLSession.getPeerCertificates method instead of getPeerCertificateChain method.

 

New APIs

java.lang package

Java SE 13 supports Unicode 12.1, but the feature is not defined by JEP. In relation to Unicode 12.1 support, some constants are added to 2 classes.

Unicode version supported in Java SE is described in javadoc of java.lang.Character class.

Here is the Character class javadoc of Java SE 13: "Character information is based on the Unicode Standard, version 12.1"

 

Character.UnicodeBlock class

As the name suggests, UnicodeBlock class defines Unicode blocks. UnicodeBlock class adds 9 constants introduced in Unicode 12.0.

• 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 enum also defines 4 scripts introduced in Unicode 12.0.

• ELYMAIC
• NANDINAGARI
• NYIAKENG_PUACHUE_HMONG
• WANCHO

 

String class

As mentioned before, String class defines 3 new methods associated with text block. We can use the methods, but javac compiler alerts for using them.

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

format method of String class is a static method introduced in J2SE 5, while on the other hand formatted method is a instance method.

jshell>  import java.time.*

jshell> "%s%n".formatted(LocalDate.now())
|  Warning:
|  formatted(java.lang.Object...) in java.lang.String has been deprecated and marked for removal
|  "%s%n".formatted(LocalDate.now())
|  ^--------------^
$1 ==> "2019-09-17\r\n"

jshell>

Both format method and formatted method call format method of java.util.Formatter class internally.

stripIndent method removes line head white-spaces, when text is multi line and meaningless line head white-space.

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
|  Warning:
|  stripIndent() in java.lang.String has been deprecated and marked for removal
|  System.out.println(text.stripIndent())
|                     ^--------------^

jshell>

When you use text bloch, line head white-spaces are removed automatically.

translateEscapes translate escape sequence into Unicode. For example, "\n" consisting of 2 character is translated into U+000A.

We don't use this method usually, and text block feature uses stripIndent and translateEscape methods.

 

java.nio package

Classes associated with Buffer class are added some methods.

 

Buffer class

Buffer class defined overloaded slice method.

• Buffer slice(int index, int length)

Existing slice method has no argument, and cuts buffer from current position to limit.

New slice method cut by index and length argument explicitly.

I used both methods with JShell as below:

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>

I used ByteBuffer class because Buffer class is abstract class. We can also use new slice method of other concrete classes such as CharBuffer class.

 

ByteBuffer/CharBuffer/DoubleBuffer/FloatBuffer/IntBuffer/LongBuffer/ShortBuffer class

Each class is added new overloaded get methods put methods.

I explaine the case of ByteBuffer class, but usage is all same.

• 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)

Existing get methods reads bytes from current position, or reads 1 byte from specified index. New overloaded get methods read bytres into byte array from specified index.

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>

Above code reads two bytes from ByteBuffer object.

In the same way, put methods write bytes from index.

MappedByteBuffer class

Overloaded force methods was added to MappedByteBuffer class.

• MappedByteBuffer force(int index, int length)

Existing force method has no argument, and write memory-mapped file contents to the file forcibly. New overloaded force method also write memory-mapped file contents by index argument and length argument.

 

java.nio.file package

FileSystems class

FileSystem class defines 3 overloaded newFileSystem methods.

• FileSystem newFileSystem(Path path)
• FileSystem newFileSystem(Path path, Map<String, ?> env)
• FileSystem newFileSystem(Path path, Map<String, ?> env, ClassLoader loader)

newFileSystem method is a factory method of FileSystem object, and uses URI for specifying the file system. newFileSystem also uses Path interface, but Classloader together.

New overloaded newFileSystem method specify the file system by Path ingterface, and use System class loader.

It is a little bit easier to deal with ZIP file or JAR file.as a file system.

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
    <<snip, snip, snip>>

jshell>

 

java.time.chrono package

JapaneseEra class

JapaneseEra indicates Japanese traditional era, and was added new era "REIWA" as constant. As you may know, the costant was backported to Java 8/11/12.

• REIWA

 

javax.annotation package

ProcessingEnvironment interface

ProcessingEnvironment interface is used for annotation processing.

• boolean isPreviewEnabled()

isPreviewEnabled method checked to use preview feature. If --enabled-preview option is set, isPreviewEnabled method returns true. If no, it returns false.

 

javax.lang.model package

SourceVersion enum

In every release, a constant is added in SourceVersion enum.

• RELEASE_13

 

javax.lang.model.element package

ExecutableElement interface

ExecutableElement interface indicateds an element that enables to execute such as method of class/interface and constructor.

• TypeMirror asType()

asType method returns TypeMirror object that indicates a type.

 

javax.tools package

StandardJavaFileManager interface

javax.tools package includes classes asociated with javac compiler, and StandardJavaFileManager interface is a file manager for the compiler.

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

Existing getJavaFileObjectsFromPaths method has an argument as Iterable interface, but new overloaded getJavaFileObjectsFromPaths method uses Collection interface.

On the other hand, old getJavaFileObjectsFromPaths method was deprecated.

 

javax.xml.parsers package

DocumentBuilderFactory class

I didn't imagine that DOM parser was added new APIs!

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

These 3 methods are factory methods to create DocumentBuilderFactory object using name space.

 

There are some APIs about security, but I don't have enough knowledge about these APIs. So, I skiped them.

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.1をサポートしています。その関連で2つのクラスに定数が増えました。

Character.UnicodeBlockクラス

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

• 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<String, ?> env)
• FileSystem newFileSystem(Path path, Map<String, ?> 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の変更をまとめてみましたが、やっぱり変更は少ないですね。

 

JJUG CCC 2019 Spring

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

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

Project Loom - 限定継続と軽量スレッド - from Yuichi Sakuraba

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で動作できるようにならないとリリースはできないので、そこが最低限の目標となるのではないでしょうか。

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

 

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 10⁴not 10³. Number unit of 10⁴ is "万" and 10⁸ 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.

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メソッドが追加されました。とはいうものの、このクラスを直接使うことはまずないはずです。

 

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