JEPで語るJava 27

JEPで語る方もおなじみになってきました。

Java 27のJEPは全部で9つ。そのうち、Standard JEPは4つで、Preview JEPとIncubator JEPは5つです。

Java 27のStandard JEPの一覧はこちら。

• JEP 523: Make G1 the Default Garbage Collector in All Environments
• JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
• JEP 534: Compact Object Headers by Default
• JEP 536: JFR In-Process Data Redaction

Standard JEPのうちAPIの変更されるのはJEP 527ですが、既存のコードのままでも恩恵を受けることができます。

Preview JEPとIncubator JEPの一覧はこちら。

• JEP 531: Lazy Constants (Third Preview)
• JEP 532: Primitive Types in Patterns, instanceof, and switch (Fifth Preview)
• JEP 533: Structured Concurrency (Seventh Preview)
• JEP 537: Vector API (Twelfth Incubator)
• JEP 538: PEM Encodings of Cryptographic Objects (Third Preview)

 

いつもと同じように、PreviewやIncubatorは軽く触れるだけで、主にStandard JEPについて紹介していきます。

ただし、JEP 527とJEP 538はセキュリティ関連なので省略します。

 

JEP 523: Make G1 the Default Garbage Collector in All Environments

サーバー環境でG1GCがデフォルトのGCになったのがJava 9。

STWを減らすために、アプリケーションスレッドと同時にGCスレッドも動作するので、本来はコアがたくさんあるような環境が適しているのは明らかです。また、ヒープをリージョンに分割するのも、ヒープがある程度余裕がないとリージョンを効果的に使えません。

したがって、リソースに余裕があるサーバー環境でG1GCがデフォルトGCというのは理にかなっています。

しかし、G1GCは着実に改良され続けて、低リソース環境でもシリアルGCと同等のスループットを得ることができるようになってきました。これってなにげにすごいことだと思うんですよね。

ということで、今まで低リソース環境ではシリアルGCがデフォルトGCだったのを、Java 27からG1GCがデフォルトGCになりました。

とはいうものの、本当にシリアルGCと同じスループットが出るかどうかはアプリケーションごとに検証が必要かもしれません。

低リソース環境といえばコンテナで動かしている場合ですね。今までシリアルGCを使用していたのであれば、G1GCを評価しておいた方がよいかもしれません。

ただ、Java 27はLTSではないので、実際に使われるのはLTSのJava 29でしょう。Java 29がリリースされるまで時間的に余裕があるので、急いで評価する必要はないかもしれないですね。

 

JEP 534: Compact Object Headers by Default

JEP 534もJEP 523と同様にデフォルト動作の変更です。

何が変更になったのかというと、オブジェクトヘッダーです。

Project Lilliputで進めていたオブジェクトヘッダーのコンパクト化はJava 25で導入されました(JEP 519)。しかし、この時はコンパクトオブジェクトヘッダーを試すには、Javaのオプションで -XX:+UseCompactObjectHeaders を指定する必要がありました。

そして、コンパクトオブジェクトヘッダーが導入されて1年、とうとうコンパクトオブジェクトヘッダーがデフォルトになったのでした。

逆に以前のオブジェクトヘッダーを使用するには、Javaのオプションで -XX:-UseCompactObjectHeaders を指定します。

 

JEP 536: JFR In-Process Data Redaction

Redactionは編集という意味なのですが、閲覧できないように黒塗りにすることもRedactionなのだそうです。

何を黒塗りするかというと、Javaの起動時オプションで指定した機密情報です。

JDK Flight Recorder (JFR)はアプリケーションの診断やプロファイリングに使う情報を収集する便利なフレームワークです。

JFRではいろいろな情報を収集するのですが、その中には起動時オプションも含まれます。

しかし、起動時オプションには公になっていないURIや、パスワードなどを指定することもあります。このため、JFRの記録ファイルから情報漏洩の可能性が発生してしまいます。

自分では解析できないので、第三者に記録ファイルを渡して解析してもらうようなケースですね。

そこで、機密情報に当たるような起動時オプションは記録しないようにしましょうというのが、JEP 536です。

これ、自分で黒塗りにするところを指定するのだと思っていたら、デフォルトのままでも結構黒塗りにしてくれます。たとえば、次のようにTestクラスを実行したとします。

> java -XX:StartFlightRecording:filename=dump.jfr Test -password abcde

Testクラスの引数として-passwordでパスワードを指定するようなパターンです。

