FreeBSD で OpenJDK の日本語を設定2013年11月19日 15時39分50秒

FreeBSD の Java は openjdk になっていた。現在のシステムは、8.4-RELEASE。インストールしたそのままでは日本語が使えない。いわゆる豆腐になる。

まずは、FreeBSD 上の Java で日本語が文字化けで行った fallback を試してみた。しかし、□のまま。そこで、fontconfig を用いた設定を試みる。以前の手順の fontconfig を試したが、相変わらずうまくいかない。もう少し調べると、どうもファイル名が違うのと、フォントのパスが違うのが原因のようだ。

まずは、fontconfig.properties には、アーキテクチャの名前が入るみたいだ。FreeBSD では openjdk6 が /usr/local に入る。その中の jre/lib 内で fontconfig.FreeBSD.properties を設定する。


$ cp /usr/local/openjdk6/jre/lib/fontconfig.properties.src /usr/local/openjdk6/jre/lib/fontconfig.FreeBSD.properties
$ diff -u fontconfig.properties.src fontconfig.FreeBSD.properties
--- fontconfig.properties.src   2013-11-16 23:19:06.000000000 -0500
+++ fontconfig.FreeBSD.properties       2013-11-19 01:34:04.000000000 -0500
@@ -180,8 +180,8 @@
 filename.DejaVu_Serif_Oblique=/usr/local/lib/X11/fonts/dejavu/DejaVuSerif-Oblique.ttf
 filename.DejaVu_Serif_Bold_Oblique=/usr/local/lib/X11/fonts/dejavu/DejaVuSerif-BoldOblique.ttf
 
-filename.Sazanami_Gothic=/usr/local/lib/X11/fonts/TTF/sazanami-gothic.ttf
-filename.Sazanami_Mincho=/usr/local/lib/X11/fonts/TTF/sazanami-mincho.ttf
+filename.Sazanami_Gothic=/usr/local/lib/X11/fonts/OTF/ipag.otf
+filename.Sazanami_Mincho=/usr/local/lib/X11/fonts/OTF/ipam.otf
 filename.AR_PL_UMing=/usr/local/lib/X11/fonts/TrueType/uming.ttc
 filename.AR_PL_UKai=/usr/local/lib/X11/fonts/TrueType/ukai.ttc
 filename.UnDotum=/usr/local/lib/X11/fonts/unfonts-core/UnDotum.ttf

そして、Sazanami と設定されているフォントだが、現在の FreeBSD では入れられないようだ。これを japanese/font-ipa に設定する。

これで、NetBeans は日本語で起動した。NetBeans で utf8 の XML を読み込んで、表示してみたがコンソールにも日本語が正しく表示されている。

前々回前回

FreeBSD の Java は openjdk2013年11月18日 13時15分33秒

久しぶりに NetBean で Java を使おうと思ったら、NetBean がインストールされていなかった。長いこと使っていなかったので消してしまっていたらしい。そして、Java もどの実装が現役なのだか。古いものだが四つ入っている。

