緊急特集! Javaの無償版はなくならないぞ!に参加した

2018/6/20にJJUG主催で行われたJJUG ナイトセミナー 「緊急特集! Javaの無償版はなくならないぞ!」の前半まとめです。個人的に気になるところだけまとめています。

Javaのリリースモデル(Java8まで)

OpenJDKのソースをもとにOracleがOracleJavaをビルドしてリリースしていた。OpenJDKとOracleJavaの差分は以下の通り。

つまりコアライブラリやコアレベルは、OpenJDK/Opracleはベースは一緒。ただしセキュリティアップデートについては、Oracleが開発。セキュリティパッチやバグフィックス、機能追加はOracle側からOpenJDKにも還元していたが、同期は不完全だった。

Javaのリリースモデル(Java9以降)

Java9以降は、Oracleから2つのバイナリを提供する。1つがOpenJDKのソースコードを、そのままOracleがビルドしたバイナリ版のOpenJDK。ライセンスはGPL v2 + classpath exception(なので自由に配れそう)。

もう一つがOracleJava。こちらは商用ライセンスで提供。OracleJavaはJava8と同様に、OpenJDKのソースコードを元に以下の機能を追加したもの。

セキュリティパッチについては、Java9以降は、OpenJDKにも確実に全部アップデートが提供される。セキュリティパッチはOracle側で作ってOpenJDKに入れるような運用となる。

リリースサイクル

OpenJDKのバージョンアップは半年に一度(3月と9月、確実にバージョンアップ)。またアップデートリリース(脆弱性対策/バグFIX)は3ヶ月に一度(1,4,7,10月)。

OracleJavaは3年に一度のリリース。セキュリティアップデートは提供され、有償サポートがあればずっとサポート(最低8年)。

その他

結論

OpenJDKはOracleJavaの大本として開発されているので、機能差分の心配はなさそう。またJava9からOracleのセキュリティパッチが確実に反映されるので、その点もうれしい。ビルド済みのOpenJDKもOracleから提供されるので、単純利用であればこれを使ええば問題なさそう。ということかと思います。

OpenJDKは細かくバージョンアップされるようになったのが懸念、という話をちらほら聞きますが、CIを回していれば問題になるケースはあまりないと思いますし、セキュリティアップデートは今までもされていたと思うのであまり問題がない気がします。インストーラー付きのバイナリ版OpenJREが出ればよりよいとは思いますが。

むしろFlight RecorderやMission Control といった商用機能がOpenJDKでも使えるようになったこと、JDKが配りやすくなったこと、新しい機能をいち早く取り入れられるようになったことなど、メリットしか感じないというのが個人的な感想です。

 

 

 

SIM City

この記事は SORACOM Advent Calendar 2017 12/20 分のエントリーです。

 

ビットの海

古くは金属線から始まり、光ファイバーやナノカーボンファイバーと進化した人類の情報伝達経路である物理線、そして「のろし」からはじまり、音や光、電波を利用した無線網はかつて地球上に張り巡らされ、まるで神経のように人類に情報を振り撒いていた。

 

このネットワーク技術の発展によって、人類は過去にない速度で情報を伝達し合えるようになった。ひとたびつながりだした人類は、より多くの情報を求め、人だけではなくありとあらゆる物質に対してその触手を伸ばしていき、得られたその情報により、生活や仕事、人間関係、そして国と言った概念さえも急速に変えていった。

 

ネットワークがより末端の物質に触手を伸ばすにつれ、物理的な制約が足かせになりはじめた。より小さく効率の良いネットワーク機器の開発が進んだ結果、量子もつれという現象を利用した通信技術「APRIL」が誕生した。

 

元々は惑星間の通信遅延を解決するために生み出された技術だったが、量子の現象だけで安定してデータを送れる技術が確立され、小型のチップ状の装置があればどこでも遅延なく相手と直接通信が行えるようになった。


結果として、従来の物理線網/無線網に頼る必要がなくなり、バケツリレー方式による「インターネット」と呼ばれたネットワークに変わる、新たな人類のネットワークが瞬く間に構築された。

 

この新しいネットワークを構築するにあたり、通信する端末には利用者認識モジュール(Subscriber Identity Module : SIM)の利用を義務付けた。無線通信の認証のために利用されていた仕組みで、SIMに割り振られた"IMSI"と呼ばれるユニークIDを使って、通信元の認証が行えるようになっている。

IMSIは元々15桁しかなかったが、現在では通信のために使われていた"IPv6"と呼ばれる広大なアドレス体系の一部がSIM用として割り振られている。

 