Testクラスの実行後、JDK Mission Control (JMC)でdump.jfrファイルを読み込んでみましょう。下図はJMCのシステムプロパティの一覧です。

sun.java.commandのところを見てみると"Test [REDACTED] [REDACTED]"になっています。つまり、この引数がパスワードであると判別して記録しないようになっているわけです。

しかし、passwordではなく、psswrdやpassだとRedactしないようです。

そこで、デフォルトでRedactしない情報については、個別に指定する必要が出てきます。

Redactする情報は -XX:FlightRecorderOptions オプションで指定します。

-XX:FlightRecorderOptions オプションの後に、以下の2種類のサブオプションで情報を指定します。

• redact-aargument: コマンドライン引数
• redact-key: 環境変数もしくはシステムプロパティ

たとえば、デフォルトではRedactされなかった-psswrdとその後の情報をRedactするには以下のように指定します。

> java -XX:StartFlightRecording:filename=dump.jfr -XX:FlightRecorderOptions:'reduct-argument=-psswrd *' Test -psswrd abcde

*は任意の文字列にマッチするワイルドカードです。1文字にマッチする?も使用できます。

このように指定することで、JFRの記録ファイルからの機密情報漏洩を防ぐことができます。

 

Preview JEP/Incubator JEP

お試し機能のJEPも簡単に了解しましょう。

 

JEP 531: Lazy Constants (Third Preview)

JEP 531は3回目のプレビューですが、Lazy Constantsになってからは2回目。

Lazy Constantsは、初期化に時間のかかるオブジェクトを遅延初期化させるためのAPIです。

Java 27での変更は少しだけ。

isInitializedメソッドとorElseメソッドの削除と、Set.ofLazyメソッドの追加です。

もともとそれほど大きくないAPIですし、変更も少しなので、そろそろStandard JEPになりそうな感じ。

Java 28で変更なしでもう一度Preview、Java 29でStandard JEPというのが櫻庭の予想ですw

 

JEP 532: Primitive Types in Patterns, instanceof, and switch (Fifth Preview)

パターンマッチングにプリミティブ型を使えるようにしようというのがJEP 532。

Java 27では変更なしでもう一度Previewなので、Java 28でStandard JEPになるのでしょう。

 

JEP 532についてはカサレアルのブログに詳しく書いたので、そちらをご参照ください！

 

switchのパターンマッチングにプリミティブ型を使う
https://bsblog.casareal.co.jp/archives/14973

 

JEP 533: Structured Concurrency (Seventh Preview)

複数のスレッドで実行した結果をまとめるような用途に使用するのがStructured Concurrencyです。

Structured ConcurrencyはProject Loomで仕様策定されているので、もともとはVirtual Threadと一緒に出せればよかったのですが、なんと今回7回目のプレビュー。

しかし、Java 28でStandard JEPになることがほぼ決まりました！

 

とはいうものの、Java 27でも変更点があります。

• StructuredTaskScopeインタフェースとStructuredTaskInterface.Joinerインタフェースにjoin()メソッドなどでスローさrふぇる例外の型を表す型パラメータが追加
• StructuredTaskScopeインタフェースに、引数にStructuredTaskScope.Configurationインタフェースをとるopen()メソッドのオーバーロードが追加
• allSuccessfulOrThrow()メソッドなどのファクトリーメソッドで生成されるStructuredTaskInterface.Joinerオブジェクトが、joinメソッドでExecutionException例外をスローするように変更
• StructuredTaskScopeインタフェースのawaitAll()メソッドが削除
• StructuredTaskScope.JoinerインタフェースのonTimeout()メソッドがtimeout()メソッドに名称変更

 

JEP 537: Vector API (Twelfth Incubator)

Value Classが正式にサポートされるまでIncubatorが続くVector APIです。

Java 27でも変更なしでIncubatorが続きます。

このまま永遠にIncubatorのままなのではないかと思われたのですが、ここに来て動きが！というのも、Java 28でValue ClassがPreview JEP (JEP 401)になります！

すぐにStandard JEPになることは考えられないですけど、次の次のLTSには間に合うかなぁ....???

そうしたら、やっとVector APIもStandard JEPへ！

 

まとめ

Java 27では、JEPで語れない方のAPI変更は少なかったですが、JEPの変更も少な目。

目新しいものはありませんし、Standard JEPになったのもデフォルト動作の変更なので。

まぁ、毎回派手に新機能が入るわけではないので、しかたありません。

しかし、次のJava 28では、いろいろと変化がありそうです。Value Classだけでなく、新しいJSON APIやLeydenの新しいJEPも含まれています。

