2020/03/17

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追加はほとんどないのがちょっと寂しい...

 

2019/10/04

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.

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.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の変更をまとめてみましたが、やっぱり変更は少ないですね。