torutkのブログ

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

オンライン勉強会2件の一部聴講メモ

redmine.tokyo勉強会とJJUG CCC 2021 Spring オンラインが開催

5月下旬の週末に、RedmineのオンラインイベントとJavaのオンラインイベントが続けて開催されました。

土日に自宅で部屋に閉じこもってべったり聴講というのはなかなか難しく（それなりに家事等があり）、一部聴講し、他の興味ある部分は後日Youtubeに録画がアップされてから聴講ということになってしまいました。

Redmine と Java

Redmine

Redmineは、バグ等の追跡管理や作業タスクの管理等をチケットベースで行う管理ツールです。 Redmine自体はオープンソースで開発され、無償提供されている他、いくつかの企業からクラウド上で有償のサービスが提供されています。

Redmineの登場は2006年*1のようです。その頃は、Trac、Mantis、影舞、Bugzillaなどのオープンソースツールや有償の製品がいくつもひしめき合っていました。

個人的にはバグ等の障害管理だけでなくWikiや掲示板も統合され、Redmineインスタンス1つで複数プロジェクトの管理ができる汎用性の高さがよいと思っています。2009年頃から使い始めて今に至っています。

Java

Javaはプログラミング言語と実行環境で、オブジェクト指向プログラミングを主とした言語仕様と仮想マシンによるプラットフォーム非依存な実行環境を持っています。当時はオープンソースではありませんが、開発キットと実行環境が無償で提供されました。

Javaの登場は、1995年にα版、β版が公開、翌1996年1月に正式版（1.0）が公開されました。

標準APIでマルチスレッド、TCP/IPネットワーク、GUIの機能を持ち、デスクトップからサーバー上のプログラムまで、OSが違っても同一バイナリ（バイトコード）のプログラムを実行することができる汎用性（適用範囲の広さ）を持っています。

1996年にJDK 1.0.2を当時自宅PC（漢字Talk 7.5：古いMacOS 7.5の日本語版）で、Webブラウザ上で動かすアプレットやスタンドアロンプログラムを作ったり、職場の実験室等にあったSolarisマシンやWindows NT 3.5マシンでプログラムを作ったりしました*2。

redmine.tokyo第20回勉強会

オンライン（ライブ）は、中盤のLTの途中から聴講でした。翌日には録画がアップされていましたので、聴講しました。 既に勉強会ページには動画、資料のリンクが貼られています。

Redmine 4.2新機能評価ガイド

Redmine 4.2新機能の紹介、地道に機能が追加・改善されています。 便利そうな機能

LT

プラグインを作りました、の紹介がいくつかあってよいです。

背景地図を取り込んで地理情報を可視化できるのは興味深いですが、セットアップがちょっと大変そう。

JJUG CCC 2021 Spring

午後から聴講開始、動画はライブですが遡って午前のモノを見ることもできたので休憩時間のときに飛ばし見をしました。オンラインだとザッピングのようにあちこちつまみ食いしてしまい、集中して聴くことがなかなか難しいです。

セッション動画

eclipseユーザのためのVSCodeのススメ

資料

最近、VSCodeでJavaプログラミングをするという、えっ、なぜIDE使わないの？という風潮があるので実際どうなのだろうとちょっと覗いてみました。 細かなところは実際触ってみないと分かりませんが、そこそこ使えるように感じました。

今どき？のJavaにおける例外処理についての考察

Spring frameworkではインフラ層のエラーを非検査例外（Runtime Exception）で飛ばし、AOPやインターセプタで非検査例外を補足して一元的に対応するという仕組みを前提として、アプリケーション層、ドメイン層のJavaコードを書くときなら検査例外はいらない。業務上のエラーは例外ではなく戻り値で扱う。戻り値はエラー状態を含む型（interface）で、という内容でした。

Spring frameworkでもなく、Webアプリケーションでもない分野でのJavaプログラミングをずっとしていたので、この前提のプログラミングはしてきませんでした。ただ、よく「Javaの検査例外は悪」といった意見を見ますのでその背景がこのような前提だろうということが分かります。

ソフトウェアアーキテクチャの選び方

動画

レイヤードアーキテクチャは、ドメインがより下層のインフラに依存するという課題から、ヘキサゴナルアーキテクチャやオニオンアーキテクチャ、クリーンアーキテクチャといったドメイン駆動等で提唱されるモデルで、ドメインが他の関心事のレイヤに依存を持たない構造を取る解説をふわっと流れるような動画で紹介していました。 後半の事例紹介は、開発メンバーの素養や開発プロジェクトの条件に応じてアーキテクチャを選定するという点が興味深いです。