通信機器と同様にSIM自体も小型化が進み、現在ではカーボンナノチューブで作られた「nSIM」と呼ばれる極小のチップが多く利用されている。nSIMにはAPRILが実装されており、このnSIMだけで認証と通信が行えるようになっている。


またセンサー類が実装されているnSIMもあり、センサーから取得した情報のコピーを仮想空間上に保持する事ができる。これはThing Shadowとも呼ばれている。

 

かつてはクラウドベンダーや通信キャリアと呼ばれた企業群は、現在はIMSIの認証とSIM間の通信を提供するための認証プロバイダとなっており、企業や個人の所有物の管理を仮想空間上で容易に行えるだけでなく、Thing間の協調動作により、事故を未然に防いだり、体調管理を行ったりすることができ、社会基盤として大きな役割を担っている。

 

『急激な温度変変化を検知しました。火災が発生した可能性があります。』

 

スクリーン上の地図が赤く点滅し、消防システムが警報メッセージを発した。10Kmほど離れた町外れの住宅街、駐車してあった複数の車両の急激な温度変化を検知したシステムが、住宅の火災を検知したようだ。

 

「消火活動のための特権ロールを要求する。担当者名カツ・ヤマシタ」

 

『承認しました』

 

警察や消防署など、公的な機関はその活動に必要な範囲のみで、認証プロバイダ内の情報に一時的にアクセスすることができる。カツは特権ロールを使い、火災箇所周囲の情報を収集をはじめる。

 

「この建物はかなり古いな。センサー類がほとんどない。現場近くの監視カメラで、火災が写っているものだけをリストアップ」

 

特権ロールの利用ログはすべて分散台帳上に記録され、検閲の対象となる。このため、特にプライバシーに関係するカメラへのアクセスは特に慎重を要する。かならず情報のフィルタリングが出来る情報を渡し、画像認識を使って必要な情報以外が写っていないかどうかを確認して、情報を取得する必要がある。


消防システムは認証プロバイダ上に地区先されたThing ShadowのGPS情報にアクセスして、火災発生箇所周囲のカメラの情報を収集する。

 

『9箇所のカメラが該当します』

 

「OK,スクリーンに動画を表示」

 

特権アクセスにより、一時的にカメラの動画にアクセスする。画面が9分割され、炎上している建物が映し出された。かなり年数の経った洋館のようで、消化システムが設置されていないためか、激しい勢いで建物を包み始めている。

 

「火災を確認。消火システムを3台、転送」

 

『転送を開始します』

 

消化薬剤を積載したドローンが3台、「Beam」と呼ばれる物質転送技術により火災現場に転送される。スクリーン上の動画のいくつかに淡い光が発生し、次第にドローンが具現化する。


ドローンは火災を検知すると自律的に飛行を始め、消火活動を始める。スクリーンにはドローンの動画が表示される。程なく火災は鎮火し、スクリーン上の赤い点滅が消える。

 

「特権アクセスを解除。現場検証に向かう。警察にも連絡を。」

 

-----

 

火災現場の発生した洋館は木造の平屋建てで、火の周りが早く半分焼け落ちていた。住人はいない模様で、人的な被害はなさそうだ。

 

現場の状況と、火災発生前の周囲の状況分析から、火災の原因は不審火である可能性が高い。

 

相続された履歴もなく、焼け残った建物を見る限りでも補修などはされていないため、数十年に渡って放置されていたと考えられる。

 

「不動産の履歴を調べましたが、建物が建築されたのはおよそ80年前です。登記時のオーナーの年齢が40歳なので、もし生きていれば120歳を越してることになります。おそらく既に他界されているでしょうね。本庁のデータベースも当たってみましたが、このオーナーのご家族に関する情報は何もないですね。」

 

現場で落ち合った警察官ジュン・ホンダは、半ば諦め気味に話す。警察や消防といった公的機関や地域の見守りのような地域のセーフネットは、センサーや通信の発達に伴い、次第にシステム化され、人手を介さなくった。過疎化が進んだ地域はこの手のシステムの恩恵は受けたが、逆に隣人同士の交流も減り、いわゆる「お隣さんが」といったアナログな見守りは希薄になるという問題を抱えていた。おそらく、このオーナーがいなくなったことも周囲には気が付かれなかったのだろう。

 

「一応決まりですので、連絡先が分かりそうなものがあるかどうか探します。お手数ですがご同行願います。」

 

ひっそり静まり返った建物に、警察官とともに入る。火の周りが早かった南側はほぼ全焼しており、残されたいくつかの部屋を捜索する。焼けて危険な部分を避けつつ部屋を見回るが、焼け残った部分の部屋はほとんど家具が無く、手がかりとなりそうなものはなかった。


