torutkのブログ

ソフトウェア・エンジニアのブログ

JavaFXアプリケーションのJDK 11対応(配布編)

はじめに

JDK 8でのJavaFXアプリケーションは、javapackagerコマンドを使ってアプリケーションとアプリケーションの実行に必要なJava実行環境をまとめて固めて配布することができました。固め方には、zipアーカイブの他、WindowsLinuxMacOSそれぞれのソフトウェアパッケージ形式(インストーラー)とすることも可能です。

しかし、JDK 11からはJavaFXが分離した際にjavapackagerコマンドも外されてしまいました。OpenJDKでは、javapackagerを代替する新しい機能を開発中*1ですが、早くてJDK 12からとなります。それまでの間、jlinkコマンドを使ってアプリケーションとアプリケーションの実行に必要なJava実行環境をまとめることとします。なお、jlinkはOS固有のパッケージ形式(インストーラー)を作成することはできません。

jlinkコマンドを使った実行イメージの作成

jlinkコマンドは、指定したモジュールが依存するモジュール群をJDKから抜きだして、実行イメージまとめるのに使います。

モジュール対応したJavaFXアプリケーションの実行イメージの作成

JavaFXアプリケーションが、モジュール対応している場合はjlinkコマンドで簡単に実行イメージを作成することができます。

ただし、モジュールパスでJavaFXライブラリのパスを指定するときは、JavaFX SDKを展開したディレクトリではなく、JavaFX jmodsを展開したディレクトリを指定します。

D:\work\EarthGadget> jlink --module-path "C:\Program Files\Java\JavaFX\javafx-jmods-11.0.1";dist ^
--add-modules com.torutk.gadget.earth ^
--output runtime ^
--launcher earthgadget=com.torutk.gadget.earth/com.torutk.gadget.earth.EarthGadgetApp
  • --module-pathでは、JDK標準以外のモジュールを収容するディレクトリを指定します。ここでは、JavaFX jmodsファイルのあるディレクトリ(C:\Program Files\Java\JavaFX\javafx-jmods-11.0.1)と、アプリケーションのモジュール化JARファイルのあるディレクトリ(カレントディレクトリ下のdist)を指定しています。
  • --add-modulesでは、アプリケーションのメインモジュール(com.torutk.gadget.earth)を指定しています。
  • --outputでは、実行イメージを生成するディレクトリを指定しています。
  • --launcherでは、実行イメージの中にアプリケーション起動用のコマンド(シェルスクリプト/バッチファイル)の名前と起動するモジュールおよびメインクラス名を指定しています。

実行イメージが展開されるディレクトリに、JavaFX関係のライブラリ(ネイティブライブラリのdllファイル、クラスライブラリのJARファイル等)も展開されます。

outputオプションで指定したruntimeディレクトリ下のbinディレクトリには、launcherオプションで指定した起動スクリプトファイル(earthgadget)/起動バッチファイル(earthgadget.bat)があるので、UNIX系OSなら前者を、Windows OSなら後者を実行するとJavaFXアプリケーションが立ち上がります。

jlinkコマンドのmodule-pathオプションで、JavaFXSDKのlibディレクトリを指定すると、実行イメージの中にネイティブライブラリが含まれないので実行時にエラーとなってしまいます。jlinkコマンドでJavaFXを指定する場合は、JavaFXのjmodsを指定します。

モジュール対応していないJavaFXアプリケーションの実行イメージ作成(改訂)

JavaFXアプリケーションがモジュール対応していない場合は、JavaFXアプリケーションが必要とするモジュールをjdepsコマンドでリストアップしてからjlinkコマンドでリストアップされたモジュールをそれぞれ指定します。

ただし現時点ではJDKのモジュールから必要なものを抜粋した実行イメージを生成することができますが、実行イメージにJavaFXライブラリとアプリケーションを含めることはできませんでした。

jdepsでアプリケーションの実行に必要なモジュールを調べる

まず、アプリケーションJARファイル(非モジュール対応)をjdepsで解析します。

ここで、非モジュールJARの依存関係を解析する場合、jdepsコマンドのオプション--print-module-depsおよび--list-depsは使用しないのがミソです(id:skrbさんの次のブログ参照)。

skrb.hatenablog.com

まずは、アプリケーションJARファイルだけを指定した場合の実行例です。

D:\work\EarthGadget> jdeps -s dist\EarthGadget.jar
EarthGadget.jar -> java.base
EarthGadget.jar -> java.prefs
EarthGadget.jar -> 見つかりません