オンライン広告入札システムとZCC

資料

G1GCと比べたときのZGCで、GCによる最長停止時間は相当短く抑えることができますが、GC頻度は増大する、というのがざっとの理解です。細かい使い方等は飛ばし見なので把握せず。 GCのパラメータは膨大なのでどの組み合わせが最適かを機械的に探索し、可視化評価する例が紹介されています。これはすごい。

  • パラメータ値の自動錯誤を自動化、よい値を発見するOptunaツール（Python製）
  • GCログの解析サービス利用（GCeasy）
JFRなどのツールを用いてFullGCやOOMEの原因を特定する流れ

資料

JFRで実行状況をファイルに出力し、JMCで解析。アプリケーションの動作状況を把握。

  • GC Viewerツール。元の開発会社による開発が停止後（2008年）、個人がメンテナンス継続
Plug-in Architectures with the Java Module System
How Should Java Developers Build Front-Ends Today?
スポンサーブース、アンカンファレンス

スポンサーブース、アンカンファレンスへの行き方が分からずたどり着けませんでした。リンクを辿ると、アカウント作成？をしたあと、デバイス（ビデオ、マイク）が接続されていないとエラーに。ヘッドフォンをヘッドセットに交換したけれど変わらず（PC再起動まではしませんでした）。

*1:https://www.slideshare.net/g_maeda/redmine9

*2:職場の事務所で個人に割当てられたPCはWindows 95で32bit対応していないためJavaが動かなかった

Gradle 7.0 とJavaモジュールシステム

Gradle 7.0 のリリース

2021年4月に Gradle 7.0 がリリースされました。

https://docs.gradle.org/7.0/release-notes.html

この3月にリリースされたJDK 16に対応したほか、Javaモジュールシステム対応が正式機能に昇格しました。Javaモジュールシステム対応は、バージョン6.4（2020年5月リリース）で試験的に導入されましたが、バージョン7.0で正式機能になりました。

これを機に、次を試してみました。

  • Javaモジュールシステムを使用したJavaアプリケーションのビルド
  • ビルド設定を Kotlin で記述
  • gradle init で雛形を生成せずにゼロから設定を記述
  • インターネット非接続での使用
  • JavaFX のライブラリをローカルにインストールして参照

環境の構築

動作環境は次です。

項目 内容
OS Windows 10 Pro 64bit　日本語
JDK Oracle JDK 16.0.1 *1
Gradle Gradle 7.0
JavaFX JavaFX 16

Gradle 7.0 のセットアップ

Gradleのダウンロードページから、Gradle v7.0のバイナリ（binary-only）をダウンロードします。

https://gradle.org/releases/

C:\Program Files\Java フォルダの下に上述で入手したバイナリを解凍し展開します。

C:\Program Files\Java\gradle-7.0

ディレクトリのシンボリックリンク C:\Program Files\Java\gradle を作成します。gradleを複数バージョン抱える際に、環境変数PATH設定をいじらずにシンボリックリンクの変更で切替えています。

C:\Program Files\Java> mklink /D gradle gradle-7.0

環境変数PATHに、C:\Program Files\Java\gradle\bin を追加します。

gradleの実行確認です。

C:\> gradle -version

------------------------------------------------------------
Gradle 7.0
------------------------------------------------------------

Build time:   2021-04-09 22:27:31 UTC
Revision:     d5661e3f0e07a8caff705f1badf79fb5df8022c4

Kotlin:       1.4.31
Groovy:       3.0.7
Ant:          Apache Ant(TM) version 1.10.9 compiled on September 27 2020
JVM:          16.0.1 (Oracle Corporation 16.0.1+9-24)
OS:           Windows 10 10.0 amd64

Javaモジュールシステムで動く Hello アプリケーション

まずは、素のJavaでコマンドラインから動くHello Worldアプリケーションを Gradle でビルド・実行します。

プロジェクトディレクトリの作成とビルドスクリプト記述

プロジェクトディレクトリを作成します。

D:\work> mkdir hello_app
D:\work> cd hello_app
D:\work\hello_app>

ビルドスクリプトを記述します。Kotlin で記述する場合、build.gradle.kts というファイル名で作成します。

plugins {
    application
}

application {
    mainModule.set("com.torutk.hello.app")
    mainClass.set("com.torutk.hello.Main")
}
  • Javaの実行可能プログラムを作成する application プラグイン（Gradleに標準搭載のコアプラグインの一つ）を指定
  • Javaモジュールシステムで実行可能モジュールを設定（モジュール名 com.torutk.hello.app）
  • プログラムのエントリポイントとなるクラスを設定（クラス名 com.torutk.hello.Main）

