恒例になってしまった半年ぶりの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クラスのメソッド追加ぐらいなのがちょっと寂しいですね。