諦めて引き上げようとした時、焼け落ちた壁の奥に何かがあるのを見つけた。

 

「何か金庫のようですね。」

 

重厚な作りの金庫が、焼けて剥がれ落ちた壁の奥から覗いていた。どうやら壁に隠れた金庫のようだ。ステンレスで出来ているのか、長い年月が経っているが錆などはない。壁の奥から持ち出し、取っ手をひねると、音もなく扉が空いた。

 

金庫の中には、小さな箱が一つ入っていた。箱の中には小さな紙切れと、5ミリ四方の四角いチップが1枚入っていた。


紙切れには、「呪いが解ける日が来るまで サトシ」と書かれていた。

 

-----

 

国の決まりにより、所有者のいない物件は、一定期間の所有申し立て期間を過ぎたあと、国により接収される決まりとなっている。このため、火災となった現場の場所と動画、そして現場から保全したいくつかの家財の写真は、所定のサイトで公開され、所有者がいれば申し出ができるようになっている。

 

土地に価値があった時代は申請者の厳密な調査を行っていたが、技術の発達により居住区域はどこにあっても問題がなくなり、土地の価値自体がほとんどなくなった今では、今回のように所有者が亡くなっているであろうケースではほとんどの場合、所有申し立てをしてくるものはいない。

 

ジュンは似たようなケースで何度も所有申し立ての情報掲示をしており、今回も他のケース同様、申し出がなく接収されることになるだろうと思っていた。しかしながら紙切れの言葉が気になっていたため、なにか手がかりがあると面白いのにと考えていた。

 

その矢先、この物件に対する問い合わせが1件入った。問い合わせは、所有の申し立ててではなく、自分の祖母が持っていた写真とこの物件がよく似ているため確認させて欲しい、というものだった。

 

-----

 

警察署を訪れたケイ・マツモトと名乗る女性が差し出したハガキ大のサイズの写真には、火災で焼ける前のきれいな洋館と、その庭先に立った男女の姿が写っていた。女性は、小さな子どもを抱いていた。

 

「この写真に写っているのは、私の母のエミと祖母のマイコです。男性は、おそらく祖父だと思いますが、母も顔が分からないそうです。写真は祖母が亡くなったあとに出てきたものなんですが、この建物と男性が写っているものはこの1枚だけです。」

 

事情は分からないが、この女性の祖母になんらかの問題が発生し、父親と離れ離れになったようだ。

 

「母の戸籍を調べてもらえれば分かるのですが、母には父親がいないことになっています。この写真が母の両親のものだとすると、この男性が私の祖父に当たるのではないかと思います。
母は、祖父がいなくなった理由を何度も祖母に聞いていたそうですが、祖母は頑として答えてくれなかったそうです。母ももう高齢なのですが、なぜ祖父が突然いなくなってしまったのか、もし分かるなら知りたいと言っていまして。」

 

紙切れに書かれた「呪い」という言葉と、祖父がいなくなった事には何か関係がありそうだが、手がかりとしては残されたものは、四角い黒いチップしかない。

 

-----

 

所有申し立て期間が経過した後、ケイ以外の問い合わせはなく、結局所有申し込みはなかった。このためジュンは、ケイに調査のために所有申し立てをすることを勧め、それは受理された。


実はジュンは紙切れの言葉が気になっていたため、所有申し立て期間が終わったあとに調査をしようと思っており、箱の中の四角いチップについて情報を集めていた。

 

「この四角いチップは、洋館が建築された頃によく使われていた"eSIM"と呼ばれるSIMのようです。古いSIMではありますが、今現在も認証プロバイダに登録があるSIMということは分かりました。」

 

所有手続きが受理された証跡と共に、認証プロバイダに対してSIMのアカウントの移譲を申請した。数日後、申請は受理され、SIMに関する情報がコンソールで見れるようになった。


コンソールで確認すると、SIMにはストレージサービスへのアクセスパスが設定されていた。SIMを鍵として、何かをストレージに格納しているのだろう。

SIMで通信すれば、このストレージサービスにアクセスできそうであった。

 

ジュンはeSIMであると判明した段階で、おそらく通信の必要があることも見越していた。このため、骨董市でこのeSIMが使える通信モジュールを手配していた。

現在の通信はAPRIL経由で行われるため、従来の通信をAPRILでトンネルできるタイプのモジュールを入手していた。

 