ソースファイルのディレクトリを構成します。 Gradleのjavaプラグインは、デフォルトでソースファイルがsrc\main\javaディレクトリ下にパッケージ階層に対応して置かれているものとして扱います。

D:\work\hello_app
  +-- build.gradle.kts
  +-- src
        +-- main
              +-- java
                    +-- module-info.java
                    +-- com
                           +-- torutk
                                 +-- hello
                                       +-- Main.java

モジュール定義とプログラム作成

module-info.java

モジュール定義ファイルを記述します。

module com.torutk.hello.app {
}

単純なHelloプログラムなのでデフォルトで使用するモジュールjava.base以外に必要な依存性はないので、モジュール名のみ定義します。

Main.java

コマンドラインから実行し、標準出力にメッセージを出力するだけの簡単なクラス（メインクラス）を記述します。

package com.torutk.hello;

public class Main {
    public static void main(String[] args) {
    System.out.println("Hello, JPMS World, powered by Gradle!");
    }
}

ビルド

D:\work\hello_app> gradle jar
  :

ビルド結果は、build\libsディレクトリにhello_app.jarとして生成されます。

プログラムの実行

Gradleのrunタスクで実行
D:\work\hello_app> gradle run
> Task :run
Hello, JPMS World, powered by Gradle!

BUILD SUCCESSFUL in 1s
3 actionable tasks: 1 executed, 2 up-to-date
コマンドラインから実行
D:\work\hello_app> java -p build\libs -m com.torutk.hello.app

Hello, JPMS World, powered by Gradle!

実行可能モジュールJARファイルが置かれている build\libs ディレクトリを、--module-path（-p）オプションで指定し、実行可能モジュール名を -m オプションで指定してプログラムを実行します。

Javaモジュールシステムで動くJavaFXアプリケーション

JavaFXは、JDK 11以降JDKから分離され独立したライブラリとして提供されています。とはいえ、Liberica JDKやZulu JDKなどJavaFXを同梱しているOpenJDKディストリビューションもあります。

しかし、今回は外部ライブラリをJavaモジュールシステムで組み込み利用するGradleのビルドを行います。そこで、JavaFXが同梱されていないOracle JDK 16にJavaFX 16を組み合わせることとします。

JavaFX 16の環境を準備

JavaFXのリリース提供サイトから、JavaFX SDKをダウンロードします。各OS毎に提供されているので、Windows用をダウンロードします。 https://gluonhq.com/products/javafx/

ダウンロードしたSDKを展開します。今回は、C:\Program Files\Java\JavaFX の下に展開します。

C:\Program Files\Java\JavaFX\javafx-sdk-16

モジュール定義とプログラム作成

module-info.java

JavaFXのライブラリを使用するので、モジュール定義に追記します。

module com.torutk.hello.app {
    requires javafx.graphics;
    opens com.torutk.hello to javafx.graphics;
}
Main.java

JavaFXアプリケーション（空のウィンドウにタイトル文字列を設定）

package com.torutk.hello;

import javafx.application.Application;
import javafx.stage.Stage;

public class Main extends Application {

    @Override
    public void start(Stage primaryStage) {
    primaryStage.setTitle("Hello, JPMS JavaFX World!");
    primaryStage.show();
    }
}

ビルドスクリプト記述

JavaFXのライブラリを参照する設定を追記します。

fileTree で絶対パス指定
plugins {
    application
}

application {
    mainModule.set("com.torutk.hello.app")
    mainClass.set("com.torutk.hello.Main")
}

dependencies {
    implementation(fileTree("C:/Program Files/Java/JavaFX/javafx-sdk-16/lib"))
}

dependencies の定義に、fileTreeでJavaFXのjarファイル群があるフォルダを指定します。 この記述は、どのjarファイルを参照しているかまでは記述していません。

flatDir で絶対パス指定＋JARファイル指定
plugins {
    application
}

application {
    mainModule.set("com.torutk.hello.app")
    mainClass.set("com.torutk.hello.Main")
}

repositories {
    flatDir {
    dirs("C:/Program Files/Java/JavaFX/javafx-sdk-16/lib")
    }
}

dependencies {
    implementation("javafx:javafx.graphics")
    implementation("javafx:javafx.base")
}

repositoriesの定義にJavaFXのjarファイル群があるフォルダを指定します。 dependenciesでimplementationに使用するJARファイルを指定します。 ここでは、直接使用するJARの他に間接的に使用するJARも指定します。

