Javafx

Java11 + JavaFXでランチャーとプロファイリング

Java11で作成したアプリをパッケージングし、メモリやスレッドのプロファイリングを可能にします。

やりたいことは

  • 1コマンドでアプリをパッケージングしランチャーや再配布JREを作る
  • ランチャーから再配布JREを使用してアプリを起動
  • 稼働中のアプリのスレッドやGCを可視化する

です。

2018年10月現在、javapackagerはJDK11に付属していません。

JDK-8203379 : Remove javapackager sources from OpenJFX repo

JDKからJavaFXを削除する一環として、javapackagerツールとjdk.packagerとjdk.packager.servicesモジュールも削除されました。
javapackagerはOpenJDKビルドには含まれておらず、スタンドアロンのJavaFXビルドにも含まれていません。
代わりに、OpenJDKで代替ツールを提供することを検討しています。
その間、開発者はJDK 10の既存のjavapackagerツールを使用することができます。

というわけで。
javapackagerには頼らず外部ツールとjlinkを使用して実現することとします。
visualvmとlaunch4jはJava11で使えるようになっています。
(インストーラは別途作る)

ツールの使い方自体は公式サイトのドキュメントや一時配布物を見ればわかるので重要情報以外は省略しています。
どちらかというと導入にあたってパッケージングのフローを考える際「これどうなんだろ」となりそうな問題を集積したような内容になっています。

外部ツールのデリメリ

ランチャーやインストーラはBtoC案件ではInstallShieldのようなWindows専用の商用ソフトを使うこともあるかと思います。
ここ数年クライアントアプリの認証回りの仕組みが世界的レベルで激変しているのでなおさらです。

それ専門のツールを個別使用したほうが基本的に自由度が高くよいものができます。
ベンダー製品が存在するほどの分野なので、突き詰めれば奥が深いです。

実務ではその用途専門のものを利用する場合もありますよという前振りです。
(ランチャーやインストーラ作成に外部アプリを利用することがイレギュラーかというと、そうでもないという話)
PureJavaのエンブレムを張ることがステイタスだった時代もありますが、遠い昔の話です。

もちろんjavapackagerの機能自体は知識として持っていた方がよいです。
ビルド手順に標準以外のツールを組み込む場合でも、どこかで使うかもしれません。
個人的にjavapackagerで使いたいのはCSSファイルのバイナリ化機能くらいかなと思います。
(むしろこれを単機能モジュールで配布してくれれば解決ですが。)

今のところ、CSSと一緒にあらかじめバイナリ化したデータも一緒にGithubに置いておく、というような開発時手順をよしとするのであれば。
buildの処理自体にはjavapackagerを組み込まず、それ以外の全ての処理をJDK11のみで行うということも可能です。

CSSの部分だけ旧JDKを呼んでもよいのですが、javapackagerが今のSDKに標準添付されていないのが問題なのであって。
いずれ簡単に呼べるようにはなるであろう部分なので、そこだけは暫定対応でもよいのではないかなと思ったり。

標準ツール外で行うメリット
JavaFX以外、Swingや最近流行りのJava亜種言語のクライアントにも対応が可能
サーバースターター等も作成が可能(一応OS毎に作り分ければクロスプラットフォームにできる)
起動時に必要となりそうな機能が網羅されており、javapackagerより細かい制御が可能
デメリット
各種ツールのフォローアップが必要(どっちにしろ必要)
アプリに合わせてパッケージングのフローを構築する必要がある(どっちにしろ必要)
javapackagerのJavaFX専用機能は利用できない(JDK-8203379にもありますが現状JavaFXと運命共同体の専用ツール)
ビルドが外部ツールのライフサイクルに依存(とはいえ高需要のため、Java誕生以降ランチャー作成ツールがない時期はない)

launch4j

公式へのリンクです。

launch4j – Cross-platform Java executable wrapper