D:\work\EarthGadget>

アプリケーションJARが依存するJDKのモジュールのみ表示されます。JavaFXのモジュールはリストされません。また、JavaFXライブラリが必要とするJDKのモジュールもリストされていません。

そこで、JavaFXライブラリを解析対象に追加します。

D:\work\EarthGadget> jdeps -s --module-path "C:\Program Files\Java\JavaFX\javafx-sdk-11.0.1\lib" dist\EarthGadget.jar
EarthGadget.jar -> java.base
EarthGadget.jar -> java.prefs
EarthGadget.jar -> javafx.base
EarthGadget.jar -> javafx.controls
EarthGadget.jar -> javafx.graphics
EarthGadget.jar -> 見つかりません
javafx.base -> java.base
javafx.base -> java.desktop
javafx.controls -> java.base
javafx.controls -> javafx.base
javafx.controls -> javafx.graphics
javafx.fxml -> java.base
javafx.fxml -> java.scripting
javafx.fxml -> java.xml
javafx.fxml -> javafx.base
javafx.fxml -> javafx.graphics
javafx.graphics -> java.base
javafx.graphics -> java.desktop
javafx.graphics -> java.xml
javafx.graphics -> javafx.base
javafx.graphics -> jdk.unsupported
javafx.media -> JDK removed internal API
javafx.media -> java.base
javafx.media -> javafx.base
javafx.media -> javafx.graphics
javafx.swing -> java.base
javafx.swing -> java.datatransfer
javafx.swing -> java.desktop
javafx.swing -> javafx.base
javafx.swing -> javafx.graphics
javafx.swing -> jdk.unsupported.desktop
javafx.swt -> java.base
javafx.swt -> javafx.base
javafx.swt -> javafx.graphics
javafx.swt -> 見つかりません
javafx.web -> java.base
javafx.web -> java.desktop
javafx.web -> java.xml
javafx.web -> javafx.base
javafx.web -> javafx.controls
javafx.web -> javafx.graphics
javafx.web -> javafx.media
javafx.web -> jdk.jsobject
javafx.web -> jdk.xml.dom

なお、--module-pathに、JavaFXSDKではなく、JMODの方を指定すると何故か依存が解析されませんでした。

D:\work\EarthGadget> jdeps -s --module-path "C:\Program Files\Java\javafx\javafx-jmods-11.0.1" dist\EarthGadget.jar
EarthGadget.jar -> java.base
EarthGadget.jar -> java.prefs
EarthGadget.jar -> 見つかりません

D:\work\EarthGadget> 

非モジュール対応アプリケーションJARファイル(EarthGadget.jar)が依存しているのは

となります。よって、jlink でこれらを指定すればあとは依存関係を辿って必要なモジュールが取り込まれた実行イメージが生成されます。なお、java.baseは暗黙で使用されるモジュールなので指定を省略できます。javafx.graphicsはjavafx.controlsが依存しているのでこちらも省略できます。javafx.baseはjavafx.controlsが依存しているのでこちらも省略できます。

jlinkで非モジュール対応アプリケーションJARのための実行イメージを生成する
D:\work\EarthGadget> jlink --add-modules javafx.controls,java.prefs ^
 --module-path "C:\Program Files\Java\JavaFX\javafx-jmods-11.0.1" ^
 --output runtime

生成された runtime ディレクトリの容量は約87MBとなりました。
JavaFXライブラリ(クラスライブラリおよびネイティブライブラリ)も含まれています。
なお、アプリケーションはこのruntimeには含まれません。

jlinkで作成した実行イメージを使ってアプリケーションを実行する
D:\work\EarthGadget> runtime\bin\java -jar dist\EarthGadget.jar

まとめ

  • モジュール対応したJavaFXアプリケーションは、jlinkコマンドで実行に必要なJDK、ライブラリ(Javaクラスライブラリ、ネイティブライブラリ)、アプリケーションをまとめたアプリケーション実行イメージを生成できる。
  • モジュールに対応していないJavaFXアプリケーションは、jdepsコマンドで実行に必要なJDKのモジュールを解析し、続いてjlinkコマンドで必要なモジュールを抜粋し実行イメージを生成する。ただし、非モジュール対応のJARファイルは実行イメージには取り込まれない。

*1:JEP 343: Packaging Tool

JavaFXアプリケーションのJDK 11対応(NetBeans編)(モジュール対応編)

はじめに

じゃばえふえっくす Advent Calendar 2018 - Qiita20日目のエントリです。