楽しみに待つことにしましょう！

JEPでは語れないJava 27

毎度おなじみ、半年ぶりのJavaのアップデートです。

Java 27はLTSの間の中間のバージョンからか導入された機能も裏方的なものが多く。APIの変更も少ししかありません。まぁ、そんなもんです。

Java 27のStandard JEPは4つ。

• JEP 523: Make G1 the Default Garbage Collector in All Environments
• JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
• JEP 534: Compact Object Headers by Default
• JEP 536: JFR In-Process Data Redaction

Preview JEPとIncubator JEPは5つ。

• JEP 531: Lazy Constants (Third Preview)
• JEP 532: Primitive Types in Patterns, instanceof, and switch (Fifth Preview)
• JEP 533: Structured Concurrency (Seventh Preview)
• JEP 537: Vector API (Twelfth Incubator)
• JEP 538: PEM Encodings of Cryptographic Objects (Third Preview)

Java 26のJEPが10でしたから、さらに減っています。

Standard JEPでは、JEP 523とJEP 534がヒープに関するもの。どちらもデフォルト動作が変更されるというものです。

JEP 527とJEP 536はセキュリティ関連ですね。

 

Preview JEPとIncubator JEPは新規はなし。一番少ないものでも3回目のPreviewなので、新規性はないです。

JEPについての詳細は別エントリーで。

 

さて、JEPで語れない方です。Java 27はAPIの変更も少なめ。ほとんどがjava.baseモジュールなので、今回はjava.baseモジュールだけです。

なお、今回もセキュリティ関連や、バージョンに関する定数については省略です。

 

廃止になったAPI

Java 27で削除されたAPIは、メソッドが1つだけです。

メソッド

スレッドプールを提供するExecutorServiceインタフェースのコンクリートクラスであるThreadPoolExecutorクラスのメソッドが1つだけ削除されました。

• java.util.concurrent.ThreadPoolExecutor.finalize()

基本的にfinalize()メソッドは使わないようにすべきです。ThreadPoolExecutorクラスが実装しているExecutorServiceインタフェースがAutoClosableインタフェースのサブインタフェースになっているため、なおさらfinalize()メソッドは必要ないですね。

もし、finalize()メソッドを使用しているようであれば、try-with-resources構文を使用するようにしましょう。

 

 

廃止予定に追加されたAPI

Java 27で、forRemoval=trueになったAPIはありません。

 

追加されたAPI

Java 27ではStandard JEPでのAPI変更がないので、全体的にAPIの変更も少ないです。

 

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

数値演算のメソッドが追加されているのがメインですね。

 

Math/StrickMathクラス

逆双曲線関数関連のメソッドが3つ追加されました。

• double acosh(double x)
• double asinh(double x)
• double atanh(double x)

メソッド名の通り逆双曲線余弦関数、逆双曲線正弦関数、逆双曲線正接関数を求めるためのメソッドです。

 

Stringクラス

文字列をエンコードした時の文字列サイズを求めるメソッドが追加されました。

• int encodedLength(Charset cs)

Javaは内部文字セットとしてUTF-16を使用しているので、String.length()メソッドではUTF-16のサイズを返します(文字列長ではないです)。これに対し、指定した文字セットでエンコードしたバイト列のバイト長を返すのがencodedLength()メソッドです。

 

jshell>  var text = "こんにちは"
text ==> "こんにちは"

jshell> text.length()
$2 ==> 5

jshell> text.encodedLength(Charset.forName("UTF-8"))
$3 ==> 15

jshell> text.encodedLength(Charset.forName("Shift_JIS"))
$4 ==> 10

jshell> 

内部的にはgetBytes(cs).lengthをコールしているのと同等になります。

 

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

Classfile APIのオペコードに対応するインタフェースにメソッドが追加されました。

 

IncrementInstructionインタフェース

IncrementInstructionインタフェースは、オペコードのiincとiinc_wに対応するインタフェースです。

これまでもファクトリーメソッドであるof()メソッドが提供されていましたが、of()メソッドがオーバーロードされました。

• static IncrementInstruction of(Opcode op, int slot, int constant)

これまでのof()メソッドはオペコードを指定することができませんでしたが、オーバーロードされたof()メソッドはオペコードが指定できます。

指定できるオペコードはOpcode.IINCもしくはOpcode.IINC__Wです。

 

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

FFMのメモリに関するインタフェースにメソッドが追加されました。

 

MemorySegmentインタフェース