eSIMを通信モジュール上のソケットにはめ込んだあと、モジュールのコンソールから「http://beam.soracom.io」にアクセスすると、ほどなくファイルのダウンロードが開始された。最終的に100GB程度のサイズのファイルがダウンロードされた。ファイルを作業用の端末に移動し、コンピューターに問いかけた。

 

「これはどのようなファイルだ?」

 

『このファイルはzipと呼ばれる圧縮形式のファイルで、AES-256で暗号化されています。現在は暗号強度の関係上、使われていません。』

 

ここ数十年使われていない方式ということだが、いまのコンピューターの計算能力であれば、復号化できそうだ。

 

「復号化にどのぐらいかかる?」

 

『最大で5分です』

 

ほどなくファイルの復号化が終わり、中に入っていたファイルが表示された。

ファイル名には日付とタイトルがついていたが、一番新しいファイルには、「マイコとエミへ」と名づけられていた。どうやらこのサトシがエミと関係が深かったのは間違いなさそうだ。

動画を再生すると、写真の男性が映し出された。ひどくやつれているように見える。

 

「マイコとエミへ。もしこの動画を君たちが目にすることがあれば、おそらくその時は私の呪いが解かれていると思う。

自分の興味本位で作った仕組みのせいで、こんなことになって本当に済まない......」

 

動画の中で、男性は謝罪を繰り返していた。

話を要約すると、"ビットコイン"というものを作った影響で、さまざまな機関から狙われるようになり、家族の身の安全のために自分から遠ざける必要があったということのようだ。

マイコが父親について頑なに話さなかったのは、それもエミの身を案じてのことだと思われる。

 

そのほかの動画には、生まれて間もない子供と、幸せそうにそれを見つめる男女が写っていた。

 

「これ、お母さんとおばあちゃんだと思う」

 

ケイが物心ついたときには、既に祖母であるマイコは他界していたため顔は分からないが、動画に映し出されている女性は、ケイの母親にそっくりだった。

 

後日、エミもこの動画を目にし、長年謎だった父親の失踪の理由と、母親が父親の話をしなかった理由を理解した。

一時は自分が両親から愛されていないのではないかと思い、母親に辛く当たった時もあったそうだが、それが全て両親がエミのことを思ってやったことだと分かり、長年の謎が消え、納得した様子だった。

 

サトシの思いは、数十年経ってようやくエミに届いたようだ。

 

-----

 

ジュンは今回のための調書をまとめながら、結局呪いが解けるという意味がわからなかったなと、と考えていた。しかし、サトシが狙われる理由となったビットコインについて調べたところ、ようやく呪いの意味が理解できた。

 

ビットコインは、洋館が建てられた後ぐらいにブームとなった暗号通貨で、ハッシュ値の計算を元に通貨が成り立っているという性質のものだった。

 

中央集権的な貨幣とは別の仕組みで流通できたこととで、多くの地下組織がビットコインや、それに類似したものに手を出し、資金源となっていたようだ。

 

ビットコインの理論は匿名で世に出したようだが、おそらくいずれかの段階で正体が発覚し、彼自身の保有していた大量のビットコインを狙われたのではないかと思う。もしくはビットコイン自体のハッキングや、新しい暗号通貨の開発のためにそういった組織から狙われていた可能性も高い。

 

しかしビットコインハッシュ値の計算に依存しているため、突然大きな計算量を持つコンピューターが出てきた場合には、暗号通貨自体が無くなったり書き換えられてしまう可能性がある。事実、ここ数十年の量子コンピューターの大幅な発展によって、何度か暗号方式の変更を余儀なくされているし、その過程でビットコインも価値を失っている。


言い換えると、もし自分が用意したzipファイルの暗号を簡単に解くことが出来るぐらいに計算量が多いコンピューターがある世の中になれば、自分と自分の家族が狙われる理由もなくなっているはずで、その時はzipファイルの暗号もビットコインの呪いも解けているはず。その時は真実を家族に話したい、という思いでこの動画を撮ったのではないだろうか、と考えると納得がいく。

 

破られないことが一番重要である暗号通貨を設計した本人が、実は一番破られることを期待していた、というのはなんとも皮肉な呪いである。

 

-----

 

ジュンは調書をまとめると、ファイルをアップロードしてこの件を報告した。

 

無数のSIMによりヒトとモノがつながり、そして共鳴する街、SIM City。もしサトシ・ナカモトが今を生きていなたら、SIMを使った仕組みを何か考えついていたのだろうか。もしそうだとしたら、それは彼が幸せになる仕組みであって欲しいと、eSIMを眺めながらそう思った。

 

 

 

 

SIM City