前回のブログ(JavaFXアプリケーションのJDK 11対応(NetBeans編) - torutkのブログ)では、アプリケーションをJava SE 9から導入されたモジュールシステム(Java Platform Module System、以下JPMSと呼ぶ)には対応せずに、JavaFXライブラリをクラスパスで参照する方法でJDK 11に対応させました。

しかしながら、JPMS対応をしなかったため、実行時に--add-modulesを指定するか、メインクラス(javaランチャーから最初に指定するクラス)のロード時にJavaFXのクラスを参照しないようにする(javafx.application.Applicationの継承をやめる)必要があります。

そこで、今回のエントリではJPMS対応によるJDK 11対応をすることにします。

JPMS対応することで、上述の制約がなくなります。さらに、Java実行環境と一緒にアプリケーションを配布する際に、Java実行環境をアプリケーションに必要なモジュールに限定することで配布サイズ削減が図れます。jlinkコマンドでアプリケーションとアプリケーション実行に必要とするモジュールだけを1か所にまとめた実行イメージを作成できます*1

対応方法

プロジェクトの作成

NetBeans 10で[File]メニュー > [New Project...] で、カテゴリ[Java]から[Java Modular Project]を選択します。

f:id:torutk:20181209000836p:plain
NetBeans 10 New Project Java Modular Project

プロジェクト名とプロジェクトを作成するフォルダを指定します。

f:id:torutk:20181209001657p:plain
NetBeans 10 New Project Java Modular Project で プロジェクト名と場所を指定

Java Modular Projectで生成したプロジェクトでは、プロジェクトの下に複数のモジュールが定義できるマルチモジュールな構成となります。よって、プロジェクト作成後に、少なくとも1つのモジュールを定義します。

プロジェクトペインで今作成したプロジェクトを右クリックし、[New] > [Module]を選択します。

f:id:torutk:20181209002117p:plain
NetBeans 10 Java Modular Project に新しいモジュールを指定

モジュール名を指定します。モジュール名は、一般的にはモジュールに含むパッケージ名のうち代表的なものとします。

f:id:torutk:20181209002535p:plain
NetBeans 10 Project に新しいモジュールを指定

モジュールを作成すると、プロジェクトの配下にモジュールが追加され、その中にmodule-info.javaが生成されます。

f:id:torutk:20181209002845p:plain
NetBeans 10 Project に追加された新しいモジュール

JavaFXモジュールのパスを指定

