jlinkのオプション指定でカスタムJREのサイズ削減 はじめに 先週のJava読書会BOF主催「The Java Module System」を読む会（第10回）では、jlinkコマンドで実行イメージを生成する章を主に読みました。 そこには、生成する実行イメージのサイズを小さくする幾つかのオプションが紹介されていました。 そこで、オプションを指定するとどれだけ実行イメージが小さくなるのか、手元の環境で確認しました。 確認環境 項目 内容 OS Windows 10 Pro 1909 64bit 日本語版 JDK Liberica JDK 14.0.2 full 64bit版 確認結果 サイズ削減に関するオプション指定のないデフォルトでの実行イメージ生成のコマンドラインが次です。 （実行イメージには、java.baseモジュールだけを含む指定） D:\work> jlink --add-m

さくらVPSのOSをCentOS 8に、Redmineを4.1に更新、の続き（5日目） 既に対処が終わっている内容ですが、以下の続きです。 torutk.hatenablog.jp MariaDBの文字コードを、utf8mb4に設定しました。これはUTF-8で1～4バイトの範囲を扱える設定です。一方、MariaDBで文字コードをutf8とした場合は、UTF-8で1～3バイトの範囲（基本プレーン）しか扱えません。utf8のデータベースに、例えばUTF-8で4バイトで表現される絵文字をWikiに記載し保存しようとするとエラーとなってしまいます。 ここで、今回の更新で起きた問題は、RedmineのこれまでのデータベースはMySQLのutf8で作成したものを移行してきたことに起因するものです。具体的には、新たにMariaDBの文字コードをutf8mb4に設定してもデータベース（テーブル）はutf8

さくらVPSのOSをCentOS 8に、Redmineを4.1に更新、の続きの続き 昨日の作業の続きです。 torutk.hatenablog.jp Let's Encrypt の証明書更新 証明書更新の処理確認（エラー対処） 証明書を更新するスクリプトの実行確認（dry-run）をします。 # certbot-auto renew --dry-run : Challenge failed for domain www.torutk.com http-01 challenge for www.torutk.com Cleaning up challenges Attempting to renew cert (www.torutk.com) from /etc/letsencrypt/renewal/www.torutk.com.conf produced an unexpected er

さくらVPSのOSをCentOS 8に、Redmineを4.1に更新、の続き 昨日の作業の続きです。 torutk.hatenablog.jp Unicornのセットアップ Unicorn gemのインストール Unicornはrubyモジュール（gem）として提供されるので、bundlerでインストールします。 Redmineをインストールしたディレクトリ下（例：/var/lib/redmine-4.1-stable）に、Gemfile.localというファイルを作成し、そこに以下を記述します。 gem "unicorn" Redmineをインストールしたディレクトリで bundle update を実行します。 $ cd /var/lib/redmine-4.1-stable $ bundle update : Installing kgio 2.11.3 with native ex

さくらVPSのOSをCentOS 8に、Redmineを4.1に更新 まとまった休みが取れたので、さくらVPSのサーバーのOSをCentOS 7から8に上げて、合わせてRedmineを3.4から4.1に上げる作業を実施しています。更新作業中はRedmineにコンテンツを挙げられないので、はてなに経過をメモすることにします。 CentOS 8への更新 さくらVPSが提供するOSインストール機能で、CentOS 8に上げます。さくらVPSサーバのバージョンはv3なので、標準OSのインストールではCentOS 8は選べません。カスタムOSのインストールでCentOS 8を入れます。 パーティションの設定 仮想ゲストでディスク（イメージファイル）を増やすこともないので、LVMは使用せず、/boot はext4、/はxfs、それとswapの3つのパーティションを作成しました。 マウントポイント 容量

はじめに JDK 10までは、JavaFXアプリケーションを配布する際に、ネイティブ・インストーラー形式にするjavapackager機能を使ってOS固有のインストーラーを作成することができました。Windowsネイティブなインストーラーを作成する際には、外部ツールとしてWiX Toolsetを使ってMSI形式のインストーラーを作成するか、同じく外部ツールとしてInnoSetupを使ってEXE形式のインストーラーを作成することができました。 しかし、JDK 11ではJavaFXとともにjavapackager機能が分離したため、JDK11上でのJavaFXアプリケーションは独自にインストーラーを作成することになります。 今回は、次のJavaFXアプリケーションをWindows OS上へインストールするMSI形式のインストーラーを作成していきます。gitのブランチは、jdk11 となります。