Launch4jは、軽量のWindowsネイティブ実行ファイルにjarファイルとして配布されるJavaアプリケーションをラップするためのクロスプラットフォームツールです。
実行可能ファイルは、特定のJREバージョンを検索するか、バンドルされたものを使用するように設定できます。
また、初期/最大ヒープサイズなどの実行時オプションを設定することもできます。
アプリケーションアイコン、ネイティブのプレJREスプラッシュ画面を使用しユーザーエクスペリエンスを向上させ、適切なJREが見つからない場合にはJavaダウンロードページへ誘導します。

バイナリツールは3.12、Maven pluginは1.7.22以降でJava11に対応します。

JavaFXはまともに動かそうとするとチューニングが半ば必須で、長いJVM起動オプションが必要です。
JVM起動オプションやチューニングパラメータはJVMの実装やバージョンに依存します。

そのためSwingのようにRuntimeJRE+executableでPureJavaアプリを作るより、ランチャーから引数を渡して再配布するJREを叩くという構成の方が都合がよく、厳密な起動処理ができます。
またJigsawのおかげでこういったことがしやすくなり、配布元からも推奨されています。
(ちなみにアプレットやJWSみたいのは今求められてなくて、こういったAll-In-One型の方が企業のニーズが高いんです、というのが配布側のシナリオ)

というわけでランチャー作成ツールが必要です。

リッチクライアントには必須気味の知識ですが、必要知識はJavaのノウハウとしては比較的汎用です。
リッチクライアント以外にも応用できます。
(CUIのバッチexe群を作ったりとか)

少なくともFXMLより汎用性が高いノウハウになるので、少し時間をかけて取り組む価値はあると思います。
(というと大げさですが、あまり使うことがないというだけであって難しい仕組みのものではありません。)

Hint

Win上でMavenビルドをする場合、最終的にはMinGWlaunch4j-maven-pluginがあればよいです。

バイナリ配布版(GUI/CUIのスタンドアロンツール)でJava11用のランチャーは作成可能ですが、ツール自体はバージョン最新の3.12でもJava11上で実行することはできません。
ただしこれと対になるリリースである最新版のlaunch4j-maven-pluginはJDK11で実行できます。

設定項目の意味やMavenの設定方法はドキュメントに全部書いてあります。
私はこのように設定ファイルや画像リソースを管理しています。

面倒そうに感じる場合、最初は旧JRE(JRE1.6 – 1.8x)をインストールしてGUIツールを使えば多少は楽だと思います。
一度設定のひな形を作ってしまえば、JRE1.8やGUIツールをアンインストールしても問題ありません。
(たとえば成果物バージョンアップ時に記述を変更するような箇所は限られるので、メンテはXML手修正でも問題ないかと)

visualvm

1.4.2でJava11に対応しています。

VisualVM – All-in-One Java Troubleshooting Tool

VisualVMは、コマンドラインJDKツールと軽量プロファイリング機能を統合したビジュアルツールです。
開発時間と生産時間の両方を考慮して設計されています。

とのことです。

JavaFXをデフォで動かそうものなら割と無駄なメモリの使い方をしてくれます。
ですのでクライアントに適した値を設定してあげる必要があります。

ある程度これは設定されることが多い、というものはあるかもしれませんが、具体的な正答はありません。
またJVMバージョンによっても少しずつ違うものなので、適宜キャッチアップしながら試すような作業が必要です。
この作業はWindowsのタスクマネージャーのメモリ量をちょろっと見てできるような作業ではありません。

オプションがわからないときはグーグル先生に聞くと割と引っかかったりします。

Hint

Java11で稼働が可能です。
etc/visualvm.confを開くと、ファイルの末尾に以下の設定項目があります。

起動時にJVMをスイッチできる仕組みになっています。こんなかんじに。

というわけで、Win+Java11のビルドマシンでlaunch4jとvisualvmを使う場合、Java11より前のJava環境は必要ありません

