銀杏の木

Oracle JDK が ２０１８年 リリースされた Java11 から有償サポート化し、 Java8 のサポート期限が２０１９年１月で終了した。また、エンドユーザーが .jar を実行するなどするためのエンドユーザー向けに配布されていたJRE も配布されなくなった。

有償サポートは Oracle Java SE Desktop Subscription の場合、１年間１ライセンスで US$30.00 。これを支払い続けるのであれば引き続き Oracle Java （Java SE 11.0.2(LTS)）を使用できる。

ただし、この費用を支払い続けるのでなければ他の無償版 JDK に移行することが必要になったということだ。そこで調べてみたのだが、いろいろ不明な点があり正直エンドユーザにとってはどうすればいいか分からないのが現状だと思う。

不明点１：無償版 JDK はどれを使ったらいいの？

OpenJDK, AdoptOpenJDK があるが、どちらがいいのか分からない。参考記事によると、 AdoptOpenJDK は「 OpenJDK のビルドを提供するプロジェクト」とされているが、別に AdoptOpenJDK からダウンロードしなくても、 OpenJDK のサイト自体で JDK をダウンロード出来るので、敢えて AdoptOpenJDK を選ぶ理由が分からない。

不明点２：AdoptOpenJDK は JVM に HotSpot と OpenJ9 を選択することになる。どっちがいいの？

先に説明だが、 JVM とは Java Virtual Machine の略と思われる。要は java のコードを実行する仮想マシンエンジンのことだろう。複数のエンジンから一つを選ばせる形になっているわけだ。

ダウンロードページのヘルプを見ると、

HotSpot is the VM from the OpenJDK community. It is the most widely used VM today and is used in Oracle’s JDK. It is suitable for all workloads.

For more details see OpenJDK HotSpot.

OpenJ9 is the VM from the Eclipse community. It is an enterprise-grade VM designed for low memory usage and fast start-up and is used in IBM’s JDK. It is also suitable for running all workloads.

For more details see Eclipse OpenJ9.

と書かれている。 HotSpot は OpenJDK で開発されていて Oracle JDK でも使われており、 OpenJ9 は Eclipse で開発されていて IBM JDK で使われている、という違いがあるようだ。

・・・だから何？

それを聞いて、どっちを使ったらいいか即決できる人なんて、エンドユーザの中のごくごくわずかじゃないの？ Oracle JRE がなくなったからやむを得ず移行しようとする一般ユーザにとって、普通はそんなこと聞かされてもさっぱり違いが分からないし、どっちを選んだらいいか判断なんてできないと思う。 Oracle JRE にあった機能のうち、どんな機能が削除されているので、こちらは使わない方がいい、とか、もっと判断材料になることを書いてもらわないと、何の助けにもならない。

不明点３：ダウンロードしても .jar ファイルを起動できるようにならない

これはまったく致命的だ。上記の JDK にはインストーラが付属していない。ダウンロードしたら、自分で .jar との関連付けを行う必要があるのだ。だが今回の件で無償版 JDK への移行方法を紹介しているサイトで、ダウンロード方法に併せて .jar の関連付けによりダブルクリック起動できるようにする方法が紹介されているサイトは実は皆無だった。エンドユーザにとって、この部分が一番出来なくて困る点なので紹介しておく。

.jar ファイルをダブルクリックしたときに、特定の java 環境で起動させるための関連付けは、以下の様な形で実装されている。

（A） assoc コマンドによる .jar ファイルに対するファイルタイプの定義

Oracle JRE の場合、

と定義されている。（ assoc （改行）で確認できる。）

（B） ftype コマンドによるファイルタイプに対するアプリケーション起動コマンドの定義

Oracle JRE の場合、

と定義されている。（ ftype （改行）で確認できる。 ）

このように２段階に定義づけされており、これを修正して、新しくダウンロードしてきた JDK の中にあるアプリケーションを起動するように変更する必要があるのだ。

具体的な手順の例としては、例えば、

（１）コントロールパネルのプログラムと機能から、 Oracle Java 関連をアンインストールする。

（２） AdoptOpenJDK から x64 の HotSpot JVM 版の JDK をダウンロードする。

（３） C:\Program Files\ にファイルを展開する。C:\Program Files\ の直下に jdk-11.0.2+9 というフォルダが作成される。

（４）コマンドプロンプトを管理者として実行する。

（５）以下のコマンドを実行する（ AdoptOpenJarfile という名前は他のものに変えても良い）。

assoc .jar=AdoptOpenJarfile
ftype AdoptOpenJarfile="C:\Program Files\jdk-11.0.2+9\bin\javaw.exe" -jar "%1" %*