プロジェクトのプロパティを開き、左側ペインで[Libraries]を選択、右側ペインの[Compile]タブで、Modulepath の右端の[+]をクリックします。ポップアップメニューが出るので、[Add Library」を選択、ライブラリ一覧からJavaFX 11を選択します(NetBeansのライブラリにJavaFX 11を追加する方法は、JavaFXのNetBeans設定 - ソフトウェアエンジニアリング - Torutk参照)。

f:id:torutk:20181209004431p:plain
NetBeans 10 Project のモジュールパスにJavaFX 11を指定

ソースファイルの移動

NetBeans 8.2/JDK 8で作成したJavaFXアプリケーションのソースファイルを、新しく作成した Java Modular Projectのプロジェクトへ移動します。NetBeans 10で旧プロジェクトを開き、ソースファイルを含むパッケージをマウスでドラッグし、新プロジェクトのモジュールの下の[classes]にドロップします。

f:id:torutk:20181219072428p:plain
旧プロジェクトから新プロジェクトへのソースファイル移動

そのままドロップするとフォルダが移動になるので、コピーするにはCtrlキーを押しながらドロップします。

module-info.javaの定義

プロジェクトのライブラリ定義のモジュールパスにJavaFX 11ライブラリを指定しただけでは、アプリケーションからJavaFXのクラスを参照することはできません。JavaFXライブラリのクラスを参照するimport文がエラーになってしまいます。

f:id:torutk:20181209005220p:plain
NetBeans 10 Project のモジュールパスにJavaFX 11を指定しただけでは参照を解決できず

そこで、プロジェクトのモジュールパスにJavaFXライブラリを指定した後、module-info.javaに使いたいクラスが含まれるモジュールを定義します。

module com.torutk.gadget.image {
    requires javafx.controls;
    requires javafx.fxml;
    opens com.torutk.gadget.image to javafx.graphics, javafx.fxml;
}
  • 基本はjavafx.controls モジュールへの依存を記述。javafx.controlsからjavafx.graphicsモジュールへの依存の推移により暗黙的な依存が定義されるので、javafx.graphicsへの依存は記述不要。
  • FXMLを使う場合は、javafx.fxmlモジュールへの依存を記述。
  • アプリケーションのメインクラス(javafx.application.Applicationクラスを継承するアプリケーションクラス)を持つパッケージ名をopensで記述。

ビルド成果物

プロジェクトの下に定義したモジュール毎に、ビルド成果物であるモジュールファイル(JARファイル)が生成されます。

f:id:torutk:20181220061707p:plain
ビルド成果物

JARファイルの内容が次です。モジュール記述子(module-info.class)が含まれています。

f:id:torutk:20181220071325p:plain
モジュールファイル(JAR)の内容

コマンドラインからの実行

NetBeans上でビルドしたJARファイルをコマンドラインから実行するには、少々長いオプションを指定します。

D:\work\ImageGadget> java --module-path "C:\Program Files\Java\JavaFX\javafx-sdk-11.0.1\lib";dist -m com.torutk.gadget.image/com.torutk.gadget.image.ImageGadgetApp
  • JavaFX 11ライブラリは、C:\Program Files\Java\JavaFX\javafx-sdk-11.0.1 にインストール
  • アプリケーションのモジュールJARファイルは、カレントディレクトリのdist下にある

NetBeans上でメインクラスの指定をJARマニフェストにする方法が見つからなかったのでオプションが長くなってしまいました。

まとめ

  • アプリケーションをJPMS対応するには、NetBeansのプロジェクト種類でJava Modular Projectを選ぶ
  • Java Modular Projectで生成したプロジェクトでは、最低1つはモジュールを作成する
  • JDK標準以外のライブラリを利用するときは、プロジェクトのプロパティでライブラリをモジュールパスに登録する(クラスパスではなく)
  • java.baseモジュールに含まれるクラス以外を利用するときは、モジュール定義(module-info.java)に依存を記述する

*1:@skrbさんのコメントをもとに文章を修正しました。モジュール対応・非モジュール対応のアプリケーションの実行イメージの作成については、 JavaFXアプリケーションのJDK 11対応(配布編) - torutkのブログ に書きました。

JavaFXアプリケーションのJDK 11対応(NetBeans編)

はじめに

これまでにNetBeans 8.2/JDK 8のAntプロジェクト(種類はJavaFXアプリケーション)で作成したJavaFXアプリケーションを、JDK 11に対応させようと試みました。

NetBeans は間もなくリリース予定のNetBeans 10のテストバージョン(vc4)で、OpenJDK 11.0.1とJavaFX 11.0.1を使います。

 今回はアプリケーション側のモジュール対応は行いません。移行後に段階的にモジュール対応を進めます。

最初の試み

まずは、JDK 11からJavaFXが分離したのに伴い、JavaFX 11を別途インストールしマシン上に展開、NetBeansのプロジェクト設定でライブラリとしてこのJavaFXを指定する方針で進めました。

 

JavaFX 11.0.1をダウンロードし、NetBeansのライブラリ定義に加え、既存のJavaFXアプリケーションのプロジェクトにクラスパスとして追加します。

コンパイルは通りますが、実行すると

JavaFX deployment library not found in active JDK.
Please check that the JDK is correctly installed and its version is at least 7u4 on Mac or 7u6 on other systems.

とエラーになってしまいます。NetBeansのビルド定義には、JDKの中にあるJavaFXライブラリの場所を探すコードがあり、見つからないと上述のようにエラーとなってしまいます。

この問題を解決するには、NetBeansが生成したビルド定義に大分手を入れる必要があります。この試みは挫折とします。

次の試み

次は、NetBeansでプロジェクトを新規に作り直す方法で進めます。

既存のディレクトリにNetBeansで新規プロジェクトを作成するとエラーになるので、新しいディレクトリにプロジェクトを作成します。

プロジェクト種類をJavaFXアプリケーションで新規作成しようとするとエラー

このとき、プロジェクトの種類をJavaFXアプリケーションとすると、

Failed to automatically set-up a JavaFX Platform.
Please go to Platform Manager, create a non-default Java SE platform, then go to the JavaFX tab,
enable JavaFX and fill in the paths to valid JavaFX SDK and JavaFX Runtime.

とエラーになります。

プロジェクト種類をJavaアプリケーションで新規作成するとビルドはOKだが実行エラー

そこで、プロジェクト種類をJavaアプリケーションとして新規作成します。そこに既存のソースコードを追加し、ライブラリにJavaFX 11を追加します。

これでビルドは成功しますが、アプリケーションを実行するとエラーとなってしまいます。

エラー: JavaFXランタイム・コンポーネントが不足しており、このアプリケーションの実行に必要です

--add-modulesでJavaFXモジュールを指定して実行エラー回避

解決方法は、javaの実行時のJVMオプションで、--add-modules=javafx.controls のようにアプリケーションから利用するJavaFXのモジュールを指定します。FXMLを使うアプリケーションの場合は、--add-modules=javafx.controls,javafx.fxml のように指定します。

Getting Started with JavaFX 11

なぜ--add-modulesでJavaFXモジュールを指定しなければならないか

ですが、なぜJavaFXのライブラリ(JARファイル)をクラスパスで指定しているのにエラーとなってしまうのか不思議でした。

いろいろ調べてみたところ、次のメーリングリストでその原因が言及されていました。

launching JavaFX in 11

これによると、実行時のエラーはjavaコマンドが最初に参照するメインクラスがJavaFXのApplicationクラスを継承している場合に発生します。javaコマンドがメインクラスをロードする際に、メインクラスが継承しているスーパークラスもロードする必要があります。しかしJavaFXのApplicationクラスがスーパークラスの場合、javafx.graphicsモジュールを探しに行って存在しない場合、クラスパスを探すことなくエラーとなります。

Mainクラスでjavafx.application.Applicationクラスの継承をやめる

試しに、メインクラスでJavaFXのApplicationクラスを継承するのをやめて、mainメソッドの中でJavaFXのApplicationを継承する別クラスを初期化するコードを呼ぶように修正したところ、--add-modulesの指定をせずに実行できるようになりました。

まとめ

  •  NetBeansJavaFXアプリケーション・プロジェクトは、JavaFXが分離したJDKOracle JDK 11以降およびOpenJDK)には対応できない
  • NetBeansJavaアプリケーション・プロジェクトでJavaFXアプリケーションをビルドする際は、JavaFX 11を別途ダウンロードしマシン上に配置し、NetBeansのライブラリ定義を追加し、プロジェクトからJavaFXライブラリを参照する(クラスパスとして参照)
  • NetBeansJavaアプリケーション・プロジェクトでJavaFXアプリケーションを実行する際は、メインクラスにJavaFXのApplicationクラスを継承させず、別クラスで継承し、メインクラスのmainメソッドにはその別クラスを初期化するコードを記述する。

 