なぜここにこだわるかというと、私自身が開発機にJava11しか入れていないためです。
(パス管理はWindowsの環境変数でなくcygwin上で行っていてコマンドもalternate管理しているので共存は可能なのですけれども、Widows上で1.8JREがインストールされた環境でJava11のクライアント開発はしたくない)

Mavenビルドの例

こんなことをするような人にとっては上記の情報でこと足りると思いますが、一応私の場合の使い方を記載します。
HelloWorld的なことをしても公式サイトに書いている以上のノウハウは出てきません。
やらなければ、わからない。

というわけでサンプルは私が作成しているネットワークミュージックプレイヤーを使用します。

概要

Subsonic系列のサーバ、Subsonic/Libresonic/Airsonic/Jpsonic等に接続視聴が可能なプレイヤーを作成しています。
JavaFXのソースの書き方としては比較的特化になるので詳細は省きます。
(パッケージングの話とはあまり関係がありません)

このプレイヤーは3プロジェクトに別れています。

coreとoptはマルチプロジェクトです。
coreでおおまかなインターフェース外観を作成し、機能はoptでプラグインとして実装します。

sonic-playerが今回のビルドの話に関係するプロジェクトです。
Mainクラスが配置されていて

でJRE作成やランチャーの作成を行います。

Mavenを実行するとtargetにsonic-playerディレクトリを作成し、以下のようなものが生成されるようになっています。

exeのダブルクリックで再配布用のJREを使用してプログラムを起動します。
(現状はほとんどブランクで、フレームを表示するのみ)

HelloWorldよりは少し面倒ですけれど、少しだけ本格的なリッチクライアントを作り始めると、まぁこんな構成になっていくこともあるかもしれない原初的なパターンの一つです。

ビルドを行うpomはsonic-player/pom.xmlです。

Jarの出力

maven-dependency-pluginとmaven-antrun-pluginを併用し、libとoptディレクトリにライブラリを出力します。
現状unnamedでJarをロードしていますが、Jarの格納ディレクトリをライブラリ用とプラグイン用に分けておけばクラスロードの読み込み順の制御をディレクトリ単位で行えます。
プラグインを先に読むためにこうしているということです。

maven-dependency-plugin

以下のようにlibディレクトリに依存するJarを出力します。
stripVersionはJarのファイル名からバージョンを除外するオプションです。

excludeArtifactIdsに除外するJarを指定しています。
たとえばchecker-qual(nullnessライブラリ)はコンパイル時にあればよいので、module指定はstatic指定してあります。
ランタイムには含めません。

javafxは後述しますが、Maven CentralのJarは使わないので除外対象にします。

maven-antrun-plugin

XML記述と実際の処理順が前後するのですけれども。

  1. create-lib-dirで出力ディレクトリを作成しています
  2. devide-lib-dirでmaven-dependency-pluginで出力した依存ディレクトリのうち、プラグインとして扱うJarをoptディレクトリに移動しています。
    (jarのnamingでひっかけている)

このときにビルドプロジェクト自身が作成するMainJar(sonic-player.jar)をlibにcopyしています。

バッチ書きたくないけど

moduleを出力するためのmavenプラグインもありますが、マルチpomの場合記述が無駄に複雑でかなりイケてないです。
ローテクであろうが簡単確実に動く方法で記載しています。

依存ツリーの逆参照が必須になるプラグインなので、siteと同じで構成によっては非常に苦労するもしくは動かない可能性があることが懸念されます。
と、私のDNAが叫んでいたのでドキュメントをチラ見して回れ右しました。
簡単なプロジェクトで検証して動いたで納得はできない部分でもあります。

バッチ嫌いだからといってGradleにすべき、はそれも難しい問題です。
アーリーアクセス追随しながら見ている限り、GradleはMavenより比較的対応が遅くバグも多いです。

JREの作成

これもプラグインがありますが使わず、確実に動かすためexec-maven-pluginからバッチを使用しています。
(このビルド用pomはJDK11ea時代に動くように作ったものです。)

exec-maven-pluginからバッチをcallしている部分。

