移行 _project.shのJAVA_HOME

DBFluteクライアントのメンテ？
そもそも _project.shとは？
JAVA_HOME調整の移行

DBFluteクライアントのメンテ？

DBFluteランタイムやDBFluteエンジンはアップグレードされても、DBFluteクライアントはアップグレードされません。アプリの情報を保存しておく場所なので、基本的にはそれで問題ありません。

ただ、何年も続くプロジェクトだと大昔のDBFluteで作ったDBFluteクライアントが時々ギャップになることもあるかもしれないので、その代表的な例を一つお話します。

(最新のDBFluteにアップグレードしたときに、DBFluteクライアントの最新テンプレートとアプリのものを比べる習慣があると理想ではあります)

そもそも _project.shとは？

MacやLinuxなどシェルベースのOSにて manage.sh を実行する時に、真っ先に呼び出されるファイルです。 DBFluteタスクをシェルから実行する上で必要な設定がされます。

e.g. _project.sh @Shell
#!/bin/bash

export ANT_OPTS=-Xmx512m

export DBFLUTE_HOME=../mydbflute/dbflute-1.2.6

export MY_PROPERTIES_PATH=build.properties

JAVA_VERSION=1.8+

# auto-setting for JAVA_HOME (keeping exiting JAVA_HOME)
if [[ -z "${JAVA_HOME}" ]]; then
  if [[ `uname` = "Darwin" ]]; then
    export JAVA_HOME=$(/usr/libexec/java_home -v ${JAVA_VERSION})
  fi
fi

Apache Ant のメモリ設定
DBFluteエンジンの場所
内部propertiesの名前
JAVA_HOMEの調整 (DBFluteエンジンが実行されるJavaのバージョンを決める)

内部的なものが多いですが、アプリ側で一番意識する可能性があるのは、JAVA_HOMEでしょう。

JAVA_HOME調整の移行

JAVA_HOMEの調整部分は、昔と変わっている部分があります。

昔の書き方

以前は、"MacだったらJava8を使う" になっていました。 (ただし、Java8がなければ無視されます)

e.g. 昔の_project.shのJAVA_HOME調整 @Shell
if [ `uname` = "Darwin" ]; then
  export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)
fi

これは、開発者のPCにまだ Java6,7 が入ってることが多い時代、Java8版のDBFluteがJava6,7で実行されないようにするためのものでした。 Java6,7の時代は過ぎても、DBFluteをJava8で実行するのは一番マッチしているので、この処理はそのまま利用されていました。

ただ、今度はJava8が開発者のPCに入っていないケースも多くなってきました。PC上のJAVA_HOMEも開発プロジェクトに合わせた(より新しい)Javaが指定されていることも多くなりました。

ですが、昔の調整処理だと、PC上のJAVA_HOMEを無視してJava8を指定してしまいます。 Java8がたまたま入っている人はJava8で動き、そうでない人は別のJavaのバージョンで実行されます。

それでも、ほとんどの場合は問題ありませんが、時々実行するJavaのバージョンの違いで結果が変わってしまう可能性もあるので、それで不都合が生じることもあります。

今の書き方

いまは、"JAVA_HOMEが設定されてなくてMacだったらJava8以上を使う" になります。

e.g. 今の_project.shのJAVA_HOME調整 @Shell
JAVA_VERSION=1.8+

# auto-setting for JAVA_HOME (keeping exiting JAVA_HOME)
if [[ -z "${JAVA_HOME}" ]]; then
  if [[ `uname` = "Darwin" ]]; then
    export JAVA_HOME=$(/usr/libexec/java_home -v ${JAVA_VERSION})
  fi
fi

つまり、すでにPCで既存のJAVA_HOMEが設定されていれば、それを優先するということです。

開発プロジェクトがJava8よりも新しいJavaバージョンを使っていて、開発者みんなでJAVA_HOMEを合わせているのであれば、こちらの調整の方がバージョン違い可能性は減ります。

ゆえに、もし既存のDBFluteクライアントの_project.shが、昔の書き方になっているのであれば、今の書き方も修正することを検討しても良いでしょう。

アプリ独自の書き方

開発者同士でPC上のJAVA_HOMEを統一してるわけではないけどJava8より新しいバージョンで統一したい...とかであれば逆に昔の書き方でJavaのバージョンだけ変えてベタッと強制させても良いでしょう。

e.g. アプリで独自に_project.shのJAVA_HOME調整 @Shell
if [ `uname` = "Darwin" ]; then
  export JAVA_HOME=$(/usr/libexec/java_home -v 17)
fi

ただし、アプリのJavaのバージョンがアップされたときに、こちらも修正し忘れないようにしましょう。 (忘れても大抵は問題ないでしょうが、結局みんなでバージョンがバラバラになる可能性があります)

このように、開発現場の都合に合わせてうまくJAVA_HOMEを調整してもOKです。ベストプラクティスは現場次第です。