今年もCOVID-19蔓延により状況が難しい状況ですので、MI68にはリアル出展ではなくバーチャル出展(URLを掲載してもらうのみ)とさせて頂きました。これにより会場では直接お会いできませんが、YouTubeに繋がる環境であれば世界中どこからでも、場所を問わず無料で参加頂けます。ピンチがチャンス!! (2回目)

視聴はこちらのランディングページからどうぞ!!

"Mushagaeshi" means the basement rock structure of Kumamoto castle, the ancient architecture of real Samurai era in Japan.
最終更新: 2020/06/27 22:14 (執筆時最新のRaspberry Pi OS + RaSCSI 1.47で更新、ブリッジデバイス+RASDRVの項目も更新)
先日X68000初代の修理を終えたので、改めてGIMONSさんのRaSCSIの設定をいちからやり直してみた。なお、本設定の元に筆者はX68000XVIで常用している。
ちなみに、RaSCSI(ラスカジー)とは、要するにRaspberry Pi(ラズベリーパイ)をSCSIハードディスクみたいに使えちゃう、という古くて新しいナウなガジェットである。これを導入すると、何とX68000やらFM TOWNSやらPC-9801やらでSCSI起動ドライブをRaspberry Piで代替出来てしまうのである。しかもRaspberry Pi OS経由で動くのでHDDイメージをWi-Fi経由でいじくる事も可能。恐るべきレトロ未来感覚・・・(ごくり)
※SCSI(スカジー)って何ですか? と聞かれたら困るんですが、まあ要はSATAのご先祖様のIDEのもっと昔のご先祖様と考えてもらえれば。機種を超えたドライブ接続の標準規格として1980年後半から90年代前半に大流行しました。接続する各ドライブにはIDを0番から7番まで設定して接続します。7台まで数珠つなぎ(デイジーチェーン)できます。
RaSCSIはLinuxのディストリビューションであるRaspberry Pi OS(ラズベリーパイ・オーエス)の上で動くため、UNIX系の操作がある程度出来る事が前提となる。まあ、ここはしょうがないので諦めて慣れましょう。
念のため本記事の前提となっている我が家の環境も書いておく。
どこかで適当に。どこでもいいと思うけど、専門店の方がいいんじゃないかなと。近所にお店があればそちらで是非。ちなみに少し高いPi 3 Model B+や最新の4という高速モデルも出たのだが、3B, 3B+, 4どれでもOK。だが、3B+や4は発熱が強いため、安い3 Model Bの在庫があれば、総合的にそれが良いだろう。
合わせて、レベルコンバーターシールドで基板全体が覆われることになるため、放熱を考えて出来ればヒートシンクも付けておこう。
Raspberry Pi 3B/3B+ を使う場合は、3.0A USB出力のACアダプターも一緒に。出力が足りなくてちゃんと動作しないケースが多すぎるんで、最低限3.0Aは必須で是非。
Raspberry Pi 4の場合は、3.8AのUSB-Cモデルを買うこと。上記のmicro USB 3.0Aアダプターからの変換だと出力が出ないように制限されるため、正常に動作しない。必ず専用品を買うこと。これは絶対の約束。
マイクロSDカードは16GB、Class 10辺りを選択すべし。遅くても動くと思うけど、余計な不安要素は最初に潰して置いた方がいいかと。もちろん、大容量のHDDを何台もぶら下げたい場合は、もっと大きいマイクロSDカードを選ぼう。
何種類か出ている模様。筆者はは公式のfullspec版を使っているので、以下の説明もfullspec版をベースにしている。該当部分は赤字にしているので適宜読み替えを。
Raspberry PiはRaspberry Pi OS等のOSの上で動く。ので、OSを起動しないRaSCSIは動かない。まずOSの設定から。
※つまり、RaSCSIが動作するまでにはOSが起動するまでの10秒くらい待たねばならない、ということ。実際に使う際には先に電源を入れるように。
最初にRaspberry Pi OSイメージのダウンロード。Raspberry Pi OS (32-bit) Liteを選択。Lite版ではないものもあるが、GUI等余計なものが入っているし、RaSCSIの動作にはほぼ役に立たない(むしろ余計なプロセスが増えて良くない)ので、最小構成であるLite版を推奨。
イメージ書き込みはRaspberry Pi公式で推奨のソフトのEtcherをダウンロード。これでSDカードにイメージを書き込む。(もし書き込みで進捗が進まない場合は、一回マシンを再起動して再挑戦。多分それで治るかと)
書き込んだSDカードをRaspberry Piに差して起動。
マイクロUSB電源を差すと勝手に起動する。黒い画面でログオンプロンプトが出てきたら、ID: pi, Password: raspberry でログオン。
以下でWi-fi・タイムゾーン・言語の設定を行う。(“$”はコマンドプロンプトの文字なので、この文字が出ていたらコマンドを叩き、Enterキーを叩いて実行すると読んで欲しい)
$ sudo raspi-config
青い画面のメニューが出てくるので、そこから下記の設定を行う。
上記が終わればFinishで完了。最後にRaspberry PiのIPアドレスを控えておく。確認する項目は”wlan0″で、IPアドレスは “inet”の項目。後ほどここに接続する。
$ /sbin/ifconfig -a
下記で手動にて再起動。
$ sudo shutdown -r now
実機での作業はここまで。以降はWindows/Mac/Linux機からSSHで接続して作業する。
Raspberry Pi OSを直接いじくるのはめんどくさいので、これ以降はリモートで作業。ここでRaspberry PiからHDMIケーブルとUSBキーボードは外してOK。電源ON状態でいきなり抜いてもOK。
まずSSHクライアントを入れる (WindowsだとPoderosa辺りで。macOSだと標準で入っているので、Terminalから”ssh -l pi <IP_ADDRESS>”で接続)。
次にSFTPクライアントを入れる (WindowsだとWinSCP辺りで。MacだとFileZillaやCyberduck辺りか)。
SSHで控えておいたIPアドレスに接続する。接続出来たら、まずOSを更新し、一旦最新にしておく。あと、時刻同期のためのNTPクライアントとしてchronyもついでに入れておこう。終わったら恐らくカーネルが最新に置き換わってる可能性大なので、一旦再起動。
$ sudo apt-get update;sudo apt-get -y upgrade $ sudo apt-get install chrony
$ sudo shutdown -r now
10-20秒程度待って再度SSHよりログオン。
それでは本作業開始。外部マシンでRaSCSIをダウンロード。「RaSCSI version 1.47」を選択する。(バージョン番号は適宜読み替えて)
もしRaspberry Pi OS側で直接ダウンロードしたい場合は、curlというコマンドが使えるので、それで直接ダウンロードのURLを叩いてしまう。ダウンロードしたものはファイルとして保存する必要があるので、”-O”オプションを忘れずに。
$ curl <FILE_URL> -O
もしくは、リモート側でダウンロードして、RaspberryPiにSFTPで転送する。転送後、Raspberry Pi OS側でZIPを伸張する。
$ unzip rascsi147.zip
展開したファイル内の “bin/raspberrypi/rascsi.tar.gz” が本体。これを更に伸張する。
$ cd rascsi147/bin/raspberrypi $ tar xvzf rascsi.tar.gz
これでRaSCSI側の基本準備は完了。
次に、SCSI HDDイメージを作成する。作成はXM6で。XM6のインストールや操作方法は割愛。XM6を起動させ、メニューの”Tools > Make a new SCSI Fixed Disk”でSCSI HDDイメージを作成する。一旦XM6の最大値である4GB(4096MB)で作成しておいてもOK。
但し、SCSIとして利用する機種・OSによって最大値が決まっているのでそれに従う。例えば、X68000でSCSI利用であればブートパーティションは1GB以内であるべきだし、更にそこにXCをインストールする場合は768MB程度に抑えておかないと途中でエラーで止まる、等々の制約があるのでそれに倣うよう。PC-9801/PC-9821系であれば、544MBの壁等が機種やSCSIボード・OSごとにあるため、あらかじめ調べておこう。
作ったHDSファイル(以下ファイル名を”x68000scsi0.hds“とする。何でもOK)をSFTP等でRaspberry Pi OS側のrascsiディレクトリーへ転送する。転送が終わったら、基板に応じてバイナリーを選択し起動してみる。(ここではfullspec版の例)
$ sudo fullspec/rascsi -ID0 x68000scsi0.hds
正常に起動したら以下のメッセージが出る
SCSI Target Emulator RaSCSI(*^..^*) version 1.47(Apr 11 2020, 23:01:38)
Powered by XM6 TypeG Technology / Copyright (C) 2016-2020 GIMONS
Connect type : FULLSPEC
+----+----+------+-------------------------------------
| ID | UN | TYPE | DEVICE STATUS
+----+----+------+-------------------------------------
| 0 | 0 | SCHD | x68000scsi0.hds
+----+----+------+-------------------------------------
上記がうまく動いたら、起動しっぱなしで停止する。そのままではどうしようもないので、一旦Ctrl+Cで停止させる。
一旦うまく動いたらしめたもの 。が、このままではRaspberry Piの電源をOFFにしたらプロセスが未起動状態となり、また上記の起動を手動で行わねばならなくなる。自動で全部Ready状態にするために、下記の作業を最後に行う。
まず、HDDイメージファイルであるHDSファイルをOS上適切な位置に配置する。SysV以降の習わしとしては、可変ファイル(variable files)は /var 配下に置くことが決まっているため、RaSCSIもそれに従おう。/var/rascsi ディレクトリーを作成し、そこに移動する。
$ sudo mkdir /var/rascsi
$ sudo mv x68000scsi0.hds /var/rascsi
次に、RaSCSIをRaspberry Pi OS上の適切な場所へ移動する。apt等で管理されない所謂「オプショナルパッケージ (optional packages)」は/optに置くのが同じくSysV以降の習わしなのでまず移動。複数のバージョンを管理したいのと、バージョンアップ時に楽をしたいので、バージョン番号付きのディレクトリーにリネームしながら移動して、シンボリックリンクを張っておく。これで新しいバージョンが出てもシンボリックリンクの作り直しだけでOK。
$ cd rascsi147/bin $ sudo mv raspberrypi /opt/rascsi-1.47 $ sudo ln -s rascis-1.47 rascsi
※もし、RaSCSIが将来バージョンアップした場合は、シンボリックリンクを張り直してやろう。下記は1.48(執筆時点ではまだ出てない)が出た場合の例。RaSCSIのデーモンを停止し、”rascsi”のシンボリックを最新のディレクトリーに張り替えて、デーモン再開、という処理となる。
$ sudo systemctl stop rascsi
$ sudo mv raspberry /opt/rascsi-1.48
$ cd /opt
$ sudo rm rascsi
$ sudo ln -s rascis-1.48 rascsi
$ sudo systemctl start rascsi
次にRaSCSIの起動スクリプトを作る。
$ cd /etc/systemd/system/ $ sudo nano rascsi.service
テキストエディターnanoで新規作成された「rascsi.service」に対し、下記をコピペする。(もちろんvimが使える方はそちらでも)
[Unit] Description=RaSCSI After=syslog.target [Service] Type=simple WorkingDirectory=/opt/rascsi ExecStart=/usr/bin/sudo fullspec/rascsi -ID0 /var/rascsi/x68000scsi0.hds TimeoutStopSec=5 StandardOutput=null [Install] WantedBy = multi-user.target
上記をCtrl+X → [Enter]で保存する。systemctlに認識されるようになるので、rascsiプロセスを自動起動に設定する。
$ sudo systemctl enable rascsi
Created symlink /etc/systemd/system/multi-user.target.wants/rascsi.service → /etc/systemd/system/rascsi.service.
設定が終わった。自動起動するように変更されているはずなので、念のため再起動してみる。
$ sudo shutdown -r now
再起動後にプロセスが自動起動しているか確認する。SSHで再接続し、下記を叩いて表示が出ることを確認する。出ない場合は正常起動していないので、上記設定を再確認。
$ cd /opt/rascsi $ fullspec/rasctl -l
+----+----+------+-------------------------------------
| ID | UN | TYPE | DEVICE STATUS
+----+----+------+-------------------------------------
| 0 | 0 | SCHD | /var/rascsi/x68000scsi0.hds
+----+----+------+-------------------------------------
Human68K 3.02書き戻した。これで勝てる!!! pic.twitter.com/rjvKHZAqSl
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2018年2月18日
ここから先はFM TOWNSだったりPC-9801だったりと各者各様で良いかと思うので具体的には割愛。SCSIコネクターに接続し、先にRaspberry Piの電源を入れて10秒くらい待って、マシンを起動すれば、(ある場合は)RaSCSIボード上のランプが光ってマシン上でDevice ID: 0として認識する。あとはOSのインストール等々、通常のSCSI HDDとして煮るなり焼くなり好きにするが良い。
RaSCSI、カーネルモジュール入れてSCSIケーブルを換えてみたら認識するようになった! pic.twitter.com/BdWaOY4eRQ
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2018年2月19日
RaSCSI、insmodの順番をrascsiプロセス起動より先にしてみたら安定した! X68000(CZ-600C)+CZ-6BS1+とむねこさん基板+Pi3B pic.twitter.com/C3Sl7NksOS
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2018年2月20日
更に、X68000だけの特別追加機能として、イーサネット機能及びホストファイルシステム(ホスト機でSCSIドライブをネットワークドライブとしてマウントできる機能)等がある。詳しくは付属ドキュメントの”doc/x68k.txt”を参照のこと。多分ここで書くよりそちらを参照した方が良い。というかこの2019年に実機でSCSI使える人ならそんなこと書かなくても分かるでしょ! (が、あとで書くかも)→下に書きました
結局書いてしまった・・・ということで続き。RaSCSIにはX68000専用に二つの機能が提供されている。ひとつがRaspberryPiのEthernet機能を使わせてもらうネットワークデバイスドライバー”RASETHER.SYS”、もうひとつがRaspberryPiのファイルシステムを直接参照できるファイルシステムドライバー”RASDRV.SYS”。
前者は実際問題としてクライアントソフトとして古くさいtelnetソフトウェア等を使うことになりセキュリティー的に疑問なのでここでは取り扱わず、安全な後者の解説に留める。
この後者”RASDRV.SYS”であるが、下記の設定でX68000からRaspberry Pi OSの中身を参照できる。ので、あとはRaspberry Pi OS側とWindowsやらMacやらとSFTP辺りでファイルをやりとりできれば、何と稼働中のX68000とリアルタイムでファイル連携が出来るのである。何という万能感。X68000とのファイルのやりとりのためにSCSIのMOドライブを繋いでおく時代は遂に終わったのです(いや、とはいえ便利なのでMO環境は残しておいた方がいい気もする・・・)。
まず、RaSCSIの配布パッケージに含まれている “bin/x68k/RASDRIVER.HDS”のHDDイメージにRASDRV.SYSが含まれている。これをRaSCSIにマウントさせるだけでX68000からRASDRV.SYSを操作できるようになる。まずはここからだ。
手順としては下記となる。
では順番に見ていこう。
RASDRIVER.HDSはRaSCSIの配布イメージの中に含まれている。これを/var/rascsiにコピーしよう。
$ sudo cp bin/x68k/RASDRIVER.HDS /var/rascsi
これは上記で記述したスタートアップ設定ファイルに追記するだけだ。
$ sudo vi /etc/systemd/system/rascsi.service
中身をこのように変更しよう。緑色の箇所が追記したポイントだ。-ID1が仮想ドライブ用のブリッジデバイス名、-ID2がRASDRIVER.HDS用だ。この「ExecStart=」から「.HDS」までは一行で記載しよう。
[Unit]
Description=RaSCSI
After=syslog.target
[Service]
Type=simple
WorkingDirectory=/opt/rascsi
ExecStart=/usr/bin/sudo fullspec/rascsi -ID0 /var/rascsi/x68000scsi0.hds -ID1 BRIDGE -ID2 /var/rascsi/RASDRIVER.HDS
TimeoutStopSec=5
StandardOutput=null
[Install]
WantedBy=multi-user.target
これで再認識&再起動させる。きちんと認識しているかどうかまでrasctlを起動して確認を入れておこう。緑色の行が出ていれば成功。
$ sudo systemctl daemon-reload
$ sudo systemctl restart rascsi
$ /opt/rascsi/fullspec/rasctl -l
+----+----+------+-------------------------------------
| ID | UN | TYPE | DEVICE STATUS
+----+----+------+-------------------------------------
| 0 | 0 | SCHD | /var/rascsi/x68000scsi0.hds
| 1 | 0 | SCBR | HOST BRIDGE
| 2 | 0 | SCHD | /var/rascsi/RASDRIVER.HDS
+----+----+------+-------------------------------------
X68000を再起動させる。RASDRIVER.SYSはDドライブに登録されている筈である。中身にあるRASDRV.SYSをAドライブのどこかにコピーする(下記ではA:\SYS。どこでもよい)
>b:
>copy RASDRV.SYS a:\SYS
“A:\config.sys” を開いて、RASDRVを登録してやる。
A:\> ed config.sys
下記の行を “DEVICE=” の最後の行に追加する。
DEVICE = \SYS\RASDRV.SYS
書き終わったら “ESC → E”で保存。その後にX68000のリセットボタンを押して再起動。起動時のログにD:ドライブが追加された、という下記のようなメッセージが出れば成功。
RaSCSI FileSystem Driver version 1.42 ドライブE:を登録しました
RaSCSIのRASDRV.SYSをHuman68kのconfig.sysに設定してみた。ちょっと注意点があるんで、Blogに追記しとこう… pic.twitter.com/JYwta4OjXH
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2018年3月19日
あとは起動完了後にEドライブを覗いてみれば・・・あら不思議、X68000からRaspberryPiの全てが見える!!
RASDRV.SYSヤバい。X68000からRasperryPiの中身丸見えやん…(ゴクリ pic.twitter.com/Bgf5tLgMVn
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2018年3月19日
あとは、RaspberryPiに向けてSFTPでファイルを “/home/pi” 辺りに転送してやれば、X68000からは “E:\home\pi” で参照出来る訳です。無線でX68000とファイルのやりとりが出来るなんて21世紀は何て素晴らしいんでしょう!!!
ちなみに、Raspberry Pi OSのルートから公開したくない場合は、”config.sys” の設定で下記のように記載すれば “/home/pi” の直下が “E:” ドライブの直下として見えるので、そのようにしても良いだろう。いやむしろそうした方が良いかもしれない。お好み・用途に応じて。
DEVICE = \SYS\RASDRV.SYS /home/pi
このまま使ってもらっても良いのだが、RASDRIVER.HDMのBドライブへの登録が残った状態になっている。最後に外してやろう。Raspberry Pi OS側に戻り、登録を外す。
$ sudo nano /etc/systemd/system/rascsi.service
サービス定義からRASDRIVER.SYSを外す。
[Unit]
Description=RaSCSI
After=syslog.target
[Service]
Type=simple
WorkingDirectory=/opt/rascsi
ExecStart=/usr/bin/sudo fullspec/rascsi -ID0 /var/rascsi/x68000scsi0.hds -ID1 BRIDGE
TimeoutStopSec=5
StandardOutput=null
[Install]
WantedBy=multi-user.target
リロードし、念のためドライブ状況を確認しておこう。RASDRIVERの行が無くなってれば成功。
$ sudo systemctl daemon-reload
$ sudo systemctl restart rascsi
$ /opt/rascsi/fullspec/rasctl -l
+----+----+------+-------------------------------------
| ID | UN | TYPE | DEVICE STATUS
+----+----+------+-------------------------------------
| 0 | 0 | SCHD | /var/rascsi/x68000scsi0.hds
| 1 | 0 | SCBR | HOST BRIDGE
+----+----+------+-------------------------------------
最後にX68000を再起動させる。RASDRVがDドライブに変更されたはずである。前記「E:」で書いた箇所は全てD:に変更されているので読み替えを。もちろん、HDSイメージを何個もマウントするとこのドライブ名が後ろにどんどんズレていくことになるのでご注意を(これは恐らくHuman68Kの仕様)。
RaSCSI FileSystem Driver version 1.42 ドライブD:を登録しました
それではお宅のレトロマシンの幸せなSCSIライフを!!!
Java EE Advent Calendar 2017の23日目です。昨日は@suke_masaさんの「Java EEにMVCはなぜ必要なのか」でした
今年はJavaOne 2017で1枠、Oracle OpenWorld 2017で1枠、Japan Sessionで1枠と、3枠の公演をしてきました。その共有会を福岡で12月に実施したのですが、そこで取り扱ったJava EE 8での差分について、改めてこちらにまとめておきます。
なお、類似の話は恐らく各所にあると思うので、読み込んでいるプロな方には今更感が満載だと思います。が、Advent Calendarはそういう趣旨では無いと思いますので、まあこういう記事があってもいいじゃないですかね。という感じで。
まず、今年のJavaOne 2017 (のちょっと前に)でJava EE 8がリリースされました。Java EEは特定の製品でも何でもなく「アプリケーションサーバーの標準仕様」となります。
※なので軽い気持ちで「Java EEは品質が悪い」とか「遅い」とか放言すると、周りの技術者から冷酷な目で見られるので注意しましょう(笑)
そのため、Java EE 8仕様に準拠したアプリケーションサーバーはこれから登場します。Java EE仕様策定に参加している会社・コミュニティー間で合意が取れ、標準仕様が決まったばかりですので。現時点ではとりあえず参照実装の位置づけであるGlassfish 5がリリースされています。また、商用製品としては、製品版以前の状態としては、Payara 5 Beta 1がリリースされています。
※当然ですが、実稼働システムを検討する場合、Glassfishは絶対に選ばないで下さい。セキュリティーパッチが出ません。 これは旧4系でも同じです。速やかに商用版であるPayaraもしくは別の製品に移行しましょう。
なお、Java EEの開発はこのあとEE4Jというプロジェクトに移管されることになっていますが、この件は本記事とあまり関係ないので飛ばします。Java EE 8より先の話です。
Java EE 8仕様は、1999年末に出たJ2EE 1.2仕様から数えて6回目のメジャーバージョンアップとなります。メジャーバージョンアップなので各種の改善と非互換が出ています。本記事の要旨はここになります。
なお、Java EE仕様の暗黙のルールとしては、「過去の技術は二つ前の仕様までサポートする」となります。例えば「Java EE 8仕様に準拠したアプリケーションサーバーは、Java EE 6仕様に準拠したアプリケーションを動かすことが出来る 」というものです。Java EE 6は2009年末に出ていますので、約8年間以上は大丈夫、という実績があります。まあ、古いアプリケーションサーバーを使えばもっと行けるので、10年ちょいは間違いなく大丈夫でしょう。Java EE仕様でアプリケーションを作成する場合は、できるだけ最新仕様を使うようにしましょう。
これは裏を返せば、Java EE 8仕様のアプリケーションサーバーは遂にJava EE 5仕様のアプリケーションが動かなくなります。Java EE 5仕様自体は2010年頃まで普通に使われていましたので、移行を検討しましょう。商用アプリケーションサーバーによっては、ひょっとしたらサポートしてくれるものがあるかも知れませんが分かりません。もしくは、Java EE 5が動くアプリケーションサーバーを後生大事に取っておくか、です。EOLの後でも数百万~数億となる大量のお金を投入すれば可能でしょう。この領域には余り興味がありませんが・・・
※ちなみにWikipediaのJava EEの項目を見たところ壮絶に古い記載で今となっては不適切だったりするので、そのうち書き換えます。
さて、そんなJava EE 8ですが、EE 7との差分がどれだけあるかというと、然程ありません。それだけEE 7仕様が優れていたということでもあるのですが、要は明らかに足りなかった機能を追加しました、という感じのメンテナンスリリースと捉えてもらえれば間違いないかなと思います。なのでエンプラ界隈が「Java EE 8が出た! これからはEE 8で未来が変わる!」というような感じになっていないのは正しい反応です。
ちなみにJava EE 8は本来、去年のJavaOne 2016で発表予定だったのですが、急遽延期になってしまった経緯があります。その影響か、Java EE 8ネタでJavaOne 2016のCall for Proposalに応募していた末席の私はもちろん、その界隈で著名な方々(Oracle社員除く)も丸ごと落とされてしまい、人知れず枕を涙で濡らしたのでした。そんな遺恨もあり、界隈のJava EE 8への視線は更に厳しいものになったのですが、実に余談なのでこれ以上は止めておきましょう。
さて、次からは技術記事らしく、中身を見ていきましょう。
Deployment Descriptor (DD)と書くとEJB 2系以前に必須であったDDであるejb-jar.xmlを思い出して拒絶反応を示す人が未だに多いですが、それだけではなくWARの中にあるweb.xmlも、JPAで使うpersistence.xmlも立派なDDなので、混同しないようにしましょう。ちなみに、ejb-jar.xmlはEJB用としてまだ使えますが、アノテーションで代替出来るため不要となりました。もしあれば、アノテーションより優先して扱われるものとなっています。
さてこのDDですが、XMLであるため冒頭にXML SchemaのXSDを指定するようになっています。こんなのどうでもいいじゃん、と思いがちですが、実はアプリケーションサーバーはこのXSDを参照して「このアプリケーションはどのJava EE仕様に則って作られているのか」を判断しています。例えばweb.xmlを古いまま使い回しているWARであれば、古いままのJava EE仕様で動作してしまうということです。新機能を使おうと思ったんだけど呼び出されない、等々で何日も悩む羽目に陥らないよう、まず最初に書き換えましょう。
例: web.xml
[code lang=”xml”]
<web-app xmlns=http://xmlns.jcp.org/xml/ns/javaee
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0" metadata-complete="true">
…
</web-app>
[/code]
例えば上記のような感じです。一覧はこちらにありますのでどうぞ。 http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html
これは大きい変更です。Webシステムでログオン有無の管理は従来自前で処理するものでしたが、他のプラットフォームではあって当たり前な感じにもなっています。何で無いのよ、と訝しげに思う人も居たと思いますが、遂に追加されましたよ!
[code lang=”java”]
UsernamePasswordCredential cred
= new UsernamePasswordCredential(
entity.getUserName(), entity.getPassword());
AuthenticationParameters params
= AuthenticationParameters.withParams().credential(cred);
AuthenticationStatus status
= securityContext.authenticate(httpServletRequest,
httpServletResponse,params);
[/code]
プログラム上のAPIを呼び出すコードは上記の感じで簡単ですが、問題はこのコードがどう動くべきか、をカスタマイズなり設定なりが必要となります。そりゃぁ、企業システムのID管理なんて千差万別な訳ですよ。Active Directoryだったり生LDAPだったりデータベース+JSONだったりと。対象が社員だったり顧客だったりするとまあ更にバリエーション豊かになります。そういうのを吸収するAPIとして制定されているようです。
例えばデータベースへ問い合わせする場合は、このようなアノテーションをAppliationConfig.java辺りに書く感じです。これなら分かりやすいかな?
[code lang=”java”]
@DatabaseIdentityStoreDefinition(
dataSourceLookup="java:global/MyDS",
callerQuery="select password from user where user_name = ?",
groupsQuery="select group_name from user_groups where user_name = ?"
)
@ApplicationScoped
@Named
public class ApplicationConfig {
…
}
[/code]
なお、標準機能としてはLDAP接続とデータベース接続辺りがサポートされていて、更にカスタムで接続を実装することが可能となっています。なのでどんな認証でもこのAPIで吸収することが理論的に可能と考えられます。恐らくこのあと実装例が多々出てくると思いますので、それを待っててもいいかもですね。
詳しくは@kodukiさんの「Java EE Security APIが街にやってきた!」でもっと詳しくありますので、気になる方はそちらへどうぞ。
つぎ、JSONとJavaプログラムを相互に変換するAPI、通称JSON-Bが追加されました。これ、慣れてる人だと、Java EE 7でCDIがREST対応した際にもJSONは使えたので、何を今更? という感じではあるかもですが、正式な単独仕様として追加されました。JavaオブジェクトからJSONへの変換は特にRESTの呼出し元側で必要となったりするので、この仕様は特にJavaFXや単独Javaアプリケーション辺りで特に使えるのではと感じます。
たとえばこんなJavaのクラスに値が詰まってたとして
[code lang=”java”]
public class Dog {
public String name;
public int age;
public boolean bitable;
}
[/code]
これをこんなJSONに変換したい、となると、
[code lang=”json”]
{
"name": "Falco",
"age": 4,
"bitable": false
}
[/code]
こんなコードだけで行けちゃいます。
[code lang=”java”]
// Serialize. Java to JSON
Jsonb jsonb = JsonbBuilder.create();
String dogJsonResult = jsonb.toJson(dog);
// Deserialize. JSON to Java
String dogJson = "{\"name\":\"Falco\",\"age\":4,\"bitable\":false}";
Dog deserializedDog = jsonb.fromJson(dogJson, Dog.class);}
[/code]
便利ですねぇ。便利すぎてアホになっちゃいそうです。入出力の細かい制御をしたければ更に色々出来ますが、通信相手側のの謎仕様JSONに合わせねばならない場合以外にはあまり使い道が無さそうではあります。
CDI (Contexts and Dependency Injection)がメジャーバージョンアップしました。要は昔流行ったDI(依存性注入)やアスペクト指向です。まあ、バズワードの一種ではありましたが、一部便利になったことは間違いないでしょう。Java EE内の位置づけとしてはポストEJBという感じで徐々にEJBの機能を絶賛移植中です。もっとドバーと一気に移植しちゃえばいいのにと思わなくも無いですが、そこまで重量級のものも要らないよね、ってことなのかも知れません。
まず追加されたのが、非同期イベントが使えるようになりました。EJBの@Asynchronous相当と思えばいいですが、もうちょっとややこしい感じです。EJBのように呼ばれ側で書くんじゃなくて、呼び元で書くという感じで、逆になってます。event.fireAsync() というメソッドを使います。
次に、EJBTimerに相当するスケジューラーをCDIからも使えるようになりました。ついでにEJBの@Startupも使えるようになりました。これはCDIコンテナーが初期化するタイミングで最初に呼ばれるメソッドです。初期化処理はここでやりましょう。
最後に、これが一番大きいのですが、Java SE環境でCDIが使えるよう仕様として公式にサポートされました。これまでも実装側で対応してたと思いますが、公式サポートは大きい。これで大手を振ってJava SE環境、特にJava SE環境で自己起動するような軽量なバッチ処理や、クライアント系アプリケーション、例えばJavaFX環境などでCDIを思う存分使いこなせるでしょう。
とりあえず動かしたい場合は、Mavenにこれを追加して・・・
[code lang=”xml”]
<dependency>
<groupId>org.jboss.weld.se</groupId>
<artifactId>weld-se-core</artifactId>
<version>3.0.2.Final</version>
</dependency>
[/code]
こんな空のMETA-INF/beans.xmlを追加して・・・
[code lang=”xml”]
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
bean-discovery-mode="annotated">
</beans>
[/code]
こんなコードで動きます。
[code lang=”java”]
public static void main(String… args) {
try (SeContainer container
= SeContainerInitializer.newInstance().initialize()) {
MyBean myBean = container.select(MyBean.class).get();
myBean.doWork(); // DO SOMETHING.
}
}
[/code]
一回CDIを呼び出しちゃえばその先はCDIワールドなので@Injectでインジェクションしまくっちゃって良い感じかと。上記のコードだと、myBean.doWork()の先からめくるめくCDIワールドです。CDIにはとりあえず@Dependentもしくはスコープのアノテーションを必ず付けましょう(CDI 1.1以降の約束)。
これは純粋にベース技術の更新であるHTTP/2にやっと追随しました、というものですね。他のプラットフォームは早々と対応していたので、「今頃!?」という感じでもあります。周回遅れ感が辛いところではありますが、もっと早く仕様が決まるような新体制になってくれればなぁと祈念致します。
[code lang=”java”]
@WebServlet(value = {"/http2"})
public class Http2Servlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
req.newPushBuilder()
.path("images/file.png")
.addHeader("content-type", "image/png")
.push();
try (PrintWriter respWriter = resp.getWriter()) {
respWriter.write("<html><img src=’images/file.png’></html>");
}
}
}
[/code]
これは最もデカい更新です。書くのが多すぎてどれから書くべきか悩むくらいありますが、順番に。
まず、Java EE 5時代の懐かしのJSF Managed Beanが遂にDeprecatedになりました。実にめでたい話です。今や何のメリットも無いので、それらはCDIに書き換えましょう。一対一で書き換えられるので、特に悩むこともないですし、一気にスクリプトで書き換えるのもありかも知れません。ただ、JSFのイベント内やFacesServletの前にFilterを置いて、仕様に無いようなハッキングに近い処理をやっていた場合は、その部分の全面書き直しになります。いずれにせよ、移行には充分なテストを行うようにしましょう。
次に、<f:event type=”postRenderView/> が追加され、遂に最後のイベントが拾えるようになりました。これは画面描画が終わった後のイベントなので、何か後処理が必要だったりする場合限定です。なくても困らないですが、ないより有る方が良いですね。
細かな改善系だと、セッション周りとの相性が最悪だったAjax関連機能の改善があります。壮絶に頭の悪い仕様だったラジオボタンもレイアウティングに対応し、やっと使えるようになってくれました。他にもInjectできる数が増えたという嬉しい話があります。特に使用頻度の高いと思われるExternalContext辺りがこんなコードで拾えるようになりました。遅いよ・・・
[code lang=”java”]
@Inject private ExternalContext context;
[/code]
Artefact | EL name | Qualifier | Type |
Application | #{application} | – | java.lang.Object (javax.servlet.ServletContext) |
ApplicationMap | #{applicationScope} | @ApplicationMap | java.util.Map<String, Object> |
CompositeComponent | #{cc} | (Not injectable) | javax.faces.component.UIComponent |
Component | #{component} | (Not injectable) | javax.faces.component.UIComponent |
RequestCookieMap | #{cookie} | @RequestCookieMap | java.util.Map<String, Object> |
FacesContext | #{facesContext} | – | javax.faces.context.FacesContext |
Flash | #{flash} | – | javax.faces.context.Flash |
FlowMap | #{flowScope} | @FlowMap | java.util.Map<Object, Object> |
HeaderMap | #{header} | @HeaderMap | java.util.Map<String, String> |
HeaderValuesMap | #{headerValues} | @HeaderValuesMap | java.util.Map<String, String[]> |
InitParameterMap | #{initParam} | @InitParameterMap | java.util.Map<String, String> |
RequestParameterMap | #{param} | @RequestParameterMap | java.util.Map<String, String> |
RequestParameterValuesMap | #{paramValues} | @RequestParameterValuesMap | java.util.Map<String, String[]> |
Request | #{request} | (Not injectable) | java.lang.Object (javax.servlet.http.HttpServletRequest) |
RequestMap | #{requestScope} | @RequestMap | java.util.Map<String, Object> |
ResourceHandler | #{“resource”} | – | javax.faces.application.ResourceHandler |
Session | #{session} | (Not injectable) | java.lang.Object (javax.servlet.http.HttpSession) |
SessionMap | #{sessionScope} | @SessionMap | java.util.Map<String, Object> |
View | #{view} | – | javax.faces.component.UIViewRoot |
ViewMap | #{viewScope} | @ViewMap | java.util.Map<String, Object> |
ExternalContext | #{externalContext} (new) | – | javax.faces.context.ExternalContext |
あと、新しい技術への対応としては、WebSocket対応 (<f:websocket>、PushContextあたり)もあります。
また、基礎技術面ではJava SE 8にもようやく対応しました。例えばNew date time APIに対応した、何故か対応していなかったExternalContext#getInitialParameterMapやらConverterやらValidatorやら。
そんなこんなで大量改善があったJSFで、これだけで1冊本が書けそうです。Web系は動きが速いので、この調子でガンガン更新していって欲しいものです。もっと激しくてもいいくらい。
さて、最後にJava Persistence API 2.2、つまりデータベースとのやりとりの場所です。ちょっとした改良に止まっています。
まず、Java SE 8対応、それに伴ってNew date time APIに対応しました。ので、やっとJDK 1.1~1.2頃に整備されたカビの生えたようなjava.sql.Dateやjava.util.Timestamp辺りともおさらばです。新たにLocalDate, LocalTime, LocalDateTime, OffsetTime, OffsetDateTime辺りが日付型カラムとの自動マッピング先として使えるようになりました。
また、Java SE 8関連として、Repeatable annotationに対応しています。これはひとつのメソッドに同じアノテーションを複数書けるようにしました、というちょっとした小改良に追随したものです。プチ改良。
あとはAttribute ConverterでCDIがインジェクト出来るようになったとか、ちょっとしたメソッドが追加されたとか、その程度です。
さて、ここまでざーっと見てきました。華々しいJSFの改良と比較して、それ以外は実質的に小改良に留まっています。要は今Java EE 7で開発を進めている方はそんなに心配せずとも、後でゆるりとEE 8対応、でもいいんじゃないかな、と思います。そもそもまだ商用アプリケーションサーバーがひとつもEE 8対応していません。代表的なJava EE対応IDEであるNetBeansも本稿記述時点で未対応です(Githubからの要自前clone & ビルド)。
元々、Java EEの最新版はリリース後1年くらい経過してから採用を、という流れですので、ここは慌てず、Glassfish 5やPayara 5 Beta辺りを使って、じっくりとバージョンアップのためのプロトタイピングを進めておくのが得策でしょう。来年のJavaOne 2018 (があれば) で商用サーバーがひととおり揃うのではないかと推測します。楽しみですね。
明日は@khasunumaさんの「これから Java EE を始める方へ」です。
長くなったので3分割した3つ目です。ビンテージPC系をまとめました。
去年後半は、それまで確保してきたPCをひたすら修理する事に明け暮れました。引っ越しを機に棚卸しができ、丁度壊れ始めた頃だったPCを修理しつつ、これまで持ってなかった機種にも幸運に巡り会えたため、それもまた修理するという地獄絵図でした(笑)。
そもそも1980年代のビンテージPCを遊ぼうとすると、その大半は壊れているのが普通であり、ごく希に修理済みのものが大変高値で取引されていたりします。ただ、趣味にはあまりお金を掛けない主義の私としては、自分で修理出来てこそ長く遊べるだろう、とう信念の下、ついでに自分で修理する技術を獲得していこう、と決め、実行してきました。
お陰様で失敗も多々ありましたが、年末に修理したPC-88VAをはじめ、多くの成功事例も重ねることが出来ました。TwitterのレトロPCクラスターの方々にも多く助言をいただき、修理スキルとしては格段にレベルアップできた一年でした。勿論、PCの動作原理も更に深く理解出来た気がします。1980年代の、という枕詞が付きますが(笑)。まあ、最新のPCとかIoTも根っこの部分は大して変わってないので、勉強と思えば安いものです。
まずドツボにはまったのは、間違いなくこの辺から・・・
遂に入手してしまったNEC PC-6001mkIIアイボリーホワイト。これでPC-6001用にバクテンさん @bakuten_do SD6031WIF のためのROM抜きができる。そこ、本末転倒とか突っ込まないで!ε-(´∀`; ) pic.twitter.com/84e8EaCpAT
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年3月6日
このボロボロのPC-6001mkIIを修理すべく奮闘するのですが、どうも動かない。まずはタンタルコンデンサーの総取っ替えから。
意地でタンタル引っこ抜いた。どうしても溶けてシュッポンで吸ってくれないから足をぶった切って表から半田ごて、裏からペンチ。溶かすのに30秒かかった。ここまで古いと辛いのー pic.twitter.com/IZaCR1HEdR
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年4月17日
が、動かず。RFユニットがダメ?
組み上げて電源入れてみたけど、やっぱり画面が出ない。かなランプが反応してリセット押したときにリレー音が鳴るから、動いてはいそう。RFユニットかな? pic.twitter.com/5UmwMoQjPM
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年4月17日
途中で海外出張等を経て、頭を冷やしてもう一度やり直し。
昨日のPC-6001mkII修理で音声合成が出なかった問題、回路図と比較して余計な電解コンデンサーをタンタルコンデンサー化してしまっていた&PSGラインのタンタルを付けるのを忘れてたという二重の間違いやってた。修正済み。 pic.twitter.com/iLzCsamvpd
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年7月4日
結局ビデオ出力で動きました。修理成功。うっかり間違いは良くないですね。
情報緩募: 直したP6mkIIのビデオ出力、P6と比較して何かジラジラするんですが、こんなもんでしょうか? pic.twitter.com/p5xTjXJtEH
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年7月4日
その直後西田ラジオさんからスプライト機能拡張付PC-6001mkII用VGAアダプターが届き、中間色を含めた16色表示環境が完全復活。
西田ラヂオさんのスプライト機能拡張付 PC-6001mkII 用 VGA アダプタ、ACアダプター買ってきて無事動きました!!文字がジラジラ表示されてたけど、DIP6:OFFで解消。ガキッと映る!ヽ(^o^)丿 pic.twitter.com/1NlmMNg9SQ
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年7月6日
その後ばくてんさんの所から戦士のカートリッジver.2.0が届き、いろいろ便利になりました。
帰国したらばくてんさん @bakuten_do のP6戦士のカートリッジver.2.0が届いてた。PLCCの4MBが付いてたからTSOP無くてもとりあえず遊べそう。とりあえず、手持ちのAX-1を吸ってぶち込んでみるか・・・ pic.twitter.com/My5HR6OYsc
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月24日
このP6版Ys-IIは実機動作させると衝撃度が凄いです。
初めて @tiny_yarou さんのP6 Ys-IIデモを@bakuten_do さんの戦士のカートリッジv2で動かしたけど、この衝撃は実機で動かさないと分からないので、とりあえずビデオ上げときます。(周回遅れ pic.twitter.com/wIgSFobcj7
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月24日
そしてベルーガの本物も。この突き抜けたクオリティが素晴らしい。それもこれもP6を修理出来た上にあるわけで、ここで味をしめていろいろ手を出す(=沼にはまる)のでした。
ベルーガ2面後半特攻シーン。このクオリティは異常。ゲームの面白さは解像度や色数やリアル度じゃないよね。 pic.twitter.com/UNPxnPyoCB
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月25日
平行で福岡FM爆音会で見たしらけんさんのPC-9821Ltがいいな、と思って数千円でこれを入手。これは乾電池漏れで中身が死んでいて、修理してるうちに液晶の同期が合わなくなり死んでしまいました。残念無念。
しらけんさんのPC-9821Ltがいい感じだったので、動作品と思しき/350Aをついうっかり2000円で。前愛機のPC-9801NS/Lに近い小ささで良いです。キーピッチが小ちゃすぎなので閲覧用かゲーム用かな。いまから開けて中を確認 pic.twitter.com/joLEJB69KM
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年3月25日
紹介しよう! ここで最終兵器「お酢」の登場である!ジュワジュワ音がする〜中和〜!! pic.twitter.com/cuHkiOjexd
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年4月1日
98 noteのdot by dot表示品質が凄すぎて鼻血モノ。ロストテクノロジー感満載で素晴らしい。みんな激安カラー98ノート買えば幸せになれると思うよ!(苦行コースへようこそ) pic.twitter.com/Up0oJjklrL
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年4月9日
ブランディッシュ2を始めてみたらまたもや水平同期がおかしく。ただ、異常時の発色とコントラストは明らかに改善されてる。残り4つのコンデンサー全とっかえしないと無理っぽい。苦行は続くよ!)^o^( pic.twitter.com/pIeOlHzGvv
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年4月10日
地震で困っててもしょうがないんで、PC-9821Ltの修理再開。前回の教訓により、最小のコンデンサーをカホパーツで選んできた。表面実装型は次回交換時にまた困るから普通のを使うのだ。 pic.twitter.com/MG0pT2BsD1
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年4月16日
やっとコンデンサー電解液漏れ発見。剥いでみないと分からないのが辛い。A3 54の左下。隣のスルーホールが塞がってしまってる pic.twitter.com/wQb7gAx5SE
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年4月16日
あまりにも奮闘が長すぎるので結論へ。動きませんでした。残念ー。修理してる最中に熊本の震災が起き、それどころじゃなくなりました、ということもあります。まあ、集積度の高い98ノート修理は鬼門ですね・・・
コンデンサー交換後起動してみたら電源はいらず。どうもヒューズが切れたぽい感じ。この辺が限界かな…98ノートはやっぱ茨の道だぜヒャッハーヾ(*`Д´*)ノ pic.twitter.com/ULWUp8Iy5E
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年4月16日
その後、懲りずに九州電遊博で大量にゲット。PC-8801mkIIMR、PC-9801UV21、PC-9821Ap2/M2の3台。これを修理しはじめる訳です。書いててうんざりします(笑)
カルチャーアーツ @fukuoka_game さんのところでジャンクのPC-9801UV21, PC-8801mkIIMR, PC-9821Ap2ゲットだぜ!\(^q^)/ #九州電遊博 pic.twitter.com/Y2B1Dpkjvy
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年7月31日
そしてその前に死蔵してた初代X68000を修理。
九州電遊博に持っていった初代X68000、もう6年くらい怖くて電源入れてないから、起動前に内部確認開始。筐体割らないように…(。-人-。) pic.twitter.com/kuKDZEtZwe
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年7月31日
これは成功。電池交換だけで済みました。初代は情報が少なく、特に電源周りではいろいろ手間取りましたが、何とかクリア。
初代X68の電池交換完了。10年後もう一回だな。 pic.twitter.com/aGMFzjefXO
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月3日
電源は綺麗で特に死んでませんでした。いろいろ聞くところによると、初代機は比較的丈夫だそうです。環境にも依るかな。下記Tweetで書いてる「電解液」は、単なるホットボンドの白でした。
初代X68の電源やっと開けた。4700uF 10vと2700uF 35vが盛大に白い何かをこぼしている。何このキモい電解液…? pic.twitter.com/CPvtot6CFp
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月4日
そしてゲームは動く。成功。
XRGB-3入れてX68000版ドラキュラ動いた。久々だなー pic.twitter.com/lkAFwnug6f
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月5日
これで勢いを増して修理開始。まずは簡単そうなPC-9801UV21より。FDD含め分解清掃したらあっさり動きました。
九州電遊博で確保したジャンク群に手をつける。まずはぱっと見で最も程度が良さそうなPC-9801UV21から。ドブに漬かった感じだったんで、中は腐ってる可能性あり。外装をガラスマイペット+キッチンペーパーで強引に清掃済み。 pic.twitter.com/ro1NWLFG0C
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月6日
開腹。定番のメルコの2MのEMSボードが入ってた。やっぱりドブ浸りしてた感じの左側が酷いけど意外に悪くない感じ。とりあえず全分解と清掃からかな。工場で使ってたのかな pic.twitter.com/trgRRutz2P
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月6日
ただし、ビデオ周りでエラー音が出て、縦線が出る状態。ROMの足の接触か、電解コンデンサーもしくはタンタルコンデンサー死亡でノイズが除去出来てない状況か、どちらかと考えられます。
修理中のPC-9801UV21の起動音が「ピーッ、ピッピッ」なんで、なんやねんと思ってたら、やっとマニュアル見つけて原因判明。VRAM(の回り)がやられてるぽい。道理でグラフィックパターンに縦線が出る訳だ。 pic.twitter.com/Y4mfuic04H
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年11月23日
どっちにしても面倒くさいので一旦放置で次。時間を作ってROM周りを綺麗にしてみます。それで治らなかったら、タンタル&アルミ電解コンデンサー全交換コース。実に面倒です。
我が心の最高傑作である大戦略II SPも内蔵FDDで動いたけど、なんかやっぱ縦線が入る。これはなんかどっかビデオ周りがおかしいのだろうか?
_(:3ゝ∠)_ pic.twitter.com/3rX6qJlwFI— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月6日
UV21のFDDは完全復活した感じですごく嬉しいけど、やっぱり縦線が治まらないのと、ブート失敗するディスクがある(ザナドゥとかイースとか)。こっから先はタンタル交換からのフルコースだな…_(:3ゝ∠)_ pic.twitter.com/hr7txKCRlL
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月8日
次、PC-9821Ap2/M2。非常に珍しい5.25インチドライブ版。表面実装電解コンデンサーの死亡率が極めて高い凶悪な機体として悪名をとどろかせています。
次はAp2を開けるところまでやって終わろう pic.twitter.com/9oZCowZH1A
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月6日
皆様にお伝えしたい事実としては、5.25インチドライブの中身はこんなに汚いという事実であります。開腹清掃してみた方がいいよ… pic.twitter.com/gZHXq6eLIh
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月7日
気を取り直してAp2側へ。電源開けてみたら猛烈な汚れ。長時間稼働してたんだろうなと。ただコンデンサー漏れは無いぽい。これは運がいい。 pic.twitter.com/xCHIcglRx1
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月7日
そしてメインボードへ易々と到達。大きく損傷はなさそうだけど、よーく見ると角型コンデンサーの足が緑色に腐食してる。死んでるかその直前だろう。いったい何個あるんだろうか…
(;´Д`) pic.twitter.com/sO5jUCO3Cx— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月7日
電解コンデンサーがかなり酷い状況、というか全滅状態なので全部交換することに。
PC-9821Ap2よ、覚悟するがいい!(そして返り討ちへ・・・ pic.twitter.com/6tvYU3ZkrJ
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月11日
ようやくAp2表面実装コンデンサー53個の交換完了。全部漏れてた。一カ所パターンが腐ってて剥げたのでジャンパー飛ばしで対象。難易度高いねー(>_<) pic.twitter.com/96Uuaj1KTF
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月11日
が、案の定動かず。原因として考えられるのは(1)電解コンデンサー漏れが激しい箇所で見えない所のパターンが朽ち果てている、(2)電源の5Vか12Vが不安定でシステムが起動しきれない、辺りかと。前者は特定がかなり難しいが、後者であれば(今であれば)電源修理でなんとかなる。
組み上げてみたけど画面出ず。スピーカーから相変わらずプチプチ音。もー疲れたヽ(`Д´)ノ pic.twitter.com/isD5DPXmAx
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月11日
無駄に半田作業のスキルがアップした気がする。がしかし結果が伴ってない。とりあえず分かったのは、起動音・画面すら出ないPC-9821の復活は容易ではなく、コンデンサー交換程度では太刀打ち不能ということか。将来別の手持ちがぶっ壊れた際に参考になるかも。
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月11日
ということで最後のPC-8801mkIIMRへ。
ジャンクPC-8801mkIIMRの確認開始。 pic.twitter.com/9vKn6ij2XF
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月12日
いきなり難所。背面ネジが錆びて朽ち果てている。開けられない。強引にネジザウルスで頭を破壊しながら回転。無事抜き取った。
一家に一本ネジザウルス。いきなりお世話になるとは・・・ pic.twitter.com/uMRLFnBeLP
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月12日
何とそのまま動いた。FDDがやばそうな感じ。
開けてちょっと拭いて、想像より状態良かったんで24khzに設定して電源入れてみたら動いた。となるとFDDが死んでて「ジャンク」扱いなのかな? pic.twitter.com/uHmV0g2XFD
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月12日
Twitterに書くのを忘れてたけど、ドライブ1側のノブシャフトが強い力で折れ曲がっていたので、力任せにまっすぐに伸ばし、芋ネジで位置を調整して分解清掃。これで治った。
TEAC FD-55GFV-40-U。ゴージャスな造りである。PC-8801mkIIMR内蔵のもの。清掃も簡単。 pic.twitter.com/6BEGvSWRyX
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月19日
結果修理大成功。我が家にSRに続き2台目のPC-88SR以降4Mhz機が。
PC-8801mkIIMRのジャンク、修理完了。FDDにもグリスアップして結構静かにカツンカツン動いてる。ザナドゥがFM音源含め完璧に動作してます
ヽ(*´∀`*)ノ pic.twitter.com/AuOhgTmtaF— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月19日
プロテクトのお陰で起動タイミングがシビアすぎるドラゴンスレイヤーも無事起動。完全復活の名に相応しい。
記念にMRでドラゴンスレイヤーLEVEL2.0撮ってみた。そういやWin版ドラスレクロニクル、このPSG歩行音がない点、指摘したのに結局スルーされてしまった。問い合わせて調べるって回答もらったけど… pic.twitter.com/FKuegCH4LH
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年8月19日
この後、FM爆音会に持っていって大活躍しました。持って行くに当たって、掃除機並みの爆音ファンを静音ファンに交換しました。風量はそこそこ確保出来ているため、問題無さそう。ただ、夏場や8Mhz機に究極静音型はちょっと考えた方がいいかもです。
PC-8801mkIIMRのファンが掃除機並みに爆音なので、交換用に究極静音ファンを買ってきた。これで明日の爆音会も安心。 pic.twitter.com/AmiAWjdEJQ
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年11月19日
FM音源も完璧。SSG音とのバランスもおかしくない。
PC-8801mkIIMR実機でロマンシアOPを爆音で聴きたければ、今日昼から北天神の福岡FM爆音会に来るのだ! pic.twitter.com/zWjEEAWxMp
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年11月20日
ということで大活躍でした。
爆音中! pic.twitter.com/6zBO7kkW9U
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年11月20日
今年はこれで終わりかな、と思ってたら最後に伏兵が。何と、ひょんなことからPC-88VA(初代)をゲット。だってお店にある、って言うもんだから・・・
カルチャーアーツ @fukuoka_game さんとこで初代PC-88VAゲット。ヤバい世界に足を踏み入れてしまった感 pic.twitter.com/PKIitHOYUm
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年12月7日
で、開腹したら壮絶なゴミの山。人生で一番汚いPCに出会った感じ。これは幾ら何でも生きてないだろうとこの時点で覚悟しました。
年末なのでカルチャーアーツさんとこから来たPC-88VAを開封清掃。汚ねーので全分解中・・・足がもげてたからゴム用強力両面テープで貼った pic.twitter.com/89FKaAIDLX
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年12月24日
気絶するレベルで汚い。幸いRAMボードは刺さってた。これ清掃すんのか・・・!? pic.twitter.com/qokYANUDeH
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年12月24日
この状態で電源ONすると短絡してICが焼けるから、古いPCを動かす前には必ず開けて清掃しましょう。いや、やりたくない_(:3ゝ∠)_ pic.twitter.com/bMp58WcUdS
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年12月24日
古い家電製品はこんな風にスイッチ部分でも湿った綿埃で短絡してるから、絶対清掃せずに電源繋いじゃダメ。火花吹いて最悪炎上するかもよ(´・ω・`) pic.twitter.com/2HRzMEZORq
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年12月24日
電源開けた。こりゃスイッチオンで燃えるわーw pic.twitter.com/bEood8SvvB
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年12月25日
ところが、何とこの機体、かなりレアなPC-88VA専用サウンドボードIIを内蔵していることが判明。ぶつくさ文句言いながら作業してたらUME-3に教えてもらいました(笑)
サウンドボード外せた。しかし、ここから裏パネルにラインを引いてるとか何つー酷い基板デザインだw pic.twitter.com/PeOtQYolkd
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年12月24日
で、綺麗にして周りを見廻すと、やっぱり電源のコンデンサーの防爆弁が膨らんでいるのが気になったので、人生初の電源修理に挑戦。もちろん、事前に数年間Webでかなりの事例を見て調べてます。元々X68000の電源を修理するつもりが何の因果か当時のライバル機側を修理する事になるとは。しかも両方初代機。
今日は非番なのPC-88VA電源修理。案の定、頭が膨らんだ16v 2200uFが液漏れ。基板が変色してた。まだ致命傷でない模様。 pic.twitter.com/yDYL3AkvpV
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年12月28日
いろいろな事例を見てると、一番でっかいコンデンサーを交換しない事例が多数見られたのですが、この電源の場合は例外なく全て交換しました。全て105℃品で統一しています。理想を言えば電源用の数個上のグレードが相応しいということを後で知ったのですが、まあそんなに88VAで長時間遊ぶことも無いと思うので一旦これで良いでしょう。そもそも対応ソフト少ないし。
ようやく全部の電解コンデンサー交換完了。組み上げテストは明日夜かなー pic.twitter.com/coafDCK2ku
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年12月28日
もちろん、電源修理は危険なので、特に半田付けを原因とする短絡事故には気をつけましょう。最悪、丸ごと燃えて火事になります。
PC-88VA電源修理終わったけど、破裂炎上が怖いから庭でスイッチオン。無事ファンが回ったから最低限のとこはOK。残りを組み上げてみる。 pic.twitter.com/jcJJqRkWpB
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年12月30日
無事だったので組み上げて、V2モードで動作成功。
有難うございます!!!!! 15khzに設定したら動きました!!!!! pic.twitter.com/wyHsM2Mvpz
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年12月30日
V3モードも成功。
キーボード接続。88VA用に隠しスイッチを上へ。この配置を考えた人、凄い。あとは組み上げてV3ソフトを動かしてみよう。このあと出勤なので出来るところまで。 pic.twitter.com/IYYkwJPfUp
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年12月30日
ということで、何というか奇蹟というか、年末に絶対死んでると確信していたPC-88VAが動いてしまいました。気をつけたのは、電池漏れで緑色や茶色に表面が錆びている箇所を無理にIPA等で拭かず、そのままにした、ということです。将来サビが進行して死ぬかも知れませんが、元凶を取り去っているため進行は遅く、仮にパターンが切れたときにはそのときに都度ジャンパーを飛ばして対処するのが正しそうです。
ということで3回に渡ってまとめた平成28年(2016)のまとめ、一旦これで終わりにします。他にもジャンクのPS2とか家庭用機を修理したりしてるんですが、まあネタ的に面白そうなのはこの辺かなと思うのでこの辺で。しかし、見事にNEC機ばかりですね。かなり普及してたという事もありますが、逆に壊れやすいということもあるかと思います(笑)。ひとこと言いたい点としては、内蔵電池と四級塩コンデンサーの二大元凶は想像以上に酷い、ということですね。
今年平成29年(2017)は、手持ちの稼働中機体(NEC以外を含む)のメンテを前半に完了させ、万全の状態で遊ぶ、です。なかなかまとまった時間が取れないので難しいですが・・・
おまけ。GeniusというAppleIIのゲームを海外から作者様に送ってもらいました。我が家のApple IIGSで音楽が聴きたいので、Mockingboard(の互換カード)の入手も今年の目標です。
Arrived "Genius into the toy warehouses" for #AppleII new game in 2016. Thanks! 2016年のApple II新作が届いた。サイン入れてもらった。US側のレトロ界隈の活動が凄すぎる(>_<) pic.twitter.com/YL8XSn5bCB
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年10月2日
明けまして御目出度うございます。今年も宜しくお願い致します。
去年を振り返ると、初の自分の書籍(というかインタビュー本)が出た目出度い年でしたが、丁度引っ越しが重なりドタバタしている間にあまり宣伝できず、という悲しい状況でした。このインタビューは2015年末に二子玉川にて行われたものですが、確か3時間近くかけていろいろな話をし、そのうちの大部分を掲載して頂きました。話題はJava EEの開発経験から勉強方法、エンジニアの教育、この先日本は働く場所としてどうなるのか、等々、多岐にわたるものになっています。推敲にだいぶ時間が掛かり大変でしたが、過去の自分の雑誌連載とは違う緊張感が大変印象に残っています。翔泳社の電子書籍シリーズとして出して頂きましたが、Amazonではプリントオンデマンド版(要は紙印刷版)も入手可能ですので、気になった方はそちらか、もしくはKobo・Kindleにてどうぞ。
編集部から連絡が。Koboでも発売されました! デベロッパーのキャリアと働き方を語ろう vol.1 [楽天] https://t.co/0e7K8KhsIn #rbooks pic.twitter.com/OBFWL3rU32
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年3月15日
丁度その頃引っ越しがあり、その直後熊本で震災発生。
国道3号線と菊池電車の交差する橋。おかしいくらいズレてる。上を車で通ってみたけどあり得ない段差。高速が死んでる現状、ここ切れたら南北の物流が途切れるから止められないのわかるけど、平常時なら通行止めレベル。次の大きな地震来たらアウトか pic.twitter.com/K260AkUbX6
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年4月24日
熊本市内にある実家と家族は無傷でしたが、食器棚がひっくり返り想い出の品が粉々に。まあその程度で済んで良かった話ではあります。
近所の松崎八幡宮はほぼ無傷。が、
鳥居が崩れそうだからつっかえ棒が入ってた。これは簡単に治せる。ここから南側断水状態とのこと。歩いて数分の実家は出るのだが… pic.twitter.com/sFAd4P8D7l— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年4月24日
本Blogの名称を頂いた熊本城と、その石垣である「武者返し」が崩れ、大変悲しい思いをしました。悲しいというか衝撃でした。人生の中でこんな事がまさかあるのか、と。「こういう事は絶対に起きない」という人の勝手な不文律を木っ端微塵に打ち砕く出来事でした。
テレビで見るのと実際見るのは衝撃度が違う。屋根がぼろぼろの熊本城と倒れた長塀。石垣が酷いことになってる。被害は京町方面続いてる。 pic.twitter.com/eEEiRBlR8N
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年4月24日
熊本の方が気になりつつ、その後初めてNew Yorkへ出張に行きました。敢えて地元民が使うような電車と地下鉄を乗り継ぎ、Times Squareへ。いわゆる世界の中心地がこれほど凄まじい物量の広告を一箇所に投入しているとは、これも衝撃でした。日本に戻り、渋谷や新宿のネオンを見て、何と寂しく時代遅れなのか、という感想を抱いてしまうくらい。日本が足踏みしてる間に、世界はどんどんMoving Forwardであります。
Finally now in NY. pic.twitter.com/TJmAS0xl6n
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年5月1日
そういえば、Java Day Tokyo 2016でも登壇しました。これは2015年のJavaOne 2015講演を日本語で再演したものでした。
昨日の #JavaDayTokyo 2016 #jdt2016_5A の資料を @SlideShare に上げました。実システムのためのJava EE 7/ Java EE 7 for Real Enterprise Systems https://t.co/uBhF37P83U
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年5月25日
海外と言えば、その後にJavaOne 2016にも参加しました。残念ながら今年は聴衆として。来年はスピーカーとして再チャレンジしたいと考えています。Java EE 8も出る予定ですしね。
The #JavaOne 2016 keynote will start. I was on this stage in 2015. pic.twitter.com/ea3U9UKgDO
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月18日
最後に、Rakuten Technology Conference 2016にも出ました。これは毎年出ているのですが、今年は丁度二子玉川ライズにてハロウィンパーティーでしたので、ちょっとだけ仮装しての登壇となりました。神道なのでハロウィンとは個人的に何の関係もありませんが(笑)。
2時から始まるよ!ライブビデオ中継あるよ!(但し英語) https://t.co/GvTyd9yPNQ pic.twitter.com/qnpRMpO8Wg
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年10月22日
と書いてきたら、全然収まらないくらいの長さになってきたので、3回に分けることにしました。2回目はアーケード基板関係をまとめます。
さて、Java EEの今年の動きは予想通りさほど大きくなく、どちらかと言うとJava EE 7が着実に企業システムに拡がっていったのかな? という感じの一年でした。それはそれで実業務を担うべく誕生したJava EEの、企業システムの基盤としては正しい状況だと思います。ただ、一方で日進月歩のダイナミズムという観点だと、何となく物足りない感じもします。みんな麻痺してる気もします。
余談ですが、実際の企業システムを開発・運用・管理している側からすると、ちょくちょく仕様が変更になるのは全く迷惑以外の何者でもありません。仕様追加ならば許容範囲内ですが、変わっちゃうと既存システムの互換性が問題になりますので。Java EE仕様の場合はよっぽど古いので無ければ切り捨てられる事も少ないですので、この点は良いですね。
話を元に戻しまして、ダイナミズムの観点では次期仕様であるJava EE 8について、数多くの動きが今年のJavaOne 2016でありました。
Beautiful San Francisco time ! #JavaOne pic.twitter.com/iVs4FH8RKK
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月19日
毎度ではありますが、国内報道はこの一部の側面しか流れませんので、参加されてない方は何が起きているのか理解不能なのではないかなとも感じます。参加しないと理解出来っこない、というのは仮に米国内に居たとしても同じ状況ではあると思いますので、永遠の課題ではあります。
日本の場合、参加費用がカンファレンス参加費約20万円に加え、渡航滞在費が4-50万円くらい余計にかかる、しかも参加出来たとしても、英語が聞けて話せないと参加費約20万円をドブに捨てる形になってしまいます。大変高いハードルです。
Good morning! pic.twitter.com/Hq0AdtGkye
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月18日
とはいえ、ここは仕様策定している有名人達と仲良くなるために頑張って英会話とライティングを習得し、あらゆる手段を使ってJavaOneに参加する、そして仕様策定に影響を及ぼす、というのがJava EE愛好家の鏡とも言える行動かと思います。ひとつ一念発起して頑張って世界に出て行く方々を応援したいと考えております。
ただ、今後頑張るとしても今年の状況は分からないと思いますので、私の見聞きした範囲を公開出来る範囲で記録として残しておきます。勿論大人の事情で全部書けるわけでは無いので、そこはまあ、そういう話としてご理解を賜りますようお願い申し上げます。
ここらへんの話は英語の一次情報を得ている人は気付いてる人は気付いてると思いますが、あまり掘り返してもいいことは無いので、目先を変えて今後どうなるのか、という話です。
"Java EE for the Cloud [BOF7984]", I believe this BOF is the super important for the #JavaEE specs. #JavaOne pic.twitter.com/7tzOSZsA6Y
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月20日
Java EEの仕様策定は相変わらずOracleによって先導されます。これ自体は、強力にホスティングしている会社が居ないとグチャグチャに空中分解することになるので、全く問題無いと思います。Oracleが好きかどうか、というのは全く別問題なのでそれは別の機会に。
そこへの意見としては、透明性を高めて欲しいという要望は当然ながら出ている訳でして、スペックリードへは諸々の要望が出ている状況です。が、それも正常なプロセスの一環であるため、特にこれと言って変わりはありません。Project JPE(はどうだったか正確には知らないですが)やJ2EEの昔からそういう意見が出て、諸々改善されてきました。改善されてないものもあります。普通です。
面白くない(?)結論ですが、まあ、そういう状況である事には変わりないでしょう。少なくとも、何かが大きく変わることは無さそうです。
次。問題はここです。オリジナルのJava EE 8仕様は元々もう少し早い時期に出る予定でしたが、ほぼ唐突に延期と仕様変更案がJavaOneで出てきました。
#JavaEE loadmap #JavaOne pic.twitter.com/yexw4iqFRs
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月18日
JCP周りのプロセスで問題があるとすれば、この辺りが閉鎖的に見えてしまう点となるでしょう。Java EEの仕様自体が複数の仕様で構成される巨大仕様であるが故に、個別の話は個別の仕様内に閉じてしまう事と、その悪影響か全体仕様を見ている人があまり多くない印象です。
ということで、あくまで案ではありますが、仕様変更案が出て、それに伴う投票が10月に締め切られました。私も投票するようTwitterで繰り返し呟きました。これに対する文句がある場合は、もう遅いという状況のため、投票しなかった方は「後出しジャンケン」(=後で文句ダラダラ)は無しにて呉々もお願い致します。
For Japanese engineers: 締め切りが10/21なので、それまで投票を。投票せずに後から文句言うのはルール違反。建設的に進めましょう。ここを履き違えると誰も幸せになれない。呉々もお願い致したく。 https://t.co/ka3GCzo73p
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月30日
と、公開しようと作業をしていたら、続報が。投票結果が出ていました。今回外された3つは見事に最下位から3つでした。まあ「結果は残酷」としか言いようが無いかなと。
Java EE 8 – Community Survey Results and Next Steps https://t.co/sB13j570LC #JavaEE #JSR366
— David Delabassée (@delabassee) 2016年12月21日
いずれにせよ、この改定仕様にてJava EE 8が策定されることがほぼ既定路線となり、既にjcp.org内にてこの結果を受けての作業が進行中ですので、今度はその中身を見ていくことにしましょう。
Java EE 8 (revised)というのが通称ですが、まあ日本人に分かりやすく以下「改訂版」としときます。改訂版ではCloud対応に焦点が当たりまして、その観点で見直しが入ったという形になります。「という建前になっている」、と補足をしたほうがいいかもしれませんが・・・。
いずれにせよ、Java EE規格策定が結構ノロノロであるため、その間に世の中の方がCloudバンザイの方向に行っちゃってしまいました、なので急ぎ対応させます、という感じで捉えると、然程間違いないかと思います。
"Java EE 8 Update [CON7976]" #JavaOne pic.twitter.com/8B8gbPZcWc
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月19日
オリジナルのJava EE 8仕様はこんなものを含んでました。
が、改訂版はこうなりました。
私自身としては、脱落した仕様はほとんど使ってなく、使う予定も無かったため、ほぼ影響無しで済みそうです。が、これらを当てにしていた方々からすると、やり場の無い怒りをどうしてくれよう、という感じかもしれません。そんなにJava EE方面に熱を上げてる方面はかなり限定されるとは思いますが・・・
まあ、そんな感情論はさておき、落ち着いて変更点をひとつずつ見ていきましょう。
これはJMSが廃止になるとかそういう話でも何でも無くて、Java EE 7のJMS仕様のまま、改定しない、という話になります。一部で廃止なのか!?と盛り上がりましたが、それは勘違いです。ただの延期。JMS 2.1はJava EE 9に恐らく載ることになります。今回は仕様バグの小修正のみが取り込まれる模様です(バージョン番号は不変)。
JMS 2.1での大きな追加要素は、非同期バッチ仕様が追加となり、アノテーション定義が拡張されて@JmsListernerが追加され、CDIでJMSが使えるようになる、等々というものでした。これによりEJB Message-Driven Beanが不要になる、という、CDI愛好家方面が狂喜しそうな内容が主だったところのため、微妙ちゃぁ微妙な更新でした。
延期の理由を関係者に直接聞きましたが、要は「作業する人が少ないので、人員を別の重要な更新に集中させるため」となります。個人的にもこれはあんまり重要で無い気がするので、延期で良いかと。なんてことを書くと他の関係者の恨みを買いそうですが(笑)。
これは悲劇ですかね。MVC 1.0というのは要はStrutsの後継というか、Strutsを今どき風に格好良くして標準化したようなものだった、とざっくり考えれば良いかと思います。
Java EE仕様のWeb標準フレームワークは、ページ駆動型のJSFです。これは紛れもない事実。要はASP.NETのASPXと同じようなものです。であるため、2000年代に流行したアクション駆動型のStrutsからの移行は「ほぼ作り直し」という非常に高いハードルを要求されます。これの救済策として急浮上したMVC仕様でした。主にStrutsを狙った多くのセキュリティーホールが出てきた頃に焦点が当たった経緯があるため、要はそういうトレンドに乗っかって出てきた感じではありました。
ところが急にスポットライトを浴びたものは飽きられるのも早い訳でして、今年のJavaOneではいきなり無かったことになってました。2014年・2015年のJavaOneでの狂騒は一体何だったのか。
延期の理由も関係者に聞いたところ「もはや重要ではないから」とバッサリ一刀両断でした。個人的にも、元々古くさいMVC仕様がこのタイミングで何故出てきたのかさっぱり理解出来なかったので、誤解を恐れずに言えば、EE 8仕様から落ちるのは大賛成です。
実はこの仕様を期待していた日本国内のベンダーやら顧客は多かった、と風の便りに聞くわけでして、さてどうなることやら。「既存のStrutsコードが大量だから移行なんて無理無理」とかゴネるのも、もう限界だと思います。もう諦めて、現代的なJSFで作り直す方がいいと思いますよ・・・
これはサーバー管理APIですね。JMXとかMBeanとか関連と思ってもらえれば。旧仕様が”J2EE Management 1.1″で2006年改訂ですから、もはやカビが生えた感が強いですが、これをRESTベースに書き換えましょうというのがオリジナルプランでした。
仕様から落ちるのは、「クラウド時代に注力するのはここじゃないよね」(意訳)というものなので、ある程度しょうがないかな。RESTベースに変更は既存のアプリケーションサーバーに膨大な仕様変更を強要する事になるので、そりゃぁ各方面が嫌がるでしょうね。これは次のJava EEに載るのかは不明です。更新されず将来廃止されるかもしれません。そっちが濃厚な気がします。
次は逆に追加されたものを見ていきましょう。二つです。
まずは監視。これは上記3-3のJava EE Management 2.0の代替としての位置づけ感が強いですね。強烈に違うポイントとしては、こちらはマイクロサービス(自走JARアプリケーション)を前提にした新APIである点です。マイクロサービス仕様はJava EE 9で登場する予定と聞いていますので、完全にそれを狙ってるのでしょう。
Serverless #JavaEE proposal. Big changing #JavaOne pic.twitter.com/Cs38jmxPyO
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月18日
いずれにせよ、これ以上細かい情報が出てない気がするので、これはちょっと判断待ち状態かと思います。どこかに出てるのかな。知ってる人居たら教えて下さい。
次に設定系の新APIです。これは完全にクラウド環境における可搬性を向上させる目的で、設定を読んだり更新したりできるものでしょう。
Java EEでは、初版であるJ2EE 1.2から設定は読み取り専用でXMLファイルで定義するものでした。いわゆるDeployment Descriptor。これがJSON等に対応し、動的に更新出来るようになるものなのか、それとも凶悪に旧式のPropertiesクラスを置換する目的になるのか、いまいちよく分かりませんが、いずれにせよこの辺りのものを置換するものと考えるのが良いでしょう。
ここら辺の周辺系改善は個人的に大賛成なので、どんどん新しいものを導入して現場の管理スタイルを洗練させて欲しい所であります。管理コストも下がるでしょうし、精神衛生上も良くなります。何より、不要なプロジェクト内共通ライブラリーを作らずに済みます。
最後にJavaOne 2016について纏めておきましょう。
2014年・2015年とスピーカーとして参加しましたが、今年は上記の混乱からか選考から外れてしまいました。私だけ?と思っていたら、あらあらあの人もあの人も・・・と。要はJava EE 8を狙ったセッションは悉く外されてしまった模様です。残念。去年のJavaOne 2015ではJava EEでのBatch設計・実装の話をしました。
Great talk by @aforarsh and @HirofumiIwasaki on Batch Processing #JavaOne2015 pic.twitter.com/y0hI9jHKVz
— Rodrigo Troy (@RodrigoTroy) 2015年10月28日
このため、JavaOne 2016のJava EEセッションの多くは、上記の改訂版Java EE 8の中身を説明するものに多くが費やされていた感触を得ました。まあ、それはそれで良いでしょうと、今年は久しぶりにリスナーとして参加することになりました。自分が話すための準備が無かったので、だいぶのんびりと参加させてもらいました。
With @reza_rahman and @yoshioterada on Moscone. Thanks for the great time! #JavaOne pic.twitter.com/yfRVThxUFR
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月19日
とはいえ、個別に多くの方と個別ミーティングを持たせてもらったことと、普通にフラフラ歩いてたら「あららこんにちは」系の脱線も多くあり、網羅的にセッションに参加出来た訳ではありません。勿論、そこから全然別の話に繋がったりと、むしろそこがJavaOne等海外カンファレンス参加の醍醐味なのでありまして、当然ながらそういう嬉しいハプニングを優先させています。
※なので、英語を聞けて喋れないとお金と時間をドブに捨てることになるのです。内容を見聞きするだけなら、YouTubeの中継を見とけばいいですしね。
現場で感じたこととしては、Java EE 8が延期されたのでイマイチ盛り上がりに欠ける状況ではあり、スペックリードが登壇するセッションも人が少な目、という微妙さ・余所余所しさが昨年以上あり。恐らくUS在住の方も日本以外在住の方も、今回はネタが少ないため参加を見送った方が多数あったのではないかと思います。
ただ、その分「一見さん」は減った感じがあり、何が何でも参加する方面の方々の毎年見る顔が揃いに揃った、という、Java EEマニアからするとレア度満点な感じも受けました。そこで会話される内容が久しぶりに濃く、私としては満足な参加となりました。
#JavaEE keynote sumamry #JavaOne pic.twitter.com/4mzIvcTY0A
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月18日
あまり難易度の高い話とメンバー固定化はオープン環境としてはイマイチかとは思いますが、そもそも取り扱っている題材が高難度のものであるが故、それに相応しい議論が行われるべきですし、ここはある程度許容範囲かと思います。そんなにマニアックなこと、誰でも込み入って会話出来る訳でも無いですしね。
ここは参加したセッションによって感触が左右されると思いますので、あくまで私個人が受けとった感触ということにて。来年のJavaOne 2017が待ち遠しいですね! 来年はこれら改訂版Java EE 8に則った、リファレンス実装であるGlassfish 5をダウンロード出来るようになっていることでしょう(勿論出ます)。
"James Gosling with the Newest, Latest, and Cutting-Edgiest Technologies with Free and Open Source Tools" #JavaOne pic.twitter.com/A98jRgXDvq
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年9月18日
明日の回は @gishi_yama さんとなります。
※2020-08-12追記
本稿のウルトラパワーアップ版として『メガCD(初代)修理マニュアル』をBOOTHでリリースしました。2種類のメイン基板、3種類のコネクト基板、CD-ROMドライブユニットのメンテナンスやアルミ電解コンデンサーの交換等まで網羅した徹底版になります。ご参考まで。
https://hirofumiiwasaki.booth.pm/items/2291597
メガCDがまたもや動かなくなり早数年。そろそろ修理しようと情報を集めると、最初に引っかかるのが2007年に自分で書いたBlog記事だったりする現状に衝撃を憶えたので、9年後のいま、続編なので日本語で続きを書くことにする。英語じゃなくてごめんね。
まず症状。我が家のメガCDは元々発売当時に買った超初期版と、ジャンクで買ったちょい新しめのものの2台ある状態。こいつらをどうにかしないと、メガCD版シルフィードが遊べないのだ。
■1台目(超初期版)の症状:
■2台目(ジャンク)の症状:
まず1台目から修理に取りかかる。メガCDの分解方法は至って簡単で、下記手順を守れば筐体を割ることは無いだろう。中もスカスカだし。
ドライブ修理の注意点としては、CD-ROMトレイを出した状態で分解を開始しないと、トレイを抜けない、ということ。メニューでイジェクトさせてから電源を切り、開始しましょう。
さてこのあと、銀のカバーをビス3本で外して、CD-ROMドライブを露出させる。ここで必要なのはまずCD-ROMトレイを横切っている上蓋押さえのビス2本を抜き、トレイの右上にある、爪で押さえてあるT字型のプラスチックを抜く。このT字型のプラスチックを抜かないと、トレイを全部引き抜くことができない。つまり引っかかりになっている(しかもイジェクト済みのセンサーに当たるようになっている)ので、抜かないといけない。爪で押さえて細いマイナスドライバーでちょいと上に持ち上げれば簡単に取れる。
で、そのあトレイをいっぱいいっぱいに引き出したあと、トレイを引っこ抜く。割れないように慎重に。そうすれば取り外したトレイの下にベルトが露出する。ローディングがダメな場合、だいたいこいつがユルユルでガビガビになってスリップしているから、必ず新品に交換する。薬剤でどうにかしようと思っても、一瞬動くかもだがすぐ駄目になるので、諦めて交換すべし。
代替品は「角ベルト 25mm x 1.6mm 径約39mm」。うちは近くのカホパーツセンターにて調達した。我が家のは案の定ユルユルになっていて、見るからにスリップしそうな感じになっていた。
張り替えたらこのくらい張りが出る。上の画像と比較しても一目瞭然である。これでトレイを戻して動かしてみたところ、一発でロードするようになった。ローディング部分はこれで修理完了。
さて、次に1号機の音が出ない点の修理。これもメガCDで頻発する四級塩コンデンサー問題なので、多分現在発症していない個体もいずれ発症する病気と考えたほうがいいだろう。
この問題点はまずメガCDが3つの基板から構成されていることを理解してから作業をするのが早い。まずCDドライブの正面から見て右横の最も大きな基板が「メインボード」(と書いてある)。ここにCPU・ROM・RAM等が積載されている。音が出ないけど動作はする、という場合、ここは無傷のことが大半。
が、このメインボードの表面実装コンデンサーが大量死して腐食が進んでいたので、辛うじて動いているものの全量交換することにした。16V 10μF x 12個、10V 100μF x1個の新品105℃の一般的なアルミ電解コンデンサーを調達し、表面実装型のランドに無理矢理はんだ付けしていく。非常に格好が悪いのだが、結局は同じだし、別に売り物にするわけでもないのでこれで良い。
注意点としては、作業しやすいように半田付けしていく順番を考えること、取り付けの際に穴に引っかからないように配置するためにコンデンサー側の足の切り方を工夫すること、くらいだろうか。また腐食が進んでいる場合一向にはんだが乗らない事が多いため、はんだごてで軽く基板側をグリグリしてやるとくっつく事も多い(がやり過ぎると焦げる)。まあとにかくくっつけるのだ。
なおこのメインボード基板は時期により数バージョンある。2号機の基板は完全にデザインが異なるもの。部品配置がそもそも違う(下の画像)。実はこれに加えて1号機と2号機の間のデザインのものが存在する(1号機の基板にEPROMではなくカスタムROMが載ってるタイプ)ことをtwitterでしらけんさんに教えてもらったため、少なくとも3バージョン以上は存在すると考えてよいだろう。
16V10μFをいっぱい買って来なきゃ… pic.twitter.com/jeobhkdimq
— しらけん/のっぷ@福岡 (@shiraken) 2016年7月19日
ふたつめの基板が、メインボードが刺さっている通称「コネクトボード」(と書いてある)。これも二バージョン確認済みで、1号機のメインボードにジャンパー線があり、表面実装型コンデンサーが2個あるものと、2号機の両者が無いもの。ジャンパー線の有無があるので互換性は無いと考えた方がいいだろう。
ここの表面実装コンデンサーも液漏れしていたため、通常の電解コンデンサーで張り替えた。16V 10μF x 1個、6.3V 47μF x 1個である。
三つ目の基板が、ACアダプタージャックや音声ジャックがくっついている、背面側にある細長い通称「サブボード」(と書いてある)。音声が出ない場合、十中八九こいつが元凶と考えて良いだろう。我が家の1号機の場合、9年前に交換した電解コンデンサーが確か5年くらい前に死んでいたのを確認して再度交換したものの、音が出ず一度断念している。この際に交換したものとは別のコンデンサーが死んでいる可能性大なので、こいつらを全交換である。
交換に際しては、16V 10μF x 10個、16V 100μF x 1個、6.3V 100μF x 2個の105℃品の新品を調達すべし。耐圧(V)はこれより上であればぶっちゃけ何でもOKだが、あんまり大きいと入りきれないので、そこそこ近いやつにしたほうがいい。福岡のカホパーツセンターでは16V 10μFが全くなかったので、50V 10μFで代替した。
メガCD修理開始。3回目くらいかな… pic.twitter.com/RP4gcoVtBM
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年7月18日
だが、結果は音声復活ならず。作業中、半田付けの際に腐臭が漂っていたため、明らかに小さな16V 10μFのコンデンサーが漏れており、漏洩後どこかが腐食していると考えられる。が、不明なので一旦保留。恐らく腐食でパターン断線、IC故障、辺りだろう。
なお2号機の電源が入らない問題も、ここサブボードの「16V 100μF x 1個、6.3V 100μF x 2個」のどれかが死んでる最も良くあるパターンではないかと考えられたため、交換したところ電源及び音声が復活した。
ここで1号機のメインボード+コネクトボード+2号機のサブボードで、一旦正常稼働状態のメガCDができあがった。
メガCD直った!! \(^O^)/オープニングはやっぱ初代がいい。結局1号機側のサブボードが死んでる模様。2号機側の漏れてるコンデンサーだけ取っ替えで行けた。サブボードだけジャンクで入手するか。 pic.twitter.com/yQWQEOuRYN
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年7月18日
音声が直った2号機側はCDトレイが熱変形でうまく閉まらない。しゃーないからサブボードを1号機へ。メガCD版シルフィード、音声も全てOK。このサブボードのコンデンサーも予備交換しとこう。 pic.twitter.com/44PeOa7qwz
— Hirofumi Iwasaki / 岩崎浩文 (@HirofumiIwasaki) 2016年7月18日
メガCDの故障は上記の他にCD-ROMトレイが経年劣化で歪んで正常にトレイが動作しない(引っかかる)というものがあり、我が家の2号機がその状態である。この場合、修理不能なので他のジャンクからパーツを拾ってくるしかない。
メガCDの良くある故障パターンは大凡上記のうちに該当する気がしている。今回は1号機メインボードの表面実装型コンデンサーが全量液漏れ死亡していたのが衝撃だった。2号機のものは漏れていなかったため経年の違いかもしれないが、初期型は恐らくどれも同じような四級塩を使ったものであろう、と考えると、単に時間の問題となることは明らかだろう。
ともあれ、私を含む実機維持派は簡単な電子工作技術が必須となる(か大量のお金が必須となる)時代に突入したと考えて良いだろう。慣れれば簡単なので、ダメ元で挑戦してみる方々が少しでも増え(て復活したメガCDが増加す)る事を願うばかりだ。
This is for the “Java EE Advent Calendar 2016” event material among Japan. Thanks for using auto translator for English.
Java EE アドベントカレンダー2015の12月23日分です。寺田さんの記事からの続きになります。
※注: 内容がエンタープライズ開発の中核方面に寄っているので難度高かなという気がします。
今年のJavaOne 2015ではキーノート発表に日本人として超久しぶりに登壇させてもらったり去年に引き続きセッションを一枠喋ったりとなかなかのプレッシャーでしたが、なんとか無事終わりほっと一息、なんて余裕が全くないのですが、そんなことより個人的にショックなことがあったのでそれを書きます。
こういう記事が雑誌(そもそも消えてしまった)や日本語商用技術サイトに載らなくなったってのが、多分日本全体の技術力の低下&乗り遅れの証なんだろうなと思いつつ、日本語で情報発信しなくなった私も元凶の一人かもしれないですね。が、個人的に日本語で発信する意味が全くない(私はSIerでもベンダーでもない)ので、逆に来年のAdvent Calendarは多分英語で書いてる気がしています。
ショックだったのがこれ。JCPに加入しているので仕様策定の状況を見てた訳ですが、IIOPが遂にJava EE 8からオプショナル扱いになるかもしれない、という話題が急遽入ってきた訳です。で、最近使ってないからいいんじゃねパーフェクト、みたいなノリでガンガン話が進んでいくわけです。
で、Java EEを丸17年間ほぼフルで使ってる私としては、おいおいちょっと待った、と。使ってない輩が勝手に仕様を削るなよと。使ってる側の話を聞いたのかよと。とまあそんな感じをまとめて私も投稿するわけですが焼け石に水。一人で世界は変えられないのでした。
で、多分IIOP (アイアイオーピー)って何よ?とほぼ10人に9人が謎に思うと思うので改めて。ざっくり言うとIIOPはCORBA仕様の通信部分のGIOPをTCP/IP互換にしたものなんですが、それはどうでも良くて、最も重要な部分はXAに対応してるJava EE内唯一の汎用通信プロトコルなわけです。RMIとの互換性を持たせてるのでRMI-IIOP (アールエムアイ・オーバー・アイアイオーピー)という仕様になってます。WebLogicではそれを更にラップしてT3 (ティースリー)という高機能プロトコルが提供されてます
で、次にXAって何よ?の回答なんですが、JDBCにXA対応、ってのがあるのでそれで気付く人が居たら嬉しいのですが、分散トランザクションの標準プロトコル、ってのがざっくり回答でしょうか。要は、複数のシステムに跨がってACIDトランザクションを制御できるってものです(ACIDはぐぐってね)。複数システムで処理する内容があったとして、どこかでエラーが起きたら複数台丸ごとロールバックできるという素敵仕様です。金融系処理には欠かせない処理、と言えばなんとなく想像付くでしょうか。お金情報が壊れたら嫌ですよね。ある日突然増えてたりとか減ってたりとか。
このXAはTuxedoや日立のOpenTP1などで1990年代後半に一世を風靡するのですが、まあそれをWebLogicがサポートして、J2EE 1.2の標準仕様に盛り込まれ、金融系システムに2000年代前半に広まっていくというサクセスストーリーな訳です。私もだいぶお手伝いさせて頂きました。
で、IIOPをオプショナルにするとなると、アプリケーションサーバーとしては標準としてサポートしなくても良くなるわけで、三大Java EE商用アプリケーションサーバーであるWebLogic, WebSphere, JBossのどれかが将来にサポートを外してくる恐れがあるわけですね。こいつぁ困った。ということでJavaOneで直談判に行ってきました。
でまあいろんな偉い人とディスカッションしていくわけですが(仔細は割愛。言えないこととかも沢山出てきた気がするので)、そこで追加で分かったのは、やっぱりEJBも将来無くなりそう、ということでした。あーやっぱり・・・時代はCDIなのです。
個人的にはEJBこそがJ2EE–>Java EEの華であり中核であり、WebLogic 3.0からEJBを使ってきた身からすると大変寂しい話ではあります。が、やはりEJBは機能がてんこもり過ぎて、必用な分だけ能動的に選択できるCDIは時代の要請でもあります。
で、Java EE 7のCDI仕様を見ると、EJBでサポートされてるけどCDIでサポートされてない機能がまあ沢山あります。どこからEJBでどこからCDIかさっぱり分からんというところもありますが、両方で使えるもの、という意味だとざっと考えて・・・
※Entity Beanは?とか聞かないで下さいね・・・もう無いです
と見ていくと、「まだサポートされてない」ものの中で落とされていくものがなんとなく色分けされていきます。どれが落とされるか分かりませんけど、少なくともIIOP+XAは当確な感じになって参りました。あーあ。
でまあ、そんなに後ろ向きだと生きるのが辛くなるし代替技術も無いので、しゃーないですなと気持ちを切り替え、XA使わないアーキテクチャーに変えていけばいいんじゃね?という方向にシフトしていく訳です。そもそもXAは完璧ではない(in-doubt windowとかあるし)ので、この方向もアリはアリです。
但し、現在動いているシステム群は一体どうするのよ?という疑問も当然あります。Webスタートアップ系の単一システムならまだしも、例えば金融系はアホみたいにシステムがある(数百から数千規模)のが普通なので、それをひとつにしていくというのも何となく無謀な感じもします。書いてると絶望感しか沸いてこない・・・で、唯一の方策というのは、製品利用企業が正しく声を上げてベンダーにIIOPをサポートさせ続けるということでしょう。プレッシャーかけていきましょう。
さて、悩み深いリアル金融系システムはさておき、大半の利用側はCDIバンザイな気がします。配備時に実装クラスを自動生成&コンパイルして動作するEJBに対して、単純に機能がインジェクトされて動作するCDIの方が、エラー発生時も分かりやすいですし、何せテストがやりやすい。
あとは現在EJBから移行されてない機能が恐らくJava EE 8〜9で追加されていくはずなので、それを待てばEJBがこの世から消える算段ができ、初学者はCDIだけ勉強すればあとはJSFもJPAもOKな幸せな世界になると思います。そう考えてCDIに仕様を移してきているので当然です。
CDIそのものの説明は既に大量にあるので省きますが、EJB特にSession BeanからCDIに移行するために何が必用か、というところだけ補足しておきます。
Session BeanからCDIへの移行はアノテーションの一括置換で概ね行けます。ざっくりとこんな感じと考えればいいでしょうか。
EJB Session Bean | CDI | |
---|---|---|
Class宣言箇所 | @Stateless | @Named @Dependent @Transactional |
EJB呼出し箇所 | @EJB | @Inject |
他を言い出すとあれやこれやありますし、EJB Remoteどうすんの(=移行先が無いので削ってアーキテクチャー変更)とか沢山有りますけど、こんな感じでの基本移行パターンを考えておく必要があるかと思います。
さてそろそろ長くなってきたので結論ですが、次の世代のEJB (特にSession Bean)は以下の書き方になっていくことでしょう。ただ、現在のJava EE 7だと機能が足りなさすぎる気もするので、ご自身のソフトウェア特性に応じて使いこなしましょう。ツールに踊らされるのは本末転倒です。
@Named @Dependent @Transactional @Path public class AnBusinessLogic { @Inject private NextBusinessLogic theLogic; @Inject private ThirdBusinessLogic thirdLogic; @POST @Consumes("application/json") @Produces("application/json") public AnReturnValue theMethod(AnParam param) throws BusinessException { // Check param values. AnReturnValue result = new AnReturnValue(); // Call other logics to operate. result.theResult = this.theLogic.businessMethod(param); result.thirdResult = this.thirdLogic.otherBusinessMethod(param); return result; } .... }
明日12/24の回はhondaYoshitakaさんの番です。Merry christmas and a happy new year!
New seats where added and tickets registration is available. Please, register as soon as possible before is too late.
ご盛況により当初想定よりお申し込みが多くなっていました。
新たに増席し、現在、申し込みが可能となっています。
ご興味がある方は、ぜひお早めにお申し込みください!
We are very proud to inform that this year Fukuoka Technology Conference has a lot of interesting presentations about the current trend on e-business from Rakuten Ichiba, Rakuten Travel and Rakuten Card in Fukuoka.
If you want to hear how our business are implementing the current technology, come to see our conference. We will be very happy in explain our services.
Also, come to talk with our employees in our Happy Hour. This is a place that you can enjoy food & drinks and talk with us. Please, feel free to have a nice conversation with us.
今年も福岡でやります!! 楽天テクノロジーカンファレンス2015です。
今年は、楽天市場、楽天トラベル、楽天カードなど、実際にドライブ中の最新トレンドについて、(東京からのサテライト込み込みですが) 福岡からも発信します! Web技術を中心として、主にJava EEやエンタープライズ系開発について、結構ディープにやっちゃいます。
また軽食・お飲物提供タイムも用意しました。現場で開発している社員も参加します。色々聞いてみて下さい。お気軽にご参加下さいませ。
Nov. 21st, 2015, Start 10:00
2015年11月21日(土)10:00〜:受付開始
Fukuoka Center Building 12F,
2-2-1 Hakataekimae, Hakata-ku, Fukuoka City,
Fukuoka, Japan
福岡県福岡市博多区博多駅前2丁目2番1号
福岡センタービル12F
http://tech.rakuten.co.jp/access.html#access-fukuoka
https://www.eventbrite.com/e/rakuten-technology-conference-2015-tickets-18950765249
1. Push “REGISTER” button. / みどり色の「REGISTER」ボタンを押して・・・
2. Apply from “(Satellites) Fukuoka”. /「(Satellites) Fukuoka 福岡サテライト」からどうぞ!
Time | Location A (Conference) |
Location B (Cafeteria) |
11:00 | Java EE Applications for Transaction Services by Kota Fujita | [Track A] Talk by Yutaka Matsuo by Yutaka Matsuo |
12:00 | [Track A] Fun Research in Computer Vision : from robots, sports, face to medicine by Takeo Kanade |
Lunch |
13:00 | [Track A] Keynote by CEO by Hiroshi Mikitani |
[Track A] Keynote by CEO by Hiroshi Mikitani |
14:00 | Better working framework for smart device service by Shimizu Yosuke | [Track B] Rakuten Ichiba by Yoshihisa Onoue |
15:00 | About JavaEE and DevOPS by Nakada Hiroaki | [Track E] Rakuten Travel by Kazuhisa Naoi and Shinoda Takeshi |
16:00 | [Track B] Rakuten Card by Hirofumi Iwasaki and Ameen Arshal |
[Track B] Rakuten Card by Hirofumi Iwasaki and Ameen Arshal |
17:00 | – | Closing |
17:30 | – | Lightning Talk & Happy Hour |
Java EE Applications for Transaction Services by Kota Fujita.
11:00〜 at Location A (Conference) in Fukuoka
Today’s e-businesses are changing very fast introducing new standards and new technologies every year. This session will explain why we selected Java EE as our platform and How we are implementing it to allow agile and safe transaction system.
14:00〜 at Location A (Conference) in Fukuoka
We believe that promoting excellent synergy between business, development and operation; creating a working environment that support each area demands; and building multinational team; It is possible to have rapid and reliable development contributing for better user satisfaction and more revenue. Some of key concepts is to have 100% in house development on both the Client and Server side and to have high qualified engineers capable to do planning, development and operation. As a result, we could optimize our working framework providing better products with high quality and very good customer satisfaction.
15:00〜 at Location A (Conference) in Fukuoka
Our system is continuing to grow and introducing new technologies is becoming our normal operation flow. This session will explain over view of our development and operation.
お申込みは、こちらから!
https://www.eventbrite.com/e/rakuten-technology-conference-2015-tickets-18950765249
Thanks for joining our session with @aforarshal in great 20th anniversary of Java on JavaOne 2015. Fortunately we had many attendees in big hall in Parc55, with many feedbacks and Q&A times there. Also the session room had TV streaming and recoding system, now we can see whole session scene on YouTube as above.
The session slides are also available from SlideShare here.
I was very pleased to see the strong passions of every engineer for Java EE technologies same level as the beginning of the J2EE 16 years ago there. Each technology details were already changed but the core policies were not changed from the beginning. I want to say it’s a great forecast in late 1999, and still moving forward to our future.
The session is going to replay in next Rakuten Tech Conference 2015 in Tokyo, Japan on Nov 21, 2015, more deeply.