Java の文字列内部表現は UTF-16 となっており Unicode を扱うことができます。ですが、 プラットフォーム （OS） との境界部分となるコマンドライン引数とコンソール出力についてはプラットフォーム （OS） の文字コードとの変換がおこなわれるため Unicode を扱えない部分があります。

Windows 版 Java における Unicode 入出力問題と回避方法について紹介します。

C 標準ライブラリ関数には標準出力に文字列を出力する printf 関数があります。これをワイドキャラクタ （≒Unicode） 出力に対応させたバージョンが wprintf 関数です。

ところが、 Windows の wprintf 関数は Unicode を出力できないというのです。にわかには信じられない話です。本当にそんなことがあるんでしょうか？

wprintf 関数の問題点と、 Windows のコンソールに Unicode を出力する方法を解説します。

JavaFX は画面のデザインを CSS で自由に変更することができます。JavaFX 2 では Caspian、 JavaFX 8 以降は Modena と呼ばれるデフォルトのスタイルが用意されています。このデフォルトのスタイルは立体感のあるデザインで、 どことなく Windows XP 時代のような古めかしさを少し感じさせます。

CSS をカスタマイズして、 Web やモバイルで主流となっているフラットデザインに変えてみましょう。今回はスクロールバーです。

Java の GUI は Swing の時代からプラットフォーム ・ ネイティブの UI とは異なる部分がありました。このような Java GUI の傾向は JavaFX になっても相変わらずで、 ネイティブ UI との違いに戸惑ったり違和感を持つことがあります。

その中でも、 JavaFX のコンテキストメニューの振る舞いはとても不自然で不満を抱えている人も多いと思います。（ネイティブと振る舞いが異なるというだけでなく、 JavaFX コンテキストメニューの振る舞いは合理的ではなく明らかに不自然なのです。）

コンテキストメニューが抱えているいくつかの問題は古くからバグレポートに上がっているのですが、 5 年以上経った今でも未解決のままです。

• https://bugs.openjdk.java.net/browse/JDK-8092118

このまま待っていても解決は期待できそうもないので、 コンテキストメニューの不自然な振る舞いを簡単なハックで修正してしまいましょう。

Web では Material Design Icons や FontAwesome などのアイコン ・ セットに人気が集まっています。これらのアイコンは画像ではなく Web フォントとして作成されており、 自由に大きさや色が変えられるという特徴があります。

アイコンにフォントではなく画像を使っていた時代は、 サイズや色ごとに何種類も用意しておかなければならず大変でした。便利になったものです。

Web だけでなく、 デスクトップアプリケーションでもサイズや色が自由に変えられるアイコン使いたいですよね？ JavaFX なら簡単に Material Design Icons や FontAwesome など様々なアイコンが使えちゃうんです！ もちろん、 CSS でサイズや色を自由自在に変えられますよ。

今日は、 JavaFX で様々なアイコン ・ パックが使えるようになるライブラリ Ikonli を紹介します。（Swing でも Ikonli を使用することができますが、 今回は JavaFX での使用方法のみ説明します。）

JavaFX アプリケーションに二重起動を防止する仕組みを追加したところ、 プロセスが終了せずに残ってしまうようになってしまいました。

これは Windows 環境の Java 11 + OpenJFX 11 で発生した事象です。他のプラットフォーム、 OpenJFX のバージョンによっては問題が起こらない可能性もあります。

実行ファイルへのショートカットをバッチファイルから作成する方法を紹介します。

ショートカットを作成する機能は ShellLink オブジェクトによって提供されています。ShellLink オブジェクトは Windows Scripting Host （WSH） からも呼び出せるので、 VBScript （VBS） や JScript でショートカット作成コマンドを実装することもできるのですが、 今回は C++を使って実行ファイル （EXE） としてショートカット作成コマンドを実装してみました。

私はこれまで Java の開発に Eclipse を使ってきました。Eclipse にコードネームとして星の名前が付くよりも前、 たしか Eclipse 2.1 からだったでしょうか。かれこれ、 15 年以上 Eclipse を使い続けてきました。

長年、 Eclipse を愛用してきた私が JetBrains の IntelliJ IDEA に乗り換えました。これまで私は IntelliJ IDEA のことを勘違いしていて、 IntelliJ IDEA は商業主義的だと否定的に捉えていました。しかし、 これは大きな勘違いでした。JetBrains はオープンソース開発コミュニティーに対してとても寛容で、 オープンソース開発を支える存在でもあったのです。

そのことについてお話しましょう。

「例外をむやみにキャッチして握り潰してはいけない」 これはよく知られている鉄則です。自ら対処できないのであれば、 例外をキャッチせずに上位にそのまま伝搬させるのが良い設計であるとされています。

例外を握り潰してしまっている例
public void myBusinessLogic() {
	try {
		doSomething();
	} catch(IOException e) {
		e.printStackTrace();
	}
}

この鉄則は広く浸透しており、 上記のようなコードを書いている人はもういません。多くの開発者は、 処理できない例外をそのまま伝搬させるコードを書きます。

例外をキャッチせずにそのまま上位に伝搬させる例
public void myBusinessLogic() throws IOException {
	doSomething();
}

この鉄則は 「呼び出される側のコード」 について言及したものです。呼び出される側のライブラリならそれで十分でしょう。しかし、 伝搬していった例外はいつか誰かがキャッチしなければなりません。その役回りは、 ほとんどの場合、 アプリケーションが務めることになります。

ライブラリでは投げっぱなしにできた例外も、 アプリケーションではそうはいきません。投げっぱなしにされた例外をアプリケーションはどのようにハンドリングすれば良いのでしょうか？

JavaFX を例にアプリケーションでの例外処理を解説します。

先日、 某社内ネットワークからインターネット上にある Subversion リポジトリのチェックアウトを試みたところ下記のエラーが発生してしまいました。（サーバーは Subversion 1.9.5、 クライアントは Subversion 1.12.2 でした。）

svn: E120104: ra_serf: An error occurred during decompression

エラーメッセージに含まれる ra_serf というのは Subversion で使われている HTTP クライアントライブラリです。この HTTP クライアントライブラリが Subversion サーバーから転送されてきた圧縮データを展開するときにエラーが発生したということです。

ウェブで ra_serf を検索してみると、 上記のエラーのほか E120106: ra_serf: The server sent a truncated HTTP response body. が発生したという報告も多数見つかります。