絶対パスの記述をプロパティに追い出す

ビルドスクリプトに絶対パス記述をすると、他のマシン間での共有が難しいので（例えばWindowsの絶対パスはUnixと異なる）、プロパティに追い出します。

gradle.properties に絶対パスを定義

gradle.propertiesにJavaFXのディレクトリを記述します。 gradle.propertiesは、ユーザーホームの.gradleディレクトリ下あるいはプロジェクトディレクトリに配置されます。 ユーザーホームはWindowsの場合、%USERPROFILE% となります。

javafx16 = C:/Program Files/Java/JavaFX/javafx-sdk-16/lib
build.gradle.kts でプロパティを参照
plugins {
    application
}

application {
    mainModule.set("com.torutk.hello.app")
    mainClass.set("com.torutk.hello.Main")
}

val javafx16: String by project

repositories {
    flatDir {
    dirs("$javafx16")
    }
}

dependencies {
    implementation("javafx:javafx.graphics")
    implementation("javafx:javafx.base")
}

ビルドスクリプト（Kotlin）では、gradle.propertiesに定義したプロパティを参照する場合、

val javafx16: String by project

とプロパティを委譲で定義します。 プロパティがないと、エラーとなります（次のエラーメッセージ）。

* What went wrong:
Cannot get non-null property 'javafx16' on root project 'hello_app' as it does not exist

プログラムの実行

Gradleのrunタスクでの実行
D:\work\hello_app> gradle run
コマンドラインでの実行
D:\work\hello_app> java -p build\libs;"C:\Program Files\Java\JavaFX\javafx-sdk-16\lib" -m com.torutk.hello.app

その他

ソースファイルをUTF-8とする場合

Gradleは、（というよりjavacコマンドは）ソースファイルがデフォルトエンコーディング（Windows 10日本語版ならWindows-31j）で記述されていることを前提とします。 そのため、UTF-8で記述されたソースファイルをWindows上でビルドすると、ソースファイルのリテラル等に記述されたUTF-8マルチバイト文字コードがエラーとなります。

そのときは、ビルドスクリプトに次の記述を追記します。

tasks.withType<JavaCompile>() {
    options.encoding = "UTF-8"
}

Windowsでネットワークドライブ切断時のエラー

Windows上でgradle 7.0を使用するとき、ネットワークドライブを割当てており、その接続が切断されているとエラーになります。

gradle 7.0.1で修正される予定です。

*1:OTNライセンスの下での使用

Scene Builder 16 リリースと日本語文字化け解消

JavaFX GUIデザインツール Scene Builder 16リリース

JavaのモダンなGUIライブラリ JavaFX のデザインツール Scene Builder 16が3月末にリリースされました。

gluonhq.com

Scene Builder は、JavaFX GUIライブラリの画面レイアウトを作成するツールです。ドラッグ＆ドロップで部品を配置しプレビュー表示が可能です。Javaのコードを書く必要がなく、設定はXMLファイルとして生成されます。

元々はOracleがJavaFXの支援ツールとして開発していましたが、オープンソース化され、現在はGluon社が開発をサポートしています。

日本語環境での文字化け問題

Scene Builder のバージョン10の頃から、日本語環境で実行すると文字化けが発生する問題が生じました。

github.com

Scene Builderのメニューなどで日本語表示されるべき文字が、別の記号等に文字化けしています。

たとえば、メニュー項目の「ファイル」が、「ファイル」と本来とは別の文字・記号で表示されています。

文字化けの原因の推察

リリースされたScene Builderに含まれるリソースバンドルの日本語プロパティファイルを調べると、native2asciiでユニコードエスケープされています。このプロパティファイルの中でメニュー項目の「ファイル」の「フ」に該当する箇所のユニコードエスケープ表記を見ると、「\u00e3\u0192\u2022」となっています。文字にすると「フ」になります。本来「フ」に該当するユニコードエスケープ表記は「\u30d5」です。

Scene Builderのソースコードリポジトリに登録されている日本語プロパティファイルはUTF-8符号化で記述されています。ユニコードエスケープ（native2ascii）されてはいません。ということは、ビルドの過程でUTF-8符号化のプロパティファイルがユニコードスケープ（native2ascii）され、その際に文字化けが生じているものと推察しました。

文字化けが生じるビルド過程

Scene BuilderのビルドにはGradleツールが使われています。 Gradleのビルド定義（app/build.gradleファイル）を調べるとプロパティファイルを処理している個所は次の通りです。