FFMでメモリ領域に対応するMemorySegmentインタフェースにメソッドが2つ追加されました。

どちらも既存のメソッドのオーバーロードになっています。

 

• static long copy(String src, Charset dstEncoding, int srcIndex, MemorySegment dst, long dstOffset, int numChars)
• String getString(long offset, Charset charset, long byteLength)

既存のcopy()メソッドは、MemorySegmentからMemorySegmentへのコピーでした。これに対し、新しいcopy()メソッドは文字列をMmoerySegmentにコピーします。

一方のgetString()メソッドはバイト長を指定できるようになりました。

 

SegmentAllocatorインタフェース

メモリーのアロケートを行ってMemorySegmentオブジェクトを返すのがSegmentAllocatorインタフェースです。

こちらも、メソッドのオーバーロードが追加されました。

 

• MemorySegment allocateFrom(String str, Charset charset, int srcIndex, int numChars)

ソースとなる文字列の開始インデックスと文字数を指定できるようになりました。

 

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

BigDecimalクラスにメソッドが1つ追加されました。

 

BigDecimalクラス

意外にもn乗根を求めるメソッドが今までなかったのでした。BigIntegerクラスはJava 26でn乗根を求めるメソッドが追加されたので、それに続く変更になります。

 

• BigDecimal rootn(int n, MathContext mc)

第2引数のMthContextクラスは精度を指定するためのクラスです。

 

java.base/java.time.formatパッケージ

Date & Time APIのフォーマッターに関するクラスが新規で導入されました。

 

DateTimeFormatterPatternProviderクラス

DateTimeFormatterPatternProviderクラスロケールごとに日時フォーマットを文字列を作成するためのクラスで、LocaleServiceProviderクラスのサブクラスです。

DateTimeFormatterPatternProviderクラスも抽象クラスであり、アプリケーションごとに以下のメソッドをオーバーライドします。

 

• String getDateTimeFormatterPattern(String requestedTemplate, String calType, Locale locale)
• String getDateTimeFormatterPattern(FormatStyle dateStyle, FormatStyle timeStyle, String calType, Locale locale)

 

その他の変更

Java 27というわけではありませんが、2026年8月からOracleがセキュリティアップデートの変更を行いました。

今までのセキュリティアップデートはCPU (Critical Patch Update)といい、1月、4月、7月、10月に行われてきました。

これに対し、新たにCSPU (Critical Security Patch Update)が追加され、2月、3月、5月、6月、8月、9月、11月、12月に行われます。

CPUとCSPUを合わせると、毎月セキュリティアップデートがあることになります。

すでに、2026年8月にはCSPUに対応するJava 26.0.2.1がリリースされています。今までのCPUが3つ目の数字で、CSPUが4つ目の数字ということになったようです。

これはOracle JDKの話ですが、結局は他のディストリビューターも追従するようですね。

 

参考: 月次のCritical Security Patch Updates (CSPUs)を2026年5月28日より開始

 

 

まとめ

LTSの間の中間のバージョンだからなのか、変更点がとても少ないです。

JEPによる変更も少ないのですが、これに関しては次のエントリーで紹介します。

 

次のJava 28は、やっとValue ClassがPreviewになります。これ以外にもプリミティブ型のパターンマッチングなどがStandard JEPになりそうなので、いろいろ動きがありそうです。

Java 27は嵐の前の静けさなのかもしれません。

探偵！ナイトスクープ Java Ring回の裏側

ひょんなことから探偵！ナイトスクープに出演することなっていました。人生長く生きていると、何が起こるか分からないものです。

 

どうして出演することになったのかとか、他の出演者がどうやって決まったのかなどの話はともかく、Java Ringですよ。

実際の撮影は1日がかりだったのですが、放送はたった10分。削られた部分が多くあるので、その部分を補っていくというのが、このエントリーです。

 

依頼者の山﨑さんも顛末をブログに書いているので、そちらもぜひご覧になってください。

• 【Java Ring】07. ナイトスクープにて，お会いましょう！
• 【Java Ring】08. Java Ring が復活しました！

 

番組はYouTubeで見られます。

 

Java Ring

Java Ringは1998年にサンフランシスコで開催されたJavaOne 98で、Sun Microsystemsが参加者に配布したガジェットです。その後、日本など世界各地のJavaのカンファレンスやイベントで参加者に配布されています。

櫻庭はJavaOne 98でもらったもの以外に、日本の2つのイベントでも取得したので3つあったのですが、1つは行方不明😰