正しく実行できていれば、この時点で .far ファイルのアイコンが Oracle JRE の javaw.exe のものから、 AdoptOpenJDK の javaw.exe のものに変わる。後は、起動したい .jar ファイルをダブルクリックすれば起動できるはずだ。今後は、 JDK の新しいバージョンをダウンロードするたびに、フォルダ名（上の例で jdk-11.0.2+9 の部分）を変更しない場合を除いて、この関連付け作業が必要になる。

吉里吉里Zのソースから必要なものをビルドして吉里吉里２用に作られたプロジェクトが動作できるようにするまでの手順が網羅されているサイトが見当たらなかったので、ここに紹介しておく。吉里吉里Zのビルドには、今最新の版である visual studio community 2017 を用いることにする。

実はこれが結構長い手順で作業は大変だが、吉里吉里２プロジェクトが動作するまで最後まで書いておく。

ステップ１ 吉里吉里Z本体をビルドする

visual studio community 2017 をインストールしておく。こちらのページの中にある「コミュニティ 無償ダウンロード」をクリックする。

cmake をインストールしておく。（例） x64 の場合、現在の最新版3.13.4はここからダウンロードできる。

nasm のサイトから、 nasm をインストールしておく。 krkrz の HowToBuild.txt には「nasm 2.10.09 (最新版は未チェック)」と書かれているが、最新版で構わない。現在は 2.14.02 。x64 の場合は nasm-2.14.02-win64.zip をダウンロードする。

github からソース環境を clone する。（例） git clone –b master https://github.com/krkrz/krkrz

「コントロールパネル」の「システム」から「システムのプロパティ」を開き、「環境変数」から、システム環境変数（またはユーザー環境変数）の Path に、 nasm.exe をインストールしたディレクトリのパスを設定する。