processResources {
    def buildDate = new Date().format(buildDateFormat)
    from ('src/main/resources') {
        include '**/*.properties'
        expand([
            version: version,
            javaVersion: System.getProperty('java.runtime.version') + ', ' + System.getProperty('java.vendor'),
            buildDate: buildDate
        ])
        filter(EscapeUnicode)
    }
    into buildDir
}

この中で、次の記述がユニコードエスケープを実施している個所です。

filter(EscapeUnicode)

文字化けの再現に挑戦

問題の解決にはまず事象の再現が基本となります。そこで、この文字化けの再現を試みます。 Windows 10 日本語版の上で Scene Builder のソースコード一式を展開し、gradleでビルドしたところ、日本語プロパティファイルは文字化けとなったものの、リリースされているScene Builderの文字化けとは異なるものとなりました。

「ファイル」はユニコードエスケープでは次のコードに化けています。

\u7e5d\u8f14\u3043\u7e67\uff64\u7e5d\uff6b

文字にすると次です。

繝輔ぃ繧､繝ｫ

ということで、単純には再現できませんでした。再現には、Gradleの振る舞いを理解する必要があります。

UTF-8とSJISにまつわる文字化けでは糸編の漢字が多く表示 ネット上で見かけた情報で、UTF-8符号化されたバイトコードをSJISとして解釈すると、糸編の漢字が登場しやすいとありました。上述の文字化けでも確かに化けて表示された7文字のうち3文字が糸編の漢字です。これは、「ファイル」をUTF-8符号化したバイナリコードを、SJISとして解釈した時の文字に一致しました。どうやら、Gradleが日本語プロパティファイルをSJIS（正確にはWindows-31j）として解釈してユニコードエスケープした結果生じた文字化けです。

Gradle の filter(EscapeUnicode)

Gradleの振る舞いを調べていくと、EscapeUnicodeによるフィルタは、入力ファイルをデフォルトエンコーディングとして解釈しユニコードエスケープするとありました。

そのため、Windows 10日本語環境で実行したときに、UTF-8をSJISと誤って解釈した結果となりました。

では、Scene Builderのリリース版に含まれる文字化けはどのように発生するのでしょうか？ ここで、Windows OSの英語版でビルドしていると仮定し、Windows OS英語版のデフォルトエンコーディングが何かを調べました。すると、コードページ1252 （ラテン文字1）でした。

Windows OS英語版でScene Builderをビルドすると、EscapeUnicodeによるフィルタは、入力ファイルをCP1252（Windows-1252）として解釈します。例えば、「フ」はUTF-8符号化すると「e3 83 95」となります。これをCP1252として解釈すると、「フ」となり、ユニコードエスケープすると「\u00e3\u0192\u2022」となります。

なるほど、事象が再現しそうです。

問題再現の環境設定

問題再現のために、Windows 10日本語版でデフォルトのエンコーディングをCP1252に変更します。 Windowsの「設定」 > 「時刻と言語」 > 「地域」 で、地域設定を「英語（米国）」に変更します。

Javaで認識するデフォルトエンコーディングを確認します。

D:\work> jshell
|  JShellへようこそ -- バージョン15.0.1
|  概要については、次を入力してください: /help intro

jshell> System.out.println(System.getProperty("file.encoding"))
Cp1252

変更できたので、Scene Builderのソースをビルドします。 結果、文字化けを再現することができました。

問題の再現に3年を費やした 問題が発生したのは2018年に Scene Builder 10がリリースされた時点です。このときは、同じ文字化けを再現することができませんでした。再現はできずとも回避策は提示できたのですが、回避策は環境変数を設定するもので、gradlew.batに設定を記載するPull Requestを作りましたが「gradle側の問題」として受け入れられませんでした。 Gradleをちょっと分かるようになった後から考えると、gradlew.batは gradleのバージョンアップ時に更新されるので、ここに修正を入れるのは不適切だったなぁと・・・

問題の解決

問題の原因は、GradleのEscapeUnicodeフィルタが入力のプロパティファイルをデフォルトエンコーディングで扱うため、UTF-8以外のデフォルトエンコーディングを持つ環境でビルドすると文字化けが発生するというものです。

UTF-8以外のデフォルトエンコーディングを持つ環境の代表例がWindows OSです。

解決の方針

解決案を列挙します。それぞれ検討・検証していきます。

  1. ユニコードエスケープをさせない
  2. UTF-8でEscapeUnicodeさせる
  3. ソースコードリポジトリに登録する日本語プロパティファイルを予めユニコードエスケープ（native2ascii）させる
解決案1