イベントで配布されたものはプロトタイプで、その後実際に販売されたようですが、製品版は見たことがないです。

 

Java Card

さて、この当時、Javaに複数のエディションを作成すると発表されていました。Java SE (Standard Edition)、Java EE (Enterprise Edition)、Java ME (Micro Edition)の3種類です。今もOpenJDKで開発が進められているのが、Java SEですね(SEとは言わなくなってしまいましたが...)。そして、Jakarta EEがJava EEの後継です。

残念ながら組み込み向けのJava MEはなくなってしまいましたが、Java MEよりもさらにリソースが限られたデバイス向けのJavaがあります。

それがJava Cardです。

Cardという名前であることから分かるとは思いますが、クレジットカードがメインのターゲットです。その他にもSIMカードなどにJava Cardは使われていました。

クレジットカードを見れば分かる通り、バッテリーはありません。つまり、カードを親機に接続したときに供給される電力だけで動作します。

また、計算リソースも極端に限定されており、浮動小数点数はおろか、整数でも4バイト幅のintは使用できません。

このため、Javaといっても、Java SEとはかなり違うものです。

 

Java CardではCardletというアプリケーションが動作します。このCardletのクラス名がAppletなのが誤解を生んでいました。

Java CardのAppletはjavacard.framework.Appletクラスで、いわゆるアプレットはjava.applet.Appletクラス。できることも違えば、メソッドも異なりますし、動作も全然違います。

Cardletでは、ほんとに限定的なことしかできないのです。まぁ、クレジットカード上で動作すると考えれば妥当ですね。

 

Java Ringとは

さて、Java Ringです。

Java Ringは、Java Cardに準拠したデバイスです。

もともとはiButtonというボタン型のデバイスがありました。そこにJava CardのVMであるCardVMをのせ、指輪状に加工したのがJava Ringです。

通常のJava Cardとは違って、バッテリーが内蔵されており、メモリもクレジットカードに比較すれば多く使用できました。このため、複数のCardletを使用できるようになっています。ただし、複数のCardletを同時に動かすことはできません。

1998年のJavaOneでは、山﨑さんがナイトスクープで言及してたコーヒーの好みを記憶させておくCardletや、マンデルブロー集合の各ピクセルを計算させてJavaOne参加者でマンデルブロー集合の図を表示させるCardletが使用できるようになっていました。とはいえ、コーヒーの好みを記憶させておくだけで、Java Ringを接続するとコーヒーを淹れてくれるというのはなかったんですけどね。

 

このようなJava Ringですが、バッテリーを搭載しているために、逆にバッテリーがなくなってしまうと動作しなくなってしまいます。そこで、山﨑さんがバッテリーを交換したいとナイトスクープに駆け込んだわけです。

 

Java Ringの構造

ソフトウェアの構造でもハードウェアでもなく、物理的な構造です。

Java Ringは、iButtonを指輪状に加工したものです。ベースになるのはiButtonが収まるサイズの穴がある指輪です。

その穴に樹脂を流し込んで、その後にiButtonを埋め込み、さらに隙間に樹脂を流し込んで、iButtonを固定してあります。

Java Ringの穴の裏側には空気抜きのための小さな穴が開いています。

iButtonは筐体全体が接点になっており、側面および底面がグランド、トップの部分が信号ラインとなっています。これをアダプターに接続して親機と通信できるようになっています(この通信方法は1-Wireと呼ばれています)。

このため、Java Ringでもアダプターに接続できるように、トップの部分が露出した形状になっています。

 

さて、このような構造のJava Ringですが、バッテリーを交換するにはiButtonを開封しなければいけません。

ナイトスクープではJavaの専門家たちに集まっていただきましたが、さすがにソフト屋には手も足も出ません。

そこで、登場していただいたのがプロモデラーのまつおーじさんです。

今回、Java Ringが復活できたのも、ほんとにまつおーじさんのおかげです。

まつおーじさんが行ったのが、iButtonの周りの樹脂の部分をタガネで掘っていくというものです。下の図にJava Ringの輪切りにした図ですが、この黒い樹脂の部分を削っていったわけです。

番組ではあっという間に掘り終わったように見えますが、実際にはこれだけで2時間近くかかっています。

上から金属が見えるところまで掘り進み、その後裏側の小さい穴も掘り進めていきます。これで下図のような状態になりました。

この後、小さい万力を利用して、下の穴から力をかけて押していきました(上手の矢印の部分)。この結果、iButtonがスポッと取り出せたのでした。