JDK 11の環境設定

JDK 11から、Oracleが提供するWindows OS向けのJDKは、Oracle JDKとOpenJDKの2種類になりました。

Oracle JDK 11は、有償で技術サポートが含まれ、LTS(長期サポート版)となる商用製品となりました。なお、開発・試験・デモ用など使用用途に制限のあるOTNライセンスでの無償提供もあります。
一方、OpenJDK 11は、無償で提供されています。

Oracle JDKもそのソースコードはOpenJDKとして開発されています。従来はOpenJDKのソースには含まれないOracle JDK独自機能(Java Flight Recorder、Application Class Data Sharing、フォント描画等)がいくつかありましたが、JDK 11に向けてOpenJDKに統合されてきています。このOpenJDKのソースはGPLであり、OpenJDKのソースをビルドしてバイナリを提供する団体がいくつか登場しています。

JDKの入手先

Oracle JDK 11

商用利用するアプリケーションをこのOracle JDKで動かす場合には、有償のライセンス契約が必要となります。開発・試験・デモ用など使用用途に制限のあるOTNライセンスは無償で提供されています。

Java SE - Downloads | Oracle Technology Network | Oracle

OpenJDK 11 Oracleビルド版

先のOracle JDK 11とは別に、OracleがOpenJDKソースをビルドしてバイナリを提供しています。
GPLv2 のクラスパス例外付きライセンスで提供されています(無償)。

JDK 11.0.1 GA Release

Zulu

Azul Systems社がOpenJDKを独自にビルドしバイナリを提供しています。Zuluの利用は無償で、技術サポートを有償で提供しています。

Download OpenJDK Java Linux Windows macOS Alpine Java 11 Java 8

AdoptOpenJDK

ロンドンJavaコミュニティが運営し、OpenJDKコミュニティの幅広いメンバーの活動によってOpenJDKをビルド・提供する団体です。

AdoptOpenJDK - Open source, prebuilt OpenJDK binaries

Windows上でのOracle JDKの環境設定バッチ