Javaは、JDK 9からリソースバンドル・プロパティファイルをUTF-8で扱えるようになりました（それ以前はISO 8859-1）。そこで、ユニコードエスケープをやめればうまくいくのではというのが解決案1のアプローチです。

次の記述を削除します。

filter(EscapeUnicode)

しかしながら、この結果は不調でした。日本語プロパティファイルはユニコードエスケープされなくなったものの、文字化けです。これは、Gradleがリソースディレクトリのファイルをコピーする際に文字列の解釈が入ってしまい、UTF-8以外のデフォルトエンコーディング環境で文字化けるというものと思い割れます。

解決案2

GradleでEscapeUnicodeの処理をUTF-8として扱うよう設定を追加するアプローチです。 ただし、環境変数での設定やGradlegが生成するファイルの修正ではなく、Scene Builder側で管理するファイルでの設定を追求します。

調査結果、次の記述をbuild.gradleに追加します。

filteringCharset = 'UTF-8'

これはうまくいきました。

解決案3

Scene Builderには、リソースバンドルのプロパティファイルが3つ登録されています。デフォルトの英語プロパティ、中国語プロパティ、そして日本語プロパティです。

英語および中国語のプロパティファイルは、ユニコードエスケープされたファイルがソースコードリポジトリに登録されています。

では、日本語もユニコードエスケープしてしまえというのが解決案3です。

しかし、プロパティファイルはUTF-8で扱えるのがJava SE 9以降であり、しかもnative2asciiコマンドがJDK 10から削除されているご時勢です。ユニコードエスケープしたファイルを扱うのはとても苦痛ですから、このアプローチは最後の手段として取っておくこととします。

解決の提案

解決案2がうまくいったので、これをPRとして提案したところ、採用されました（2021.2）。

よかったよかった。

最後に雑記

経緯は次のチケット（個人Redmine）に記載しています。 www.torutk.com

  • 「きっとすぐに、誰かが修正するに違いない」と思っていたが、年単位が経過しても修正されずにきてしまった。
  • 環境に起因する問題は再現が厄介、とくにロケールに絡む問題は。Javaのデフォルトエンコーディングは厄介。
  • Gradleも中の動きが分かりにくい

jpackageで作る自己完結型アプリケーションの設定ファイル書式がJDK 14と15で変わっていた

JDK 14にてincubatorの位置づけで導入された jpackage（自己完結型アプリケーションパッケージを作成する等のツール）の設定ファイルが、JDK 15では認識されない事象が発生しました。

jpackageコマンドで自己完結型アプリケーションを作成すると、アプリケーションの属性、JavaVMオプション、コマンドラインオプション等を記載する設定ファイルが生成されます。（アプリケーション名に拡張子.cfgを付けたファイル）

JDK 14で作成したときの設定ファイル例を次に示します。

[Application]
app.name=AnalogClock
app.version=0.6.0
app.runtime=$ROOTDIR\runtime
app.identifier=com.torutk.gadget.analogclock
app.classpath=
app.mainmodule=com.torutk.gadget.analogclock

[JavaOptions]
-Xms32m
-Xmx128m
-Xss256k
-XX:TieredStopAtLevel=1
-XX:CICompilerCount=2
-XX:CompileThreshold=1500
-XX:InitialCodeCacheSize=160k
-XX:ReservedCodeCacheSize=32m
-XX:MetaspaceSize=12m
-XX:+UseSerialGC

[ArgOptions]
--x=-144
--y=-240
--scale=0.7
--fps=5
--on-top=true

JDK15で作成したときの設定ファイル例を次に示します。

[Application]
app.mainmodule=com.torutk.gadget.analogclock/com.torutk.gadget.analogclock.AnalogClockApp

[JavaOptions]
java-options=-Xms32m
java-options=-Xmx64m
java-options=-Xss256k
java-options=-XX:TieredStopAtLevel=1
java-options=-XX:CICompilerCount=2
java-options=-XX:CompileThreshold=1500
java-options=-XX:InitialCodeCacheSize=160k
java-options=-XX:ReservedCodeCacheSize=32m
java-options=-XX:MetaspaceSize=12m
java-options=-XX:+UseSerialGC
java-options=--module-path
java-options=$APPDIR\mods

[ArgOptions]
arguments=--x=-144
arguments=--y=-240
arguments=--scale=0.7
arguments=--fps=5
arguments=--on-top=true

[JavaOptions]と[ArgOptions]の項のプロパティの記述がJDK 14のjpackageで生成したものと、JDK 15のjpackageで生成したものとが変わっています。

jpackageは、近日リリース予定のJDK 16で正式導入となります。現在JDK 16のリリース候補版が公開されています。それに含まれるjpackageで作成してみたところ、JDK 15変更と同じ形式となっていました。