% ls -d /usr/local/*jdk*
/usr/local/diablo-jdk1.5.0      /usr/local/jdk1.5.0
/usr/local/diablo-jdk1.6.0      /usr/local/jdk1.6.0

さて、make install で引っ張られてくるのは openjdk だった。FreeBSD Java Project: How To Install によると、OpenJDK が現在の公式の Java サポートみたいだ。

OpenJDK は以前の Java の様に自分でダウンロードをしておかなくても良いみたいだ。文句を言われてから取りに行こうと思って、おもむろに make install を叩いたが、そのまま無事に終了してしまった。

もう一つ。8.4 RELEASE 時の ports を使っているが、「Enable Legacy Debugging Support」を使って i386 上ではコンパイルエラーが発生した。これを無効にしてコンパイルを再度始めたところ、今度は問題なく終了できた。メモリが 4GB あると tmpfs を使って、OpenJDK をメモリ上だけでコンパイルとインストールできる。IO が省けて速くなる。

NetBeans 7.3 がデフォルトで、 NetBeans 6.1 の ports もあった。どちらともインストールするだけで動いた。ワークスペースの情報が引き継がれないみたいで、7.3 ではプロジェクトが空っぽだった。

前回次回

Mercurial を WIndows に2009年09月07日 11時44分46秒

NetBeans のプロファイルを使いたいので、最近 Windows 上で NetBeans を使うようになってきた。やっぱり履歴管理は行ないたい。そして、別途のレポジトリ管理などはやりたくないので Mercurial を使うことにした。

Mercurial binary packages for Windows and Mac OS X から Mercurial 1.3.1 を取得。2009-08-08 の Release version になる。ダウンロードして、インストール。

一つだけインストールすればよかったみたいだ。簡単に NetBeans から使えるようになった。

Windows の NetBeans でコンパイルすると2009年08月30日 02時29分33秒

最近、Windows の NetBeans を使うようになった。最近は NetBeans 6.7 も出たが、相変わらず FreeBSD ではプロファイラがサポートされていない。そこで、Windows を試したのだ。MacOS X も持っているが、2003 年ぐらいのモデルなので、荷が重い。

NetBeans を使っていて、気になった事がある。コンパイルに失敗する事があるのだ。

詳しく見ていると、既にコンパイルしている間とプログラムが動いている間に、新たにコンパイルを開始すると、必ずコンパイルに失敗する。どうも、ファイルのロック又は削除に失敗しているようだ。

Windows では利用中のファイルをロックするので、削除できない。その為の様だ。複数のプログラムを走らせておき、変更した箇所の使いかってを調べたりする事も多いので、この動作は不便だ。

NetBeans を通さずに Mercurial を使わなければいけない場合2009年06月29日 12時11分39秒

NetBeans には CVS を始めとする履歴管理のソフトウェアも使える様になっている。CVS は自前の実装のようだが、Subversion や Mercurial 等は、別途にインストールしないと使えなかった。

NetBeans からは rename や copy 等のコマンドが使えない。そこで、これらのコマンドを使う時は、わざわざターミナルを準備する必要がある。最近の履歴管理のソフトウェアで rename や copy が無いのはむしろ旧来型の CVS ぐらいな物だ。しかし、NetBeans にはこれらのコマンドは使えない。

Java 等のソースコードだったら、リファクタを使っても良いのだが。リファクタを使うと、ファイルの名前を変えて適切に必要箇所も変更してくれるので重宝している。

しかし考えてみると git では rename や copy 同等の事を勝手に判別してくれる。

NetBeans が FreeBSD 7.1 i386 で起動しない原因2008年12月11日 13時26分50秒

FreeBSD 7.1-PRELEASE i386 で NetBeans が動かなくなったのは、JDK が原因だった。

NetBeans に --jdkhome を渡すことで、NetBeans を起動する JDK のバージョンを変えることが出来る。


% netbeans --jdkhome /usr/local/diablo-jdk1.6.0
% netbeans --jdkhome /usr/local/jdk16
% netbeans --jdkhome /usr/local/jdk1.6.0
% netbeans --jdkhome /usr/local/jdk1.5.0
% netbeans --jdkhome /usr/local/diablo-jdk1.5.0
XIO:  fatal IO error 0 (Unknown error: 0) on X server ":0.0"
      after 0 requests (0 known processed) with 0 events remaining.

diablo-jdk-1.5.0.07.01_12 だと NetBeans は 7.1-PRELEASE i386 上では動かないようだ。

NetBeans 6.5 が ports に来た2008年12月09日 03時07分44秒

NetBeans 6.5 が java/netbeans に来て、NetBeans 6.1 は java/netbeans61 になった。

repocopy が伴ったため、6.5 がリリースされてから、ports にくるのに時間が掛かった。cvs のファイル名の変更に弱いのと FreeBSD での運用方針が相まっての弊害だ。

NetBeans にてパッケージ名の変更2008年12月05日 10時39分01秒

ファイル名の変更は NetBeans 外から行った方がいい。今度は、ディレクトリ名の変更を試した。つまり、java パッケージの名前の変更だ。パッケージ名の変更はファイル名の変更とは違い、NetBeans に頼ったほうが良いみたいだ。

こちらは、どうも使っている履歴管理のソフトウェアとの相性もありそうな雰囲気だった。ここらへんは、後々、他の組合せでも試してみたい。

今回は Mercurial を使っているプロジェクトだった。 取り合えず、NetBeans 内で行って何が起きるかを観察する事から始める。 なお、今回試したのは NetBeans 6.1 だ。現在、 NetBeans 6.5 が出ている。

プロジェクトのパッケージを右クリックして、「リファクタ」「名前の変更」が出る。これを使うと、ディレクトリの名前を変更し、package や import 部を書き換えてくれる。基本的には、パッケージ名の変更は、Mercurial から rename を行うより簡単だった。しかし、二つの問題があった。

一つは、NetBeans で Mercurial の commit をする時。古いディレクトリも NetBeans が削除してしまう。しかし、Mercurial はこの変更を commit 時に、古いディレクトリが存在しないと commit が失敗する。名前を変更する前のディレクトリを作成する必要があった。

二つ目は、NetBeans のコードの置換。GUI のコンポーネントが入っていたクラスのパッケージ名を変更した。その呼び出し側のコードが正しく変更されていなかった。コンパイルすればすぐに出てきて分かりやすいエラーだ。これが影響だったのかは分からないが、問題があったフィールドはカスタムの初期化を行った場所だった。

NetBeans がデッドロック2008年12月03日 10時49分51秒

NetBeans 6.1 だった頃に一度やってしまった失敗。NetBeans が全く反応しなくなってしまい、kill したので二度目は試していない。しかし、見た感じだとデッドロックを起こしていた様な動作だった。

「Help」->「Check for Updates」と「Tools」->「Plugins」を同時に行ってしまった。「ヘルプ」->「更新の有無を確認」と「ツール」->「プラグイン」が日本語版の表示になる。

この「更新の有無を確認」した時に、幾つかの物がダウンロードが始まった。それをバックグランドで実行。その時に調べたいプラグインがあって、「プラグイン」を起動。それ以降は、NetBeans が反応しなくなってしまった。この「プラグイン」もダウンロードやコンポーネントにアクセスしたいが、「IDE のインストール」がリソースを掴んでいる。しかし、「IDE のインストール」挙動不審になり、ダウンロードが止まってしまった。それとも、ダウンロードが終って、「プラグイン」と同じデータにアクセスしようとして出来なかったのか。

強制終了を行った後に、.netbeans をバックアップから復旧した。

NetBeans のリファクタリングコピー2008年12月01日 16時10分54秒

NetBeans でファイルを「コピー」した後に、「パッケージ」を選択しすると「ペイスト」「リファクタリングコピー」が出来る。これは、ファイルを複製し、クラスの名前だけを変えて新しいクラスを作る。

しかし、これが「バージョン管理」を行っていると相性が良くない。元もと、ファイル名の変更や、ファイルのコピーをサポートしていない CVS なら、直接的な問題にはならない。しかし、Subversion や Mercurial などの、これらの変更を追うプログラムだと、NetBeans をとおして変更を行うと、これらの履歴が記録されない。

そこで、ファイル名を変更したり、ファイルをコピーする場合には、コマンドラインにて、svn copy FileA.java FileB.javahg rename FileC.java FileD.java の様に、呼び出した方が良い。NetBeans からのバージョン管理は、これらのプログラムからの出力を GUI を用いて表示しているだけなので、何ら問題は無い。また、NetBeans がファイルの出現、消滅を検知してくれるので、こちらの問題もない。

このやり方だと、NetBeans がクラス名などを変更してくれなくなるので、コンパイルは失敗するようになる。しかし、基本的にコンパイルエラーを元に簡単に修正できる。それよりも、履歴を正しく記録できないことの方が、悩みは大きい。