コマンドプロンプト(cmd.exe)を開き、ローカルに clone した先の krkrz/krkrz/external/zlib/ に cd で移動する。（（例） cd c:/users/*/source/repos/krkrz/krkrz/external/zlib ）

移動した場所で、 cmake . を実行する。これによって、 プロジェクト zlib に欠けていた zconf.h が出来るのでビルドが通るようになる。

ローカルに clone した先の krkrz/krkrz/vcproj/ にある tvpwin32.sln を開く。

option_desc_ja.json を開き、 901 行目の

sound プロジェクトの WaveFormatConverter_SSE.cpp を開き、冒頭の #include 部分に '#include <intrin.h>' を追加する。そうしないと、34, 35 行目で _mm_cvtepi16_epi32 の undefined identifier のエラーが出る。

ソリューションエクスプローラーで turbojpeg-static の中の x32 をクリックし、 j*.asm という名前の NASM 形式のアセンブリのファイルの一覧を表示させる。複数選択で全て選択して右ボタンクリックし「プロパティ」を開き、「構成プロパティ」の「カスタムビルドツール」の「全般」を選択すると、「コマンドライン」に、

setlocal
nasm -fwin32 -DWIN32 -I../win/ -I../simd/ ../simd/%(Filename).asm -o./$(Platform)/$(Configuration)/%(Filename).obj
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd

ソリューションエクスプローラーで tvpwin32 をクリックして選択し、メニューバーの下のアイコンから、 Debug Win32 を選択し、 evpwin32 を右クリックし、「リビルド」を選択し全体をビルドする。

ローカルに clone した先の krkrz/ に tvpwin32_d.exe が出来ているので、吉里吉里２用に作成したプロジェクトのルートディレクトリに tvpwin32_d.exe をコピーする。

ステップ２ 吉里吉里Zの動作に必要な DLL をビルドする

github からソース環境を clone する。（例） git clone –b master https://github.com/krkrz/krkrz_dev

ローカルに clone した先の krkrz/krkrz_dev/src/plugins/win32/menu/vc2012/ にある menu.sln を開く。

ソリューションエクスプローラーで menu をクリックして選択し、メニューバーの下のアイコンから、 Debug Win32 を選択し、 menu を右クリックし、「リビルド」を選択し全体をビルドする。

ローカルに clone した先の krkrz/krkrz_dev/src/plugins/win32/menu/vc2012/ にある menu.sln を開く。

ソリューションエクスプローラーで menuをクリックして選択し、メニューバーの下のアイコンから、 Debug Win32 を選択し、 menuを右クリックし、「リビルド」を選択し全体をビルドする。

ローカルに clone した先の krkrz/krkrz_dev/bin/win32/plugin/ に menu.dll が出来るので、吉里吉里２用に作成したプロジェクトのルートディレクトリの下の plugin ディレクトリに menu.dll をコピーする。

ローカルに clone した先の krkrz/krkrz_dev/src/plugins/win32/KAGParser/vcproj/ にある KAGParser.sln を開く。

ソリューションエクスプローラーで KAGParser をクリックして選択し、メニューバーの下のアイコンから、 Debug Win32 を選択し、 KAGParser を右クリックし、「リビルド」を選択し全体をビルドする。

ローカルに clone した先の krkrz/krkrz_dev/bin/win32/plugin/ に KAGParser.dll が出来るので、吉里吉里２用に作成したプロジェクトのルートディレクトリの下の plugin ディレクトリに KAGParser.dll をコピーする。

github からソース環境を clone する。（例） git clone –b last_hedgepodge_repository https://github.com/krkrz/krkrz

ローカルに clone した先の krkrz/last_hodgepodge_repository/src/plugins/win32/win32dialog/vc9/ にある win32dialog.sln を開く。

ncbind.hpp の 532～536 行目を以下の様にコメントアウトする。コメントアウトしないと、「error C2668:  : オーバーロード関数の呼び出しを解決することができません。」エラーが出る。

// for reference
//        template <typename SRC>
//        inline void operator ()(VarT &dst, SRC &src, ncbTypedefs::Tag<SRC&> const &tag) const {
//            operator()<SRC&> (dst, src, tag);
//        }

ソリューションエクスプローラーで win32dialog をクリックして選択し、メニューバーの下のアイコンから、 Debug Win32 を選択し、 win32dialog を右クリックし、「リビルド」を選択し全体をビルドする。

ローカルに clone した先の krkrz/last_hodgepodge_repository/bin/win32/plugin/ に win32dialog .dll が出来るので、吉里吉里２用に作成したプロジェクトのルートディレクトリの下の plugin ディレクトリに win32dialog .dll をコピーする。

ステップ３ 吉里吉里２プロジェクトを修正する

ローカルに clone した先の krkrz/krkrz_dev/script/KAG3/data にある system ディレクトリの中にあるファイルを全て、動作させたい吉里吉里2プロジェクトの system ディレクトリにコピーする。

動作させたい吉里吉里2プロジェクトの scenario ディレクトリにある .ks ファイルの文字コードを shift-jis から utf8 に変更する。（エディタで開いて文字コードを変えるか、参考サイトの「２．文字コードを変更する」のように nkf で一括変換すると便利。）

動作させたい吉里吉里2プロジェクトのルートディレクトリの下の system ディレクトリにある config.tjs を開き、右ボタンクリック時の動作などを吉里吉里Zが用意したものを用いる場合は、以下の useHamExtention  を true にする。逆に、私のように、自分の吉里吉里2環境で自前で右クリック時の動作などを記述しているので余計なことをしないで欲しい場合は false にする。

// ◆ Ham拡張の使用
// Ham Extention for KAG3を使用しない場合はfalseにしてください。
;global.useHamExtention = false;

動作させたい吉里吉里2プロジェクトのルートディレクトリにある startup.tjs をエディタで開き、冒頭部分に、以下のような if ブロックを追加する。

@if (kirikiriz)
property _dummyProp { getter {} setter (v) {} }
with(Window) {
     &.innerSunken    = &_dummyProp;
     &.showScrollBars = &_dummyProp;
}
Plugins.link("plugin/menu.dll");
Plugins.link("plugin/KAGParser.dll");
Plugins.link("plugin/win32dialog.dll");
@endif

ローカルに clone した先の krkrz/krkrz_dev/script/Krkr2Cpmpat/data/ の中にある k2compat ディレクトリとその中身を全て、動作させたい吉里吉里2プロジェクトのルートディレクトリにコピーする。

ステップ４ 吉里吉里２プロジェクトを修正する（吉里吉里Zが吉里吉里２非互換の部分について、 互換性を出来るだけ確保したい場合の追加作業）

動作させたい吉里吉里2プロジェクトのルートディレクトリにある startup.tjs をエディタで開き、冒頭部分の if ブロックに、 var base = “k2compat/”; からの３行を追加する。（ ３つの Plugins.link については、この作業をした場合なくてもよくなるはずだが、あってもエラーにはならない。）

@if (kirikiriz)
property _dummyProp { getter {} setter (v) {} }
with(Window) {
     &.innerSunken
    = &_dummyProp;
     &.showScrollBars = &_dummyProp;
}
Plugins.link("plugin/menu.dll");
Plugins.link("plugin/KAGParser.dll");
Plugins.link("plugin/win32dialog.dll");
var base = "k2compat/";
Scripts.execStorage(base+"k2compat.tjs");
Krkr2CompatUtils.scriptBase = base;
@endif

これで、吉里吉里２プロジェクトが動作するようになる。ただし、プロジェクトによっては、各部で吉里吉里２と吉里吉里Zの非互換部分でエラーが出る場合があるので、その都度修正が必要になる。

吉里吉里２は、展開するだけでそのまま開発を始められるアーカイブファイルが用意され、分かりやすいチュートリアルやリファレンスマニュアルが用意されていたから、多くの初心者が吉里吉里を使うことができたのだと思う。

吉里吉里Zにも公式サイトにリファレンス等があるので参照するとよいと思う。ただし、配布アーカイブは、本体と KAG (ノベルソフトを書くのに役立つスクリプトツール）が別々になっており、 KAG も機能別に「鱧入り KAG3 for 吉里吉里Z」と「 KAG3 for 吉里吉里Z」（ github リポジトリは「鱧入り KAG3 for 吉里吉里Z」と「 KAG3 for 吉里吉里Z」）に分かれて配布されているので注意して欲しい。

この記事が少しでも新規に吉里吉里Zを用いてモノづくりをしたいと思う人と、吉里吉里２から吉里吉里Zに移行して吉里吉里を使い続けようと思う人の役に立てば幸いに思う。

昨年から PHP７で動作するよう rNote を修正して使用していたが、PHPマニュアルサイトの flock() の説明によると、 PHP 5.3.2 以降は、 flock($fp, LOCK_EX); などでロックしたファイルは、 fclose($fp); の直前で明示的に flock($fp, LOCK_UN); を呼んでアンロックしてやらないといけないことに気づいたので grep で検索してみたら、結構あちこちでアンロックを明示的に呼んでいなかった。

そこで、 flock($fp, LOCK_UN); を明示的に呼びだすように修正した。（修正しなくても特に問題なく動作していたが、 PHP の仕様上正しくロックしなくなっていたはず。）

特に気を付けたいのが rnote.php で下のように定義されている _fopen_wb() 。

function _fopen_wb($fname){
    $fp = @fopen($fname, "wb");
    if(! $fp) error("$fname : File write error");
    set_file_buffer($fp, 0);
    flock($fp, LOCK_EX);
    rewind($fp);
    return $fp;
}

この関数の中では $fp = fopen() が呼ばれ、開かれたファイルをロックしているのだが、アンロックしないまま fclose($fp); も呼ばず、そのまま $fp を返り値として返しているので、_fopen_wb() を呼び出した側で、受け取った $fp を使用した後に fclose($fp) する直前で明示的に flock($fp, LOCK_UN); を呼ばなければいけない。コードとしてはかなり見通しが悪くなり汚いコードになるが仕方がないのでそのように修正した。

timidity のプロジェクトの一つ、 osdn にある timidity++ 41版 というプロジェクトをローカルでビルドしようといろいろ試していて、やり方が分かった。

プロジェクトのルートフォルダごとに CMakeList.txt というファイルがあるので検索して見つけた CMake というツールを使うことで一発でビルド出来た。

最初 CMakeList.txt の中身を覗いてみたときに思ったのは、冬星の知っている Makefile の記述とはかけ離れてるなあ、ということだった。どちらかと言うと何かのスクリプト言語みたいな感じがした。

ビルドの仕方も、冬星の知っている make とは全然違っていた。 make の場合は、 make –f Makefile などとして Makefile を読み込ませればそのまま gcc なりのコンパイラが呼ばれビルドが始まったが、 CMake の場合はそうではなく、プロジェクトのルートフォルダに CMakeLise.txt があっても、そのフォルダで CMake CMakeList.txt などとしても何も起こらなかったが、「CMakeの使い方（その１）」を見て手順が分かった。

CMake でのビルドは：

1. プロジェクトのルートフォルダ（プロジェクト用の CMakeList.txt が用意されている）で mkdir build などとして、ビルド用のフォルダを作る。
2. 作ったフォルダに移動する。
3. そのフォルダから cmake .. とする。

という不思議な手順で行う。こうすることでビルドが行われるかというと、実はそうではなくビルドは始まらない。 timdiity41 の場合、 Visual C++ 用のソリューションとプロジェクトが自動生成された。

そこで、 Visual C++ 用のソリューションをダブルクリックして Visual Studio を起動しソリューションを開いてやることで、ようやくビルドを開始することが出来た。

ここまで書いてから書くのもなんだが、つまり CMake は Visual Studio に対応しているということだ。（でなければこんなことができるはずがない。）また、 gcc にも対応しているらしい。 gcc の場合、上の手順の３まで行ったら make 用の Makefile が自動生成されるようだ。一言で言うと、 CMake は make の一種「ではなく」 Makefile などを自動生成するためのツール、ということだ。

rNote のオリジナルコードでは、単一記事モードで記事を閲覧したとき、

の中で、有効なリファラか判定するために、

となっている。 ’//’ のあとに、任意の６文字以上があれば有効と見做している。

しかし、「ドメイン名の文字数と使える文字の制限」に書いたように、 http://a.cn/ など、１文字ドメインからのアクセスを考えると、これではまずい。

その部分を、

と変更する。

これで、少なくとも第２レベルドメインまで存在し、

などの形式の場合に有効なリファラと判断するようになる。

数値参照でエンコードされてきた場合などを考えて、ラベルには「%&#;\」などを追加してあるが、必要ないかもしれない。