Java読書会　会場とオンラインの併用を試みる（実施）

1月度のJava読書会は、会場での開催にオンライン参加を実現しました

昨日1月30日（土）に開催した Java読書会では、通常の会場での開催に、リモートからの参加を併用しました。

リモートからの参加にあたり、構成と準備作業は次に書きました。 torutk.hatenablog.jp

今回利用した会場には、インターネット接続可能なWiFi環境が備わっていたので、それを利用してTeams会議でリモートからの参加を受け入れました。 会場では、Web会議用のマイク・スピーカーと広角カメラ（ノートPC搭載カメラに被せて広角にするタイプ）を用意しました。

結果は、会場から発する音声が切れ切れになるという状況がありましたが、なんとか実施には耐えたようです。

音声が切れ切れになる状況のメモ

会場からの音声は、マイクから50cm程度の距離であれば良好ですが、1mから2mに離れると音声が途切れ途切れになります。また、会場で議論発生時にバラバラな方向から発声があると音声が切れ切れになるようです。

大き目にしゃべるといいようです。

「データ指向アプリケーションデザイン」を読む（第4回）

Java読書会BOF では現在、書籍「データ指向アプリケーションデザイン」 を読んでいます。 昨日の内容は、5章 レプリケーション の途中（マルチリーダーレプリケーション）から始まり、リーダーレスレプリケーションを読み、6章 パーティショニングを読み進め、7章 トランザクションの途中まででした。

Java読書会　会場とオンラインの併用を試みる（準備）

今月のJava読書会で会場での開催にオンラインで参加できるようにしたい

Java読書会BOF は、明日1月30日（土）に「データ指向アプリケーションデザイン」を読む会（第4回）を開催します。

今回は、コロナ禍の2回目の緊急事態宣言発令下での開催となり、会場の定員も半分に削減することとされています。ただし、参加に不安を感じる人もいますので、会場だけでなくリモートからも参加できるよう試みることとしました。

Java読書会BOFでは、以前にコロナ禍の対応として2020年4月、5月、6月の3回をオンライン読書会として実施しました。

昨年のオンライン読書会との違い

昨年は、全員がオンライン参加としたので、参加者がそれぞれマイク・スピーカーを揃えてTeams会議に参加する形でした。今回、会場でのリアル開催とオンラインをつなぐので、会場にリアル参加の会話とオンライン参加の会話がつながるようにする必要があります。

読書会は朝10:00から夕5:00までと長丁場でその間音声・動画を流すので、時間やパケット量に制限のあるインターネット接続サービス（携帯電話や上限のあるモバイルルータ）は不適です。また、利用するWeb会議サービスも参加人数や利用時間が読書会開催に足りることも必要です。

今回利用する会場には、インターネットと接続できるWiFiサービスが提供されているので、オンラインとつなぐことはできそうです。

Web会議サービスは、昨年のオンライン読書会と同様 Microsoft Teams（無償版）としました。これは参加人数と利用時間が読書会開催に十分足りています。

アイテムの準備

続いて、次のアイテムを準備することにしました。

  1. 会議用のマイク・スピーカー
  2. 会場全体を映すカメラ
マイク・スピーカー

Java読書会は、参加者が順番に書籍を朗読し、随時議論を行うので、無指向性のマイクを真ん中に置く構成とします。といってもJava読書会は手弁当で開催しているので高いアイテムを買うのは厳しいのでなるべく廉価でそこそこ使えそうなものを探しました。

この中から、価格と無線接続が可能なLunaを選び購入しました。バッテリー搭載で無線でPCと接続できるので、会議室の真ん中に、電源やPCとの有線接続をせずに置くことができる点を評価しました。

カメラ

ノートPCのカメラで会場を映すと画角が狭く正面の参加者しか映りません。そこで、広角のカメラを用意すべく探してみたところ、スマフォのカメラに被せて広角にするレンズなら安価に用意できそうでした。

1000円未満の格安帯と、1000～5000円当たりの帯と、さらに高価な帯とがありました。格安なものはケラレという現象が出るとかがあり、その上を狙いました。

広角なカメラは120度が多いようですが、中に165度という超広角がありました。会場で自席に置いたノートPCからなので、この超広角を選び購入しました。

Teams（無料版）

今回もTeamsを使う想定です。

Microsoftアカウント

Teamsは、参加者もアカウントが必要です。アカウントは、Microsoftアカウントです（無料で作成可能）。 次のリンク先で作成します。 https://account.microsoft.com/account/