この記事は SORACOM Advent Calendar 2015 12/22 分のエントリーです。

IMSI 440903115977777

「15桁のIMSIなんて、聞いたことがないよ。そもそも15桁って少なくないか?」

秋晴れの骨董市で男が見つけたのは、表面が金色にコーティングされ、鈍く光る2センチ角ほどのプラスチックチップだった。

裏には製造番号らしき文字と、そしてうっすらと北斗七星のマークが書かれているのが見える。

"IMSI"というのはこのチップに書き込まれているIDで、同じIDのものは2つ存在しない。

「これは売り物じゃないんだけどね。珍しいでしょう。祖父からもらった物なの。祖父も、父親か誰かにもらったみたい。」

そう言いながら、店番の女は懐かしむようにチップを見つめる。男は、きれいな瞳をもったその女を、その少し興奮した面持ちで見つめる。

「これ、"SIMカード"っていう名前なのよ。昔はIMSIが15桁しかなかったの。IMSIの末尾が7で揃っているでしょ?だから幸運のお守り代わりに持っているの。それにこれ、IMSIの書き換えが出来ないのよ。一途な感じでいいでしょ。」

一途というよりも、融通が効かないってほうが合っているんじゃないかと、男は思った。

「カードという割には、チップと言ったほうがいい大きさに見えるけど。」

「このチップは元々、大きなカードについていたの。それでこのチップは、切り取ったあとのもの。昔はこれを電話機に入れて使っていたのよ。」

「電話機か。それなら、うちのじいさんが持ってたな。でもそんなチップを入れる所はなかったけど。」

「多分その電話機には"eSIM"っていうのが入っていたんじゃないかしら。SIMカードよりもだいぶ小さいチップよ。出てきたあとに、あっという間にvSIMやnSIMに取って変わられたけどね。それにね、今と違ってこのeSIMもSIMカードも、通信にしか使われてなかったのよ。」

女は、別のケースから小さな黒いチップを取り出した。2ミリ角ほどの小さな物体、eSIM。Embedded SIMと呼ばれていたものだ。

「昔はほとんどすべてのものが"SIMフリー"だったんだろ?僕はとてもじゃないけどそんな環境では生活できないな。」

「SIMフリー、ね。以前は"電話機がSIMを選ばない"という意味だったらしいけど。確かに今ではSIMのついていないモノを探すほうが難しいわね。」

通信を行うために使われ始めたSIM(Subscriber Identity Module:利用者認識モジュール)は、単に通信時の認証だけでなく、人や物、データを識別するためのモジュールとして、ここ数十年で大きく発展を遂げた。

SIMに割り振られた"IMSI"と呼ばれるユニークIDは元々15桁だったが、用途が増えるに連れ、より大きなアドレス体系へと移行し、現在は元々通信のために使われていた"IPv6"と呼ばれる広大なアドレス体系の一部が、SIM用として割り振られている。

IMSIはIDブロックごとに国などの政府機関や民間団体に割り振られ、SIMに埋め込まれて利用される。そしてIMSIの埋め込まれたSIMの認証と、IMSIと紐づく情報の保護を行うための認証プロバイダ(以前はクラウドやキャリアと呼ばれた企業)により、巨大な仮想空間の中で運用される。

過去に発行された社会保障番号マイナンバー、電話番号といった類のID体系はすべてこのSIMに収れんされ、強固な認証やブロックチェーンを用いて保護されて、様々なデータに紐つけられ、利用されている。

このSIMは大きく2つの形状もっている。一つは形がなく、電子情報に付与されるvSIM、そして物理的なものに付与されるnSIM。

古く使われた「SIMカード」や「eSIM」と呼ばれたものと比べても極小のnSIMは、カーボンナノチューブで作られており、仮想空間と物理空間の個別の物体を識別/認証するためのIDとして、世の中のありとあらゆるものに付与されている。

また至る所に張り巡らされた高周波網から出力される電波を使い、nSIMはそれ単体で駆動/通信することができ、nSIMの付与された対象物の様々な情報を常に仮想空間上のコピー(Thing Shadow)に反映させることができるようになっている。

このコピーにより、個人の所有物の管理を仮想空間上で容易に行えるだけでなく、Thing間の協調動作により、人と会話をしたり、事故を未然に防いだり、体調管理を行ったりすることができ、社会基盤として大きな役割を担っている。

「昔の人は、几帳面だったんだな。俺なんか部屋の物への最終アクセス履歴がないと、掃除も出来ないよ」

「それは私もそうね。冷蔵庫からレコメンドがないと、美味しい料理は作れないわね。」