これも番組では簡単に取り出せたように見えますけど、これもなかなか引っかかりがなくて時間がかかっています。

次は、取り出したiButtonを切断してバッテリーを取り出すわけですが、これもそんなに簡単にできるものではありません。

もともとiButtonはバッテリーを交換するようにはできていません。バッテリーを取り出すには、何らかの方法でiButtonを切断しなくてはなりません。

山﨑さんも紹介しているiButtonの電池交換レポートでは、グラインダーを使って切り進んでいますが、これは中の基盤などを壊してしまう可能性も高いです。

iButtonの形状を図式化したのが下図です。

ここで、まつおーじさんが注目したのが、iButtonの底部にあるフリンジです。下の図はiButtonを水平に見た時の図ですが、フリンジは赤丸の部分ですね。

このフリンジは、iButtonを他のデバイスなどに装着しやすくするための出っ張りです。ですが、iButton自体をかしめるにもこの形状が都合がよかったのだと思います。

このフリンジの部分をペンチで繰り返し曲げ伸ばしすることで、金属疲労によりちぎりとっていったわけです。

最終的には缶詰を開けた時のように、一周ぐるりとフリンジを取り除き、底部をパカッと開けることができたのでした。

そして、バッテリーは底部にあったので、無事に交換ができたのでした！！

ちなみに、下の写真はバッテリーを抜いた後です。

と、ここまでが物理的な話。番組だとかなりはしょられてはいましたけど、こちらがメインでしたね。

まぁ、ソフトは何かやっていても絵にならないからしかたないです。

 

Java Ringのソフトウェア構成

さて、ここからがソフトウェアの話です。

Java Ringのソフトウェアの構成を示したのが下の図です。

ベースの部分にファームウェアがあり、その上にJava CardのVMであるCardVMが動作しています。リソースが限られているため、OSに相当する部分はありません。

また、ファームはバッテリーがなくても、1-Wireからの給電で最低限の動作は可能です。

山﨑さんのblogエントリーの 【Java Ring】05. CRC エラー！ で、バッテリーがなくても通信ができているのはこのためです。しかし、バッテリーが切れてしまったため、CardVMは動作しません。このため、CRCエラーが発生してしまっています。

そして、CardVM上でCardletが動作するという構成になっています。

また、Master PINなどの秘密情報を保持している領域も用意されています。

 

このような構成になっているわけですが、当然のことながらそれぞれの構成要素がメモリーのどこかに保持されています。

問題はどこまでがバッテリーがなくてもメモリー内容を保持できるかどうかということです。

メモリーには電源が供給されないと内容を保持できない揮発性メモリーと、バッテリーがなくても大丈夫な不揮発性メモリーがあります。

不揮発性メモリーにも、長期的に安定しているものと、長期的には内容を保持できないものがあります。

前者にはEPROM、後者にはフラッシュメモリーなどがあります。前者は一般的にROM、後者はNVRAMと呼ばれることがあります。

iButtonでも、EPROMとNVRAMが使われています。

問題はどこまでがROMに保存されているかということです。

もう1つ考えなくてはならないのが、耐タンパー性です。

耐タンパー性とは外部からの攻撃を受けた時の耐性を示しています。攻撃に対する対応にはいろいろありますが、漏洩してはならない情報を消去するという手法もあります。

Java Ringはパーソナルなガジェットなので、分解しようとすると暗号鍵などの秘密情報は耐タンパー性により消去されてしまうのではないかということです。

事前に大山さん、石原さんと話していたのは秘密情報は、まず消去されるでしょうということ。また、Cardletもバッテリーがなくなれば保持できないであろうということです。

で、議論になったのが、CardVMです。

製品版のJava Ringならともかく、プロトタイプでイベント用に配布するために作られたJava RingでCardVMをわざわざROMに焼くかということです。

3人の意見は、多分ダメだろうと。

ところが、バッテリーを交換してビックリ、CardVMが生きていたのでした！！

 

とはいえ、秘密情報は消去されてしまったので、初期化されてしまった状態です。収録の時には、Cardletをロードするところでエラーになってしまいました。事前に工場出荷時のMaster PINの候補はいくつか探していたのですが、いずれも失敗。

結局、残念ながら時間切れ。

その後、山﨑さんが自宅で設定をいろいろと見直すことでCardletのロードに成功したのでした。どうやら、工場出荷時にはMaster PINが設定されていなかったようです。

その後、Cardletの実行までできたのは彼のblogにある通りです。

 

ということで、Java Ringが復活したのでした！！