メールアドレスがキーとなります。作成、使用時にはキーとしたメールアドレスにセキュリティコードが送られるので、そのメールアドレス宛のメールを読み取れる環境が必要です。

Microsoftアカウントを作成し、Teamsアプリを起動すると、「まだTeamsに登録していませんが、組織でセットアップできます」のメッセージと[Teamsに新規登録]ボタンが表示されてしまいます。これは

参加に必要なこと
  • Microsoftアカウントを保有している
  • 会議への招待のリンクを開く
会議の作成（管理者）

最近のTeams（無料版）は、「今すぐ会議」機能だけでなく、「会議のスケジュール設定」機能が追加され、事前に未来の会議を作成し招待リンクを事前配布することができるようになりました。

動作確認

自宅のデスクトップPCとノートPCとでMicrosoftアカウントを別にしてTeamsに接続、会議を作成し、招待リンクを辿って会議に参加し、eMeetのマイクが使えることまで確認しました。

あとは明日会場で確認することとなります。

Java読書会　今月から読む本

はじめに

前回の本と台風とコロナ禍と

Java読書会BOF 主催のJava読書会は、昨年2019年11月から毎月1回のペースで「The Java Module System」（洋書）を読む会を開催し、先月2020年9月に読了しました。

この本の読書会期間中には、台風直撃とコロナ禍と大きな出来事が重なりました。

台風による中止

まず、予定していた第1回（2019年10月12日）は関東に台風19号が直撃し、中止としました。この台風では、鉄道の運休、多摩川の氾濫が発生するといった状況のため翌月に延期となりました。Java読書会BOF主催の読書会は毎月開催をしていますが、これが途切れたのは2001年6月以来で18年ぶりのことでした。

オンライン（Web会議）開催

また、2020年4月7日にはコロナ禍による緊急事態宣言が発出され、4月11日（土）に予定していた第6回は会場での開催ができなくなり、初のオンライン開催となりました。

緊急事態宣言の発出がほぼ確実視された時点でオンライン読書会を実施するためのサービスを調べました。当時の調査結果は次です1。

Java読書会オンライン開催検討 - ソフトウェアエンジニアリング - Torutk

この中から、読書会参加人数の平均である11人程度をカバーし、開催時間である朝10:00～夕17:00までの7時間をカバーするサービスで無償なものとなると、Microsoft Teamsの無償版がほぼ一択でした。そこで、第6回～8回（4月、5月、6月）はTeamsを利用したオンライン開催としました。

読書会開催データ

2019年9月時点での読書会開催に関するデータです。

項目 値
開催回数 257回
書籍数 39冊
総ページ数 15,183ページ
1回の平均ページ数 59ページ
平均参加人数 11人
のべ参加人数 2,821人

10月からの本

Java読書会の継続に影響を及ぼす事象は自然災害だけではなく、Java技術に関する読書会向きな書籍の候補がでないという事象もあります。世の中的に出版不況や技術書籍の刊行が（初心者向けの入門本を除くと）不調というのがあるのかもしれません。

このような中、課題図書の候補のリストアップと投票を実施したところ、「データ指向アプリケーションデザイン」に決まりました。

投票の状況は次のとおりです。1票差と接戦でした。

書籍名 投票数
データ指向アプリケーションデザイン 9票
マイクロサービスパターン 8票
テスト駆動開発 2票
実践テスト駆動開発 1票
Design It!ープログラマーのためのアーキテクティング入門 1票

著者（Martin Kleppmann氏）について

著者の自己紹介ページ https://martin.kleppmann.com/

著者のMartin Kleppmannは現在英国ケンブリッジ大学で分散システムの研究者（Senior Research Associate／Affiliated Lecturer）。以前はソフトウェアエンジニア＆起業家として活動。 また、オープンソースプロジェクト automerge、apache avro、apache samza の貢献者。 分散システムに関するカンファレンスのスピーカー。

内容（超概要）

分散システムにおいて主にデータを扱うシステムを構築するための様々な技術（原理）を解説しています。 データモデル、ストレージ、レプリケーション、パーティショニング、トランザクション、一貫性と合意、バッチ処理、ストリーム処理といった章題が並びます。

この書籍の感想ブログへのリンク

この書籍について感想を書かれているブログが多数ありました。 検索で見かけたものをいくつかピックアップします。

hydrakecat.hatenablog.jp

kuromt.hatenablog.com

takezoe.hatenablog.com

takuti.me

  1. 2020年4月10日時点の情報で、その後コロナ禍対応のためそれぞれのサービスが向上しています。↩