発生した事象 IntelliJ IDEA で作成していたJavaFXアプリケーションがあります。ビルド成果物でJARを作成し、Main Classを指定すると、実行可能JARファイルが生成されます。 このアプリケーションのプロジェクトにmodule-info.javaを追加してJava Module System対応をしました。ビルドでJARファイルを生成し、そのJARファイルをコマンドラインから実行すると、−ｍオプションに明示的にmain classを指定しないとエラーとなってしまいます。実行可能JAR（-jarオプション）としての実行はできているのですが・・・ D:\work\myapp> java -p out\artifacts\myapp_jar -m com.torutk.myapp モジュールcom.torutk.myappにModuleMainClass属性がありません。-

ソフトウェア開発環境が含む範囲 本記事は、製品としてソフトウェアを作る場合で、複数の開発者が共同して作業する、企業でのビジネスを想定しています。プログラミング言語は、コンパイラ型でオブジェクト指向プログラミング機能を想定しています。 逆に、サービスの提供が目的でソフトウェア自体が製品ではない場合、開発規模が小さい（ごく少人数の開発で阿吽の呼吸が通じる）場合、既にある製品やサービスを活用し、ちょっとしたアドオンやカスタマイズで実現する場合、などは本記事の想定外となります。 開発環境と一言でいうとどこまでを含むのか ソフトウェアの開発環境を整備しようとしたら、何を含めるのかについて同じ職場でもコンセンサスがなかなか得られていません。そんなときは両極端な思考をしてみて検討の幅を持たせて適切なところを探ります。 最小限の開発環境 まず、片方の極端な思考として、もっとも少ない開発環境を考えます。ミニ

Java読書会「The Java Module System」を読む会（第1～3回）のまとめ（その２） torutk.hatenablog.jp の続きです。 第２章　Anatomy of a modular application モジュール化したアプリケーションのディレクトリ構成の例 +- libs　　　　（サードパーティの依存物） +- mods　　　　（コンパイル＆パッケージ化したモジュール） +- monitor 　　（アプリケーションモジュールの１つ） | +- src | | +- main | | +- java　　（モジュールのソースコードを含む） | | +- monitor | | +- module-info.java　　（モジュールの宣言） | +- target | +- classes　　　　　　　　　（モジュールのコンパイル結果を格納） +- monitor

前提 ソフトウェア開発環境がインターネットと隔離されていることは、昨今のセキュリティ事情からよくあることと思います*1。 ソフトウェアエンジニアの場合、事務作業で使うPC環境とは別にソフトウェア開発用のPC環境があり、それは事務作業で使うネットワーク環境とは異なるソフトウェア開発のネットワーク環境につながっており、インターネットとはつながらない（あるいは強度な制約のもとインターネットにつながる）環境となります。 例えば、事務作業用のPCと開発用のPCが物理的に分かれていて、それぞれ別々なネットワークに接続されていることや、事務作業用PCの利用は仮想マシンを通して行い、開発用PCと仮想マシン間のデータ交換は不可となっていることなどです。 開発したソフトウェアを組み込む製品と開発環境をつないで、ソフトウェアのインストール・更新、ログの取得、デバッグ、各種設定をする際は、製品が開発用ネットワーク

「Java 11 and 12 New Features」（洋書）を読む会を開催 昨日6月15日（土）に、Java読書会BOFは書籍「Java 11 and 12 - New Features」を読む会（第1回）を開催しました。 あいにくの雨模様でしたが、10名を超える参加者が集まりました。Javaの最新技術、といっても2年前の2017年にリリースされたJava SE９からの技術を解説した日本語の書籍が皆無で、洋書の選択となりました。 Java読書会BOFが開催する読書会では、書籍を本文、脚注、ソースコードとすべてを朗読して進めています。今回は洋書なので、どう進めようか？と思いましたが、英語のままで朗読して進めてみることとしました。 書籍の入手に関して Amazonのサイトには、紙の書籍とKindle電子書籍版があり、紙版も2日程度で入手可能となっています。また、洋書の出版社Packt P

今月のはてな日記は2日しか書けていないということに衝撃を受けて、思い出しながら書ける内容で盛ってみます。 今月3日に日本Javaユーザーグループ（JJUG：Japan Java User Group）主催のカンファレンス（CCC：Cross Community Conference）で、JavaFXで地図を描くというセッションに登壇しました。JJUG CCCは、公募のセッションとスポンサーセッションから構成されているようです。9月頃に2つのテーマで公募し、そのうち1つが採択され、登壇することとなりました。もう1つのテーマはJava読書会BOFで読んできた書籍一気通貫紹介だったのですが、こちらは非採択でした。 公募の動機 Javaといえば、OSの縛りを超えて動くプログラムを作ることができる言語で、しかもGUIを標準で持っています。ですから、作ったGUIプログラムがWindows、Linuxな