Oracle JDKインストーラーでインストールし、レジストリにインストール場所が記録されます。これまでは、レジストリからJDKの場所を調べて環境変数を設定するバッチファイルを作って環境設定をしていました。

Setting oracle jdk path using registory for Windows command prompt - Gist

OpenJDKは、zipで提供、インストールしたい場所に展開するだけのインストールなので、レジストリからOpenJDKの場所を調べることができません。そこで、自分で決めたインストールディレクトリの下にJDK-<バージョン番号>のディレクトリを探してそれを環境変数に設定するようにしました。

LTSについて

これまで、JDKは1年半〜4年半の間隔でメジャーバージョンアップをしてきました。また、マイナーバージョンアップにおいても、セキュリティアップデート、バグ修正のほか機能追加が行われたりしていました。

これからは、LTS版はセキュリティアップデートとバグ修正が続き、機能追加は半年毎にバージョンアップされるOpenJDKの方で行われるようになります。なので、JDK 12、13、14、15、16と半年毎にリリースされている間、LTS版のJDK 11はセキュリティパッチとバグ修正パッチが順次提供されます。

なので、ミッションクリティカルなシステムではこのLTS版を使うと、より頑健になります。

ミッションクリティカルでなく、これまで3ヶ月毎にリリースされるCPU(Critical Patch Updte)やPSU(Patch Set Update)のJDKに更新していない、リリース時点のJDKバージョンで固定して使っているシステムでは、OpenJDKで十分でしょう*1

また、LinuxディストリビューションにはこれまでもOpenJDKが含まれていたので、こちらを使っていたシステムはそのままLinuxディストリビューションのOpenJDKを使い続けることになると思います。

*1:3ヶ月毎にJDKをアップデートして回帰テストなんてやってられないや、というシステムなど

Wix toolset 3.11のインストールで.NET 3.5を要求される

自宅PCのインストールソフトウェアを整理していて、Wix toolset(ちょっと古いバージョン)をアンインストールして最新の3.11.1をインストールしようとしたところ、.NET Framework 3.5が必要とインストーラーがエラー停止しました。
Windows 10では、.NET Framework 4.6(Creator Updateで4.7)が入っていますが、これではダメで古い .NET Framework 3.5がないと先に進めません。

コントロールパネルの[プログラム]>[プログラムと機能]>[Windowsの機能の有効化または無効化]から.NET Framework 3.5にチェックを付けてインストールする手順で対処可能なようです。

Wix 3.14(3系の次のリリース予定)またはWix 4において、.NET Framework 3.5への依存が解消されるそうですが、まだどちらもリリースはされていません。

インターネット非接続環境での.NET 3.5のインストール

Windows 10にインターネット非接続な環境で.NET Framework 3.5をインストールする方法を調べてみたら、Windows 10のインストールメディアを必要とします。

.NET Framework 3.5 を有効化する手順について ( Windows 10 ) | Ask CORE

うーん、プレインストールのノートPCではWindows 10のインストールメディアはないし、インターネット接続環境した別マシンでWindows 10のインストールメディアを作成し、外付けドライブに置いてそれを持ってくるとかとっても面倒です。

なお、アプリケーション実行用のランタイムイメージは.NET Framework 3.5については用意されていないようですね。ということは、.NET Framework 3.5以下で作成したアプリをWindows 10で使うのはかなり難関(不可能ではないが)です。

はてな日記のサービス終了がそろそろ

夏頃に、はてな日記のサービスが終了になるとのアナウンスがありました。終了予定は2019年春頃です。はてなブログに移行するか、他のブログサービスに乗り換えるかの選択となります。

2019年春「はてなダイアリー」終了のお知らせと「はてなブログ」への移行のお願い - はてなダイアリー日記

はてなブログへ移行する場合は、はてな日記上のコンテンツのURLは移行先のはてなブログへリダイレクトされるので、別サイトからリンクを張っていた場合もリンク切れになることはなさそうです。

はてな日記をいつ頃使い始めたのかを遡ってみると、2004年9月2日が最初のはてな日記書き込みでした。今から14年前ですね。日帰り出張(たしか岐阜へ)で早朝〜午前様となった愚痴とともに往復の電車でリーンソフトウェア開発本を読んだ一日だったらしいです。

出張、疲れた - torutkの日記

これまで、1113日分を書いているので*1、1年あたりでは80日と一週間に1〜2日のペースで書いていたことになります。

*1:プロフィールページに書き込んだ日数が表示されています