そう言いながら、彼女はふと視線をそらす。おそらくどこかから連絡が入ったのだろう。

「ごめんなさい、上司から呼び出しがあったの。対面で話がしたいって。」

「仮想でなくて対面でなんて、よほど重要な用事なのかな。」

「おじいちゃんだから、仕方がないわ。」

そういうと彼女は荷物を一つにまとめはじめた。

「それじゃあね。またどこかで。」

上目遣いで笑いかける彼女に、心拍数が上がるのを僕のThing Shadowが見逃さなかった。頭のなかでアラートが鳴る。

「あのさ、その、よかったら君のIMSI、教えてくれないかな?」

驚いた彼女は一瞬考えたあと、いたずらな顔をして、彼女自身のIMSIと、先ほどのSIMカードを差し出した。

「このSIMカードからの連絡なら、出てあげる。年代モノだから、これが使える通信機器を探すのも大変だと思うけどね。」

そう言うと、彼女の体が光りに包まれ、少しづつ薄くなっていった。彼女を取り巻く無数のSIMが、物質情報をデジタルにプロトコル変換して転送する、「SORACOM Beam」と呼ばれる転送方式。

「早く電話してこないと、他の誰かにSIMロックされちゃうから。」

そう言い残した彼女は、電子の海へ消えた。

SIMを通じて融合する仮想空間と物理空間、その中で生きる人と人、人と物には、予測できない出会いがまだまだたくさんある。無数のSIMによりヒトとモノがつながり、そして共鳴する街、SIM City。この幸運のSIMカードが使える電話への出会い、そして彼女との再会を楽しみにして、僕は街に踏み出した。

 

PDFBoxとFXGraphics2Dを使って大きなPDFをレンダリングする

この記事は、JavaFX Advent Calendar 2015 - Qiita の 16 日目の記事です。

昨日は kimukou さんの 

basilisk-fw について試食した雑感 - exception think でした。

はじめに

先日お伺いしたJJUG CCC 2015 fall でセッションをさせて頂いた際に、SORACOMの業務システムにJavaFXを使っていますよ、という話をさせて頂きました。

セッションの中では、Swaggerの話やAWS Lambdaの話などをさせて頂きましたが、「javax.smartcardioでSIMカードを読む」というくだりが(さすがにJavaの人たちなので)一番反応が良かったので、このアドベントカレンダーでもJavaFXを使ったカードリーダーにしよう、と思ったわけなのですが、よく考えるとカード読み取りの説明ばっかりでほとんどJavaFX出てこないな、と思いまして、今回は別の内容にすることにしました。

PDFBoxとFXGraphics2Dを使って大きなPDFをレンダリングする

タイトルそのままですが、JavaFXを使ったPDFViewerの話です。

JavaオープンソースPDFと言えばiTextを連想される方も多いと思いますが、iTextはPDF生成ライブラリの色が強く、画面や画像レンダリングの機能はありません(少なくともAGPL以前のものにはない)

このため、作成したPDFをJava上で表示したり、PDFレンダリング非対応のプリンタで印刷しようとすると、レンダリング機能のあるライブラリが必要になりますが、以前は日本語が使えるのは、JPedalなどの商用ライブラリしかまともに動くものはなかったかと思います。

しかしながら、最近Apache PDFBoxがメキメキと実力をつけてきたようで、最新版の2.0はまだRC2ながらも既に日本語レンダリングが行えるようになり、弊社でも帳票出力などに活用しています。

よくあるPDFBoxを使った表示サンプルは、以下の様なものになります。PDFBoxが提供するPDFRendererを使って作ったImageを、JavaFXのImageViewで表示しています。

gist.github.com

これの結果は以下のとおりで、一旦BufferedImageにレンダリングされたPDFが、JavaFX上で表示できます。 

f:id:c9katayama:20151216221304p:plain

スケールを大きくする

上記のPDFは、スケールが1倍(等倍)で表示されています。PDFの拡大はよくあるシチュエーションだと思いますので、ためしに上記PDFを10倍に拡大してみます。

サンプルコードの「int pdfScale = 1;」を10にすれば、10倍サイズでレンダリングされます。

f:id:c9katayama:20151216221618p:plain

正しく拡大されていますね。では50倍ではどうでしょうか?

実は50倍にすると、renderer.renderImageの部分で、OutOfMemoryErrorが発生します。

PDFBoxの提供するPDFRenderer#renderImageは、描画のために引数のスケールに応じたBufferedImageを用意するため、倍率が高いと巨大なBufferedImageが作られてしまい、OutOfMemoryErrorが発生してしまいます。