JavaFX Advent Calendar 12月3日担当です。 11/30開催の「第8回JavaFX勉強会」（日本JavaFXユーザーグループ主催）で、「ダブルクリックで起動する JavaFX アプリケーション JAR の仕組み 」を発表をしてきました。 この発表では、作成するプログラムがJava SE／JavaFX以外の他のJARに依存しない単純な形式を対象にしていました。 発表の質疑応答にて、依存するJARがあり複数のJARで構成されるアプリケーションの場合について質問を受けました。事前に調査はできておらず、宿題ということで本日「（補遺）依存するJARがあるJavaFXアプリケーションの実行可能JAR作成」を紹介します。 注記）本記事でのコマンド実行例、ディレクトリパス記述表記は、Windows OS（Windows 7）環境での操作・記述を前提としています。Linux、Solar

はじめに 先月5月20日（土）に、JJUG CCC 2017 Springで「JavaFXでデスクトップガジェット風プログラムを作る」のセッションを行いました。 セッションのスライドは次です。 https://www.slideshare.net/torutk/jjugccc2017spring-m6-javafx このセッションでは、デスクトップガジェット風プログラムに実装するガジェットに共通する次の振る舞いを紹介しました。 ウィンドウ枠の非表示、背景の非表示（透明ウィンドウ） ウィンドウの位置をマウスドラッグで移動 ウィンドウの大きさをマウスホイール（＋Ctrlキー）で変更 ポップアップメニューから終了 ウィンドウの位置と大きさを終了時に保存し、次回起動時にその値に復元 これらの振る舞いを、JavaFXアプリケーションに持たせるには、それなりのコード量を記述する必要があります。 ガジェ

先月開催のJJUG CCC 2017 Springの「JavaFXでデスクトップガジェット風プログラムを作る」セッションで、透明ウィンドウ化とそれに伴うウィンドウの移動・大きさ変更・閉じる・などの振る舞いの実装を紹介しました。 複数のガジェット風プログラムを作るとき、こうした振る舞いを都度コピーペーストするのもいただけないので、別クラスに切り出して利用するようにしました。 このパッケージ名をどうしようかな？ と考えていた時に見つけたブログが次でした。 Util Packages Are Evil : Adam Bien's Weblog commonは以前から避けるべき命名と認識していましたが、base、modelは使ったことがあるのでちょっとグサッと・・・ ここでの根拠は「un-cohesive」（凝集度の低下）をもたらすということです。比喩で「Kitchen-sink」に至ると書かれて

はじめに システムがカットオーバーされると、それまで運用してきた旧システムは撤去することとなります（基幹系では新システムがトラブルになった場合の備えとして残しておくことがあるかもしれません）。情報システム関連の仕事には、この旧システムの撤去もあります。サーバーを収容するラックは耐震上がっちり設置されているので、これを取り外して普通の床面に戻すのは工事が必要で、取り外したものを運び出すには運送が必要です。このような作業はITエンジニアでは行えないので、それぞれ施工会社や輸送会社などにお願いすることとなります。そのためには見積もり、手配、現地の下調べなどのお仕事があります。 先々月に異動になった部署では、カットオーバーする新システムのインフラストラクチャーの見積もり、手配、据え付けなどを行うのですが、それに伴う旧システムの撤去も扱っていたのです。 というところで、ここしばらくこの見積もりのため

ときおり、PDF文書から任意のページを切り出したいということがあります。PDF文書を扱うのはAcrobat（≠Acrobat Reader）を購入するのが一番でしょうし、フリーのツールも多々存在しますが、ここはJavaでツールを作成してみたいと思います。 まず、第一歩としてPDF文書をページ単位でJavaで表示するPDFのビューアーを作成し、次にページを指定して切り出す機能を付けるという段階で進めていこうと考えました。 JavaからPDFを扱うオープンソースライブラリとしては、昔からの定番のiTextと、ApacheのPDFBoxが著名でしょうか。ぐぐっていると次のまとめページがありました。このページは分かりやすいです。 今どきのJavaのPDFライブラリ まとめ (2014年版) | WEB ARCH LABO iTextは商用ライセンスとAffero GPLのデュアルライセンスです。A