jlinkをcallしているバッチ本体は以下のファイルです。

create-jre.bat

オプションはMavenの冒頭のプロパティに記載してあります。
バッチ実行時に、出力ディレクトリとjdkとjavafxのmodsディレクトリを渡しています。

バッチ書きたくないけど

マルチプラットフォームの場合、上記の辺りOSや環境依存する箇所を分岐処理で書くことになります。
(Mavenで可能)

プラグインがマルチプラットフォーム対応しているならそれを使えればベストです。
ただし扱いたいJDKとその時点でプラグインが扱えるJDKの対象バージョンに依存するため、最新JDKと格闘する場合プラグインが使えないかもしれないという矛盾があります。

バッチの場合、まだプラグインが対応していない時期でも動かせます。
この記事を書いている時点ではプラグインがファイナルアンサーとはならず、バッチなら確実にできるという状態でした。
最新を追う場合当てにしにくい部分なのでバッチがベターな時期があるはずです。

なぜMaven CentralのJarは使わないのか

成果物にはMaven CentralのJarではなくjmodを使っています、というお話です。
これは公開されているJavaFXのバージョンがCentral<SDKの場合、リリースノートを見て文法上問題なければSDKを利用してランタイムを作成するためです。

JavaFXのSDKはJava Platform, Standard Edition 11 Reference Implementationsで入手可能です。

Maven上のJavaFXのscopeをprovidedにできるようにしておくと、JavaFXの最新リリースに追随するためにSDKを併用するときには便利な場合があります。

WindowsのJavaFXのバイナリ作成は他OSより面倒と公言されています。
事実アーリーアクセス時代は必ずSDKのリリースが先行していて、centralでの公開は数日から数週遅れていました。
そのためJavaFXのコンパイルバージョンとリリースバージョンを別に扱えるようにしていました。
Java11以降もこういった傾向は続くかもしれませんし、開発元が作業に覚醒してタイムラグなしで双方リリースするかもしれません。
アーリーアクセス時代はSDKありきでした。

MavenとSDKでは使用するファイルがjarかjmodかの違いがあります。
(SDKはjimageで提供されるようになってくれるとパフォーマンス面で恩恵があるのですが)。
centralのjarはクロスプラットフォーム対応のため妙な参照をするmoduleなのでファイル数が多いですが、バージョンが同じであれば基本的にAPIは変わらないはずです。
licenseはどちらもGPL 2.0です

JREとアプリの配布を分けたい場合には、Mavenを使えばよいのではないかと思います。
アプリ実装のJavaFXをprovidedにしたい場合は、jmodを使えばよいのではないかと思います。
使い分けです(サーバでもあるある)。

ただJavaFXのライブラリがOS別に別れている以上、OS別になる再配布JREと切り離して管理する必要があるのかどうか、よくわかりません。
JREのリリースサイクルが早いのでJDKとJavaFXはセットでプラットフォームと考えてもよい気がします。
(オールインワンのアプリ作るときにJREとアプリの配布を分けたい場合があるだろうか。多分ない。OS依存となるランタイム作成時点で、OS依存となるJavaFXはJREの一部にしてしまってもよい気がしますけど?という話)

JavaFXがMavenで使えるようになって便利になりましたが、JavaFXをユーザLibに実配置するかどうかは別の話です。
最適解はケースによって分かれます。

jdk.management.agent

JREを作成するバッチ本体のjlink実行時に、追加モジュールとしてjdk.management.agentを指定しています。
最終成果物には必要ありませんが、exeから再配布用JREを使用して起動したJavaFXアプリに対してプロファイリングするのに必要です。

Launch4jを作成する際の設定XMLのoptの項目に、exe実行時の起動引数が指定してあります。
この中に-Dcom.sun.management.jmxremote が指定してあるため、起動時にJMXの待ち受けが自動で行われます。

eclipseやMavenからでも似たこと(似たこと)はできますが、最終アプリに近い状態でプロファイリングする場合ここに仕込むとよいです。

Java11 + JavaFXでeclipseの連携

この記事で扱っているようにjmodを使用してJava11+JavaFXのランタイムを作成しておくと、JavaFXをprovided扱いにしてeclipseからテスト起動できます。
(厳密にはpom側のスコープもprovided指定)

Run Configurationで、起動するアプリケーションの設定のJREを標準JDKではなく、自分が生成したランタイムに変更します。

eclipseのコンパイルは標準JDKとMaven Central経由のJavaFXや、使いたければJavaFXのプラグインを適当に。
(コードアシスト等を利用するためにeclipse上で自動コンパイルするための設定の話。ビルドはMavenありき)

あらかじめJava11とJavaFXを結合した(昔のような)マイJDKを作っておくという方法は。
一見開発環境の構築が楽になりそうな気がするのですが。
コンパイラにエクステンションして恒久使用するのは、比較的単騎(短期)ローカル開発向きです。
明確な理由がない限り、利点は少ないかもしれません。

以下のような点は問題になりやすいです。

  • せっかくJDKが軽くなったのに本末転倒
  • jmodのみの使用となりCentral経由の環境運用に難がある。MavenでJavaFXやJDKのバージョンを一次的に変更して検証したりしにくくなる
  • 更新の早い時期にJavaFXに追随する場合JDKのパターンをマトリクスで作成して使い分けることになる
    POM管理であれば検証、あるいはfixしてバージョン更新をすれば自動でダウンロードされ履歴として残る
    意味があり先人が進化させてきた管理方法を独自に旧世紀の方法に戻すメリットは(普通は)ない
  • 自分が開発したものではなく他者が開発した異なるJavaFXのバージョンのプロジェクトをIDE上で同時に読み込むというように、異なるバージョンが並列する状況で問題がある。JavaFXがモジュール化された以上想定される事態
  • 他のマシンへビルド環境を移行する状況や継続的インテグレーションを考慮すると障壁になる
    例えばtravisへ載せる場合、コンパイラ側に細工を入れる構成管理は若干歪なアプローチ
    JavaFXのSDKをDLしてパス通してキャッシュまで明示処理すればよいが(Maven使えば)不要。CIでJDKのマージは無駄

モジュール化されたJavaFXを再度JDKに統合する発想は、当然ながらモジュール化のメリットを享受しにくくします。
上記に上げたような点は、初心者ではない技術者が難色を示しやすく、いくつかの状況ではアウトです。

とはいえ、いつでもPOMを書くのが至高というわけではなく状況によります。

JDK+SDK

Maven経由でなくJDK+SDKで構成したコンパイラの使いどころは、IDEでの設定をさぼるときではなく。

必然性があるのは、文法レベルで大きく異なるバージョンがSDKでリリースされていてCentralでリリースされていないケースに対応する場合です。
メジャーバージョンが変わるくらい先行する状況ではSDKでないと不可能な場合があります。

またネットもMavenも使えない環境ではSDK主体になります。
これは基本開発キットであるSDKにとっては絶対にできなければならないことなので、本来基礎中の基礎の構成となります。

一方現代のJavaにとってネットとMavenは基礎以前の空気に相当します。
殊更JDK+SDK構成が入門編として適切とか有利ということもありません。

POMもCIも一般的ではなくアプデも遅かった大昔であれば、この構成がhowtoの入口足り得たのですが。
現代においては前節にあるような点がJDK+SDK構成のデメリットとなり共有や再現性で不利な為、真っ先に試すべき方法/ナリッジ集積していく方法としてはあまり向いていないかもしれません。

隔離環境/レガシー構成と言わずとも、Maven構成との違いを理解し特定目的で使用する環境になりつつあるかもしれません。

JDK+Maven+SDK

現状Mavenの公開が軌道に乗っているので、基本はPOMで管理をするのが順当かと思います。

最新のSDKがバグフィクスを含んでいるような場合にCentralにないバージョンでもSDKから取り込むという体制にするには、並行して最新のSDKでランタイムを作成できる方法も確保します。
つまりこの記事にあるようなMavenとSDKのハイブリッド型になります。

また配備上の理由で成果物にjmodを使用したい(ユーザlibにJavaFXのライブラリを置きたくない)場合はこの方法となります。
純粋にJDK+Mavenのみで構築する場合と、この点が異なります。

ランタイムにSDKを使用する場合、その部分のバージョン管理は基本的に手動になります。
開発中はCentralのライブラリをPOMで指定するのでフレキシブルですが、最低限、成果物のリリースタイミングでCentralとSDKのリリース状況を再確認することになります。
当然ですがバージョンの関係は、 「POM管理しているJavaFX」≦ 「SDKのJavaFX」 になります。

両方のおいしいとこどりをしましょう、というような曖昧に便利そうなアイデアを提示しているわけではなく。
考え方も使い方も基本はMaven寄りなのですが、フルにMavenを利用できない場合に弱点補完するならこのような使い方もあり得るという感じです。

JDK+Maven

Centralに公開されているバージョンしか使わない、というのであればSDKは使わずMavenだけでも用は足ります。
おそらく世に一番多いパターンで、構成管理が見かけ上最もスマートになり動作再現も管理もしやすいです。

一方で故あって「JDKとSDKのみを使用している」「JDKとSDKとMavenを使用している」ようなケースと異なり、Centralのライブラリバージョンのみが頼みの綱となります。

バージョン変動期は最新に追随しにくいですが、ポータビリティの高さやPOM管理の平易さを重視する場合に適した方法です。
そしてなんでもかんでも複雑になりがちなJavaでは、ほとんどの場合ポータビリティや平易さはとても重要なものとされます。

何事もなければこれ一本でよく、またそうありたいところです。
アーリーアクセス中はそうでなかったですが、しばらくすると落ち着くと思います。
長期的に見たときにJavaFXがどのようなサイクルでバージョンアップしていくか。
今は誰にも分かりません。

どれがよいか

CentralとSDKのJavaFXリリースバージョンのラインナップ(つまり時期)にもよるのですが。
初動から開発/ビルド/CI管理等、工程をトータルで見るとSDKではなくMaven主体の管理が合理的です。
Mavenはそのために存在するツールであり、module化されたJavaFXはMavenとの親和性が高くなっています。

OSやバージョンについてより厳密なランタイムが必要な場合では、packageのフェーズに限りjmodを利用する方法が一案。
(jmodを開発環境のJDKに組み込むのと成果物のJREに組み込むのでは意味が異なる)

私のPOMの例でいえば、以下のコマンドではMaven CentralのJavaFXを使用します。
IDEからコンパイルしたり、UTまでCIに載せたりということが簡単にできます。

パッケージングではjmodも使用します。
この工程はビルドマシン上で行う想定。

以下の順番を意識すると、全体としては妥当性がある構成や環境構築になりやすい傾向があると思います。
各ツール群の依存関係がそうなっているので、考慮しなければならない仕様の優先度もその順番になっています。

  1. 最終成果物の定義をする(OS/ランタイムの構成等含む)
  2. JDKのパッケージング方法を選ぶ(Java11 + JavaFXでは必須工程。構成によってはjmodのJavaFXを使用)
  3. パッケージングから逆算してPOMの設定方法を選ぶ(JavaFXがPOMに入ったり入らなかったりscopeが変わったり)
  4. そのPOMに適したIDEの環境設定を選ぶ(普通はPOMから引っ張ってくるがそうでない場合色々な方法が)
  5. ソースコードを書く

初心者本はいきなりIDEの構築から話が始まりやすいです。
それらに比べると、ここに挙げたリストの順序は一見逆張りのように見えるのですが。
昨今の文書は必要以上に商業化されキャッチーであることを求められるため、体系的視点を欠く場合があるだけです。

通常、設計開発では成果物定義を最初の方に行います。
(国内外問わずWeb上でもデキるヤツはMavenビルド辺りから話を始める。Java11 + JavaFXは成果物が旧来とは異なる故)

パッケージングによってはPOMの書き方が変わる可能性があり、またPOMが変わればIDEの設定も変わる可能性があります。
成果物がどのようなものかという条件により、その後のやり方がある程度決定されます。
これは因果であり、関係性が逆転することはありません。

というわけで「作りたいものによって過程は変わる、逆はない」という初心者が困惑しそうな答えですが。
困らせるために長文を書いているわけではなく。

長期的に考えると一般的なJava使いにとって必須知識とされるMavenについて学んでから着手するとスムーズです。
重要度順に学ぶのが結局は着実最速ですし、より重要な知識を差し置いてJavaFXを触っても得るものは少ないかもしれません。

実行例1

作成したアプリをランチャーのダブルクリックで起動し、visualvmも起動します。

visualvmのApplicationsに、作成したアプリが表示されています。

JMXで接続されているのでスレッドの中身が見れるはずです。
外枠だけのアプリですが、スレッドプールを持つInvokerは既に使っているので標準以外の名称付きスレッドも確認できます。

Tool > Plugins からプラグインを簡単にインストールできます。
Visual GCは必須だと思います。

Visual GCの画面。
これがないとチューニングができません。

実行例2

取り急ぎスレッドとメモリとオブジェクトが見れればOKですが、アプリケーションのデバッグ時にコンソール(ログ)があると便利です。
これをJMX経由で行う方法もあるようですが、少し調べてみたところ設定が面倒そうでバージョンによっても変わるようです。

それはいずれやっつけるとして、ここではもっとお手軽簡単な方法を。
exec-maven-pluginを使ってMavenから実行し、Mavenを使っているコンソールにログ出力をする方法です。

exec-maven-pluginの設定記述を抜粋。
(起動オプションはまだテキトーなので参考になりません。JDK11 のチューニングフラグというフォローアップ記事があります。)

Mavenが使っているJDKではなく、配備用に作成したJREで起動する設定です。

この状態でexecします。
Mavenとは別にアプリケーションスレッドがspawnされます。

ただしこの方法ではMavenの稼働環境を引き継いでしまうと、ドキュメントに書いてあります。
eclipseからの起動も似たようなものでしょう多分。
やろうとしていることはヤッター動いたのその先にあることですので、ここは注視する必要があります。

プロファイリングは実環境である実行例1を主として、簡易的補佐的にログ出力したい時があるという場合はこのような方法を併用するとよいかもしれません。
(やりませんがITを自動化するのであれば当然、成果物を実行例1の形で起動した延長であるべき)

すごくちゃんとするにはvisualvm側にプラグインがあるので、JMX経由でそちらに出すことになります。
そこまでして必要かというと個人的にはクライアント開発時はそれほど重要でなかったりします。
クライアントのコンソールはこのような騙し騙しな方法で対処できてしまうことも多いです。

(パッと探して見つからなかったのでJDK11でJMXのコンソールプラグインの稼働事例があるかわかりませんでした。
この記事を書いているのはvisualvmとlaunch4jがJava11対応した直後です。この記事に書いてあるようなことができないなーできないなー・・・できるようになった!のタイミングで書いています。)

ローカルではなくリモートサーバのコンソールを再現するとなると、コンソールプラグインは俄然必須機能になります。
(ですので動くようになっていて私が知らないだけか、もしくは今動かなくてもそのうち確実に対応される高ニーズ機能なので、少し落ち着いてから触るでもよいかなという私見)

コメントはまだありません

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

Javafx
JDK11 + JavaFXでイベントドリブン 2018

JDK11 + JavaFX でイベントやアクション周りを自作する例です。内容は中級者向けです。

Javafx
JavaFXで疎結合な画面遷移(イベントドリブン方式)

コントローラ間で画面移動のパラメータ制御を行い、画面が画面をuseしない疎結合を実現する方法です。