FXGraphics2Dを使う

PDFRendererクラスには、renderImageメソッドの他に、renderPageToGraphicsというメソッドが用意されています。

これは引数にjava.awt.Graphics2Dを取るメソッドで、これを使うとSwingのコンポーネントなど、Graphics2Dをグラフィックコンテキストに使用するコンポーネントに対して直接描画を行うことが出来ます。

これを使って、JavaFXコンポーネントに直接描画を行うことで、無駄な画像描画を行わず、拡大したPDFを表示することが出来ます。

しかしながらGraphics2Dはjava.awt時代のもので、直接JavaFXでは扱うことができません(もしかしたらSwingとのインターオペラビリティクラスにそういうのがあるかもしれませんが)

ということで、FXGraphics2Dというクラスを使用します。これはjFreeチャートの人が作ったクラスのようで、Graphics2Dと、javafxCanvasに書き込めるGraphicsContextのアダプタとして使用することが出来ます。

これを使って、PDFをJavaFXCanvasに直接書き込んでみます。

gist.github.com

等倍での書き込み。これは先ほどのrenderImageのものと変わりません。

f:id:c9katayama:20151216223854p:plain

 50倍での書き込み。正しくレンダリングできているようですが、左上を起点にしているので、緑色しか出ません。

f:id:c9katayama:20151216224043p:plain

 FXGraphics2Dを使ったほうは、倍率を上げても、その分大きなBufferedImageが作られるわけではないので問題なく描画できます。

緑色だけでは面白く無いので、ドラッグできるものも作ってみました。

gist.github.com

 PDFをドラッグした分、描画の起点をずらす実装が入っています。

Graphics2DにAffineTransformを設定すると、PDFRendererの描画処理の座標を、GraphicsContextに伝える際に座標変換出来ます。GraphicsContextはCanvasのサイズでClipされていますが、その範囲外でPDFRendererが行った描画処理を、座標変換することでClip内に収め、見た目ドラッグして移動したようにしています。

出来たサンプルを動かしてドラッグすると、以下の様な感じになります。

 

f:id:c9katayama:20151216230241p:plain

「世界中の」の「世」の部分ですね。ちゃんと描画できているのが分かります。

まとめ

PDFBoxは日本語対応も進んでいるので、2.0のリリースが待ち遠しいですね。FXGraphics2Dがあれば、既存のチャートライブラリなんかはひと通り使えると思うので、安心ですね。

JavaFXはSceneBuilderとeclipseという環境で開発していますが、UIとロジックが綺麗に別れるので、個人的には非常に便利だと思っています。AdobeFlexはまさにこういうスタイルだったので、Flex亡き今、Javaで生産性の高い仕掛けがあるのは非常に嬉しいです。

 

JavaをやっておきながらJJUGは実は初参加で、しばらくJava実装もやっていなかったのでJavaコミュニティーに行くのも4年ぶりぐらいで若干ビビってましたが、そんなことはなくてJavaの話で盛り上がれて、本当に楽しかったです。@makingさんのリアクティブの話や@sugarlifeさんのGCの話は非常に勉強になりましたし、特にSpringMVCがリアクティブでも頑張ってくれるという話は個人的には大興奮のポイントでした。

またTwitterではよく見かけているうらがみさんや、相変わらずスベってるセロさんにも会えましたし、なによりきしださんがセッション前に資料作成が終わってたのには驚かされました。人は成長するものですね。

そんなわけでまた機会があればネタを作ってJavaイベントに参加したいと思います。

 

明日はskrbさんのブログです。

 

 

 

 

 

 

SORACOMの提供するCSVのご紹介

みなさまこんにちは。毎日SIMを焼いています。ソラコム片山です。

好きなSIMは標準サイズです(ちょっとカードが厚いので、焼き心地がいい)

はじめに

ソラコムリリース記念ブログも終盤戦に差し掛かり、素晴らしいエントリーが揃ってきました。ありがたい限りです。

私も自分な好きな機能について書こうと思い、先日のSORACOMデベロッパーカンファレンスでもLTでご紹介した「SORACOMイベントハンドラー」のエントリーを考えていましたが、実はイベントハンドラーの話はジャストインケースの松井さんにがっつり書かれてしまい、ネタがかぶってしまいました(ちなみに松井さんも、SORACOM Beamのネタをクラスメソッドの大瀧さんに書かれてイベントハンドラーネタにしたそうで、完全に玉突き事故状態です)

 

そんなわけで今朝、家で「何かいいネタないかな?」と相談したところ、「私の銀行口座の残高が減ったら通知されて、自動的にお金が振り込まれる仕組みとかいいんじゃない?」というとても嫌なイベントハンドラーのアイデアをもらいましたが、そもそもSORACOM関係ないということで、丁重にお断りしました。

 

ということで、SORACOMの機能でまだ紹介されていない部分のご紹介をしたいと思います。

やっぱりCSV

先日のLTでも、@manacatさんが「みんな大好きCSV」とおっしゃられていましたが、ご多分に洩れずSORACOMでもCSVを提供しています。

CSVは大きく分けて2つで、「データ使用量」と「利用料」の2つになります。

データ使用量

このCSVは、IMSI単位で使用したSORACOM AirおよびSORACOM Beamの使用量を取得するものです。コンソールでは、課金情報タブの下側に取得メニューがあります。

f:id:c9katayama:20151021183433p:plain画面からは、過去6ヶ月間(月ごと)もしくは過去90日間(日ごと)のいずれかを選べますが、APIを使用していただければ、unixtimeのfrom-toと月ごと/日ごと/詳細(分単位)の指定でデータを取得することができます。

以下はSORACOM AirCSV(日ごと)のサンプルです。項目は見ていただければ想像がつくと思いますが、各IMSIごと(SIMごと)に項目が分かれており、さらに日ごと、速度クラスごとに上り下りの通信バイト数とパケット数が取得できます。

f:id:c9katayama:20151021184627p:plain

 

SORACOM Beam(日ごと)の場合は、以下のようになります。

f:id:c9katayama:20151021185542p:plain

こちらもわかりやすいと思いますが、IMSIごと、日ごと、Beamのプロトコルのin/outごとに、通信カウントを取得することができます。

 

またいずれのCSVにも、CSV右側の方にいろいろな文字がひっついてきます。

これはタグとグループになっていて、すべてのタグおよびグループが項目名として列挙されており、タグ/グループがついたIMSIの行には、そのタグ/グループの値が入ります。

f:id:c9katayama:20151021192107p:plain

これを使っていただくと、所有者や部署単位での集計や、通信量の多いIMSIを見つけたりすることが簡単に行えます。

APIはこちらのリンクから確認できます( Air, Beam )

 

利用料

データ通信の利用料の明細を、月ごとにCSVを取得することができます。画面では同じく課金情報タブの「最新の請求予定額」および「過去の請求履歴」から取得できます。

f:id:c9katayama:20151021193327p:plain

f:id:c9katayama:20151021193417p:plain

 最新の請求予定額の部分は、当月の予定額が逐次計算されたものをCSVで取得することができます。また支払済の月については、確定したデータをCSVで取得することができます。

f:id:c9katayama:20151021193921p:plain

利用料についても、IMSIごと、日ごと、品目ごとに単価(unitPrice)、数量(quantity)、金額(amount)のデータが取得できます。

billItemNameというのが課金項目で、現在は以下のような項目があります。

basicCharge-{状態}

基本利用料。-ready(SIMを登録した状態)-active(通信可能状態) -inactive(休止状態)がそれぞれ 別で計算されます。

downloadDataCharge/uploadDataCharge-{速度クラス}-{時間}

上り下りのデータ通信料。速度クラス(s1.fastなど)ごとに分かれており、さらにdaytime(日中)とnighttime(夜間)ごとに分かれています。

quantityは通信バイト数、unitPriceは1byteごとの単価になっています。

docomoSMSCharge

SMS付きのSIMでSMSを利用した場合の料金。quantityがSMS送信数となっています。

soracomBeamRequestCharge-{in/out}{プロトコル}

SORACOM Beamの利用料。-inHttpなど、各プロトコルのin/outごとに明細になっています。quantityがBeamのリクエスト回数になります。

dataTrafficFreeTier

データ通信料の無料利用枠(30円まで)。金額がマイナスで表示されます。

soracomBeamRequestFreeTier

SORACOM Beamの無料利用枠(10万リクエストまで)。こちらも金額がマイナスで表示されます。

すべての項目には消費税がかかっていないため、請求額としては合算後に消費税を適用した金額となります。

 

なお、利用料のCSVについても、データ使用量と同じくIMSIごとにタグおよびグループが付与されていますので、部署や地域ごとに費用を算出したり、たとえば夜間だけやたらと利用の多いIMSIを見つけたりすることができます。

 

まとめ

結局「CSVのご紹介」という地味な内容となってしまいましたが、ぜひ上手くCSVをご活用頂ければと思います。

 

CSS Niteみたいな感じで「CSV Nite」とかやったら人来ますかね?私は行かないですが。