小さな渋谷の会社でゼロから作るWebアプリケーション (4) Java環境整備
株式会社エー・アンド・ディのCTOの山口です。
前回でJavaのアプリケーションが動かせるところまでいきました。
今回は、チーム開発などで有用なJavaのフォーマッター・静的コード解析ツール(CheckStyle)を有効にします。
なお、本マガジンで開発しているプロジェクトのソースコードはこちらで公開しています。
(開発は継続しているため、masterブランチでは本文の内容より先に進んでいる場合があります)
https://github.com/andcorp/morisoba
フォーマッターについて
プログラミングでは、ソースコードを人間の手で書いていきます。
その時、スペースの入れ方・改行の入れ方・変数や関数の名前の付け方など、プログラムの動作に関わる箇所以外のスタイルについても、人間が意識して書く必要があります。
たった一人で開発している限りはどうとでも好きに書いて良いのですが、複数の人間で継続的にプログラミングを行っていく場合、スタイルが統一されていると以下のメリットがあります。
* ソースコードを読むときに、スタイルが統一されていると読みやすい。
* ソースコードを書くときに、方針が統一されていれば悩む必要がない。
また、プログラミング言語によってはある程度標準的なスタイルがあり、そちらに沿うことで、新しいメンバーや外部の開発者に読みやすくすることができます。
Javaでは、以下の2つが有名です。
Code Conventions for the Java Programming Language
Sun (現Oracle) 謹製のコード標準
Google Java Style Guide
GoogleのJavaスタイルガイド
こういった、決められたスタイルに沿ってソースコードを自動で整形してくれるツールがフォーマッターです。
フォーマッターを使うことで、以下のメリットがあります。
* スタイルが機械的に統一される。
* 属人性が排除される。
* スタイルの適用漏れが無くなる。
* コーディング時、細かいスタイルを気にしなくてよくなる。
* ある程度スタイルから外れていても、フォーマッターが保存時等に勝手に調整してくれる。
静的コード解析ツールについて
プログラミングでは、「基本的にこうした方がよい」「基本的にこうしない方がよい」という規約が多数存在します。
例を挙げると、
* publicなクラスでpublicかつ変更可能なフィールドを持たない方がよい。
* ローカル変数は明示的に初期化した方がよい。
* 不必要にObject型を使わない方がよい。具体的な型を使用したりジェネリックスを使用した方がよい。
* equalsメソッドをオーバーライドした場合、hashCodeメソッドもオーバーライドした方がよい。
こういったものは、プログラミング言語としては特にエラーの対象にはなりません。
しかし、バグを誘発したりソースコードを分かりにくくする原因になります。
こういった「基本的にこうした方がよい」「基本的にこうしない方がよい」という規約についてチェックを行うのが静的コード解析ツールです。
(高度なツールになると、複雑すぎる箇所の指摘や統計処理などを行えますが、今回はそこまでやらない予定です)
Javaではよく利用されている静的コード解析ツールにCheckStyleというものがあります。
VSCodeでも拡張機能により利用できるので、このプロジェクトではそちらを活用します。
Javaのフォーマッターの設定を作る
さて、さっそくJavaのフォーマッターを有効にしてみたいのですが、その前にフォーマッターの設定ファイルが必要です。
設定ファイルを用意するのにいくつか選択肢がありますが、今回はEclipseでフォーマッターの設定ファイルを作る方法をとってみたいと思います。
なぜ突然Eclipse……?
実は、今まで黙っていましたが、VSCodeのJava拡張は内部でEclipse(のJDT Language Server)を利用しています。
(実は、.projectなどのEclipse用ファイルも裏で自動生成されていたりします)
そのため、Eclipseのフォーマッターの設定ファイルがそのまま使えるのでした。
というわけで、突然のEclipseでフォーマッターの設定ファイルを作ります。
ここからいきなりEclipseの説明記事になります。
まずはEclipseをダウンロードするわけですが、以下のサイトからzipファイルをダウンロードするのがおすすめです。
対象ファイルは「Eclipse IDE for Enterprise Java Developers」の「Windows 64-bit」でよいです。
ダウンロードされたzipファイルのeclipseフォルダの中に、Eclipseの実行ファイル eclipse.exe が格納されています。
こちらの実行でEclipseが起動されます。
ただ、Eclipseの起動にはJavaが必要です。
もしJavaをインストールしていなければ、(本プロジェクトのためにJDKをダウンロードしたのみであれば)環境変数JAVA_HOMEをcorrettoのパスを指すように設定すればOKです。
後でJAVA_HOMEを削除することを忘れないでください。
Eclipseを起動すると、こんな画面が出てくると思います。
適当に決めてOKを押します。(フォルダが作られますが、不要であれば後で消してOKです)
ここで、Windows > Preference メニューを選択します。
すると、下記のような設定ダイアログが開きます。
左側のツリービューを辿り、Java > Code Style > Formatter を開きます。
ここでEclipseのJavaのフォーマッター設定が取得できます。
「Active Profile:」の下の方にある「New...」ボタンを押します。
適当に「Profile name:」を入れ、「OK」を押します。
すると、新しいフォーマッター設定の設定ダイアログが開きます。
基本的にはデフォルトのまま使用しますが、「Enable Off/On tags」の設定だけ使いたいので、このチェックをOnにします。
(コメントによりフォーマッターのOn/Offを切り替える機能です)
「Enable Off/On tags」のチェックをOnにしたら「OK」ボタンを押します。
また元のダイアログに戻るので、ここで「Export All...」ボタンを押します。
すると、設定内容がxmlとして保存できます。適当な場所に保存してください。
以上で、Eclipseでのフォーマッター設定ファイル作成手順は完了です。お疲れ様でした!
Eclipseは、フォーマッター設定がうまくいけばもう削除して大丈夫です。
Eclipseのフォーマッターの設定ファイルのライセンスは?
さて、これからこの設定ファイルをVSCodeで使うようにして、Gitに格納したり共有したりします。
ところで、この設定ファイルってライセンスどうなるんだっけ……。
この問題は、たぶん会社内などで「使用」するだけであれば問題ないのですが、成果物に含めて提出したり、私のようにGithubで共有する場合、悩む必要があります。
組み込みのチェック内容はEclipse Foundation(の協力者)により作成されています。
もし、このチェック内容が、Eclipse内部のソースコードの一部からコピーされていたら、そこにライセンスが発生しています。
Eclipse自体は、EPL 2.0というOSSライセンスが適用されています。
もしEclipseのソースコードを改変して配布するとしたら、該当ソースはEPL 2.0のままとし、元のソースコードの入手方法などを明記しないといけません。
それで、果たしてこの出力されたXMLはどう扱えば良いんだろう……。
Eclipseのソースコードで言えばおそらくこのあたりの内容が出力されているのですが、
XMLファイルそのままの形で保持されていないので、XMLはプログラムの出力結果であるという結論になりそうな気がします。
(GIMPやEmacsの出力結果にGPLが適用されないのと同様に、プログラムの出力結果にライセンスは及ばない)
ただ、デフォルト値をそのまま使用しているなど、確証は持てない部分があるので、該当ファイルはEPL 2.0を適用します。
(プログラム本体に組み込まれない差し替え可能な外部ファイルなので、プログラム全体へのEPL 2.0の適用は免れます)
VSCodeでEclipseのフォーマッター設定を使用する
ようやくVSCodeに戻ってきました……。
まず、VSCodeワークスペースのmaster\java_formatterに先ほど出力したXMLファイルを格納します。
そして、Javaのフォーマッター設定を有効にするために、morisoba.code-workspace.template を修正します。
// 前略
"settings": {
"editor.formatOnSave": true, // これを追加
"java.home": "${userJavaHome}",
"java.format.settings.url": "master/java_formatter/java_formatter.xml", // これを追加
"java.jdt.ls.vmargs": "-noverify -Dfile.encoding=utf8 -Xmx1G -XX:+UseG1GC -XX:+UseStringDeduplication",
"java.configuration.updateBuildConfiguration": "automatic",
"files.exclude": {
"**/.classpath": true,
"**/.project": true,
"**/.settings": true,
"**/.factorypath": true,
"jdk/": true
},
"terminal.integrated.env.windows": {
"JAVA_HOME": "${userJavaHome}"
}
}
// 後略
そして、master\initialize.batを叩きます。
PS C:\Users\ikemen\github\morisoba> .\master\initialize.bat
C:\Users\ikemen\github\morisoba>cd C:\Users\ikemen\github\morisoba\master\
C:\Users\ikemen\github\morisoba\master>CALL :SET_JAVA_HOME "..\jdk\amazon-corretto-11"
C:\Users\ikemen\github\morisoba\master>SET JAVA_HOME=C:\Users\ikemen\github\morisoba\jdk\amazon-corretto-11
C:\Users\ikemen\github\morisoba\master>EXIT /B
C:\Users\ikemen\github\morisoba\master>.\gradlew.bat --stacktrace initializeWorkspace
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/5.5.1/userguide/gradle_daemon.html.
Daemon will be stopped at the end of the build stopping after processing
Configuration on demand is an incubating feature.
BUILD SUCCESSFUL in 8s
1 actionable task: 1 executed
これでフォーマッターが有効になっているはずです。早速試してみましょう!
このような絶望的なコーディングスタイルで書いてあったとしても……
package
jp.co.andcorp.morisoba;
import
org.springframework.boot.SpringApplication;
import
org.springframework.boot
.autoconfigure.SpringBootApplication;
/**
* アプリケーションクラス.
*/
@SpringBootApplication public class Application
{
/**
* アプリケーションのメインメソッド.
*
* @param args コマンドライン引数
*/
public
static
void
main(
final String[] args) {
SpringApplication.run(Application.class,args);
}
}
保存してみます。
package jp.co.andcorp.morisoba;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
/**
* アプリケーションクラス.
*/
@SpringBootApplication
public class Application {
/**
* アプリケーションのメインメソッド.
*
* @param args コマンドライン引数
*/
public static void main(final String[] args) {
SpringApplication.run(Application.class, args);
}
}
このように元通り!
設定ファイルを作ったりするのは面倒でしたが、使うのは割と簡単でしたね。
CheckStyleの設定を作る
さて、次は静的コード解析ツールのCheckStyleです。
こちらも、設定ファイルを入手してくる必要があります。
CheckStyleは、デフォルトの設定ファイルが明確にソースコードに含まれています。
そして、ライセンスはLGPL 2.1になります。
https://github.com/checkstyle/checkstyle#licensing
というわけで、デフォルトのsun_checks.xmlファイルをLGPLに従って改変し、利用します。
修正結果はこちらのファイルになります。
修正点は下記の通りです。
* コメント削除
* 改行コードをLFに設定
* 警告抑止用のコメントを設定
* テストコード向けの警告抑止フィルターを設定
VSCodeのCheckStyle設定
設定ファイルができたので、VSCodeで使用する設定を行います。
まず、CheckStyle向けの拡張機能をmorisoba.code-workspace.templateに追加します。
// 前略
"extensions": {
"recommendations": [
"EditorConfig.EditorConfig",
"eamodio.gitlens",
"redhat.java",
"vscjava.vscode-java-debug",
"vscjava.vscode-java-pack",
"vscjava.vscode-java-test",
"vscjava.vscode-maven",
"shengchen.vscode-checkstyle", // これを追加
]
},
// 後略
そして、CheckStyle用の設定を追加します。
// 前略
"settings": {
"editor.formatOnSave": true,
"java.home": "${userJavaHome}",
"java.format.settings.url": "master/java_formatter/java_formatter.xml",
"java.jdt.ls.vmargs": "-noverify -Dfile.encoding=utf8 -Xmx1G -XX:+UseG1GC -XX:+UseStringDeduplication",
"java.configuration.updateBuildConfiguration": "automatic",
// 次の行を追加
"java.checkstyle.configuration": "master/checkstyle/checkstyle.xml",
"files.exclude": {
"**/.classpath": true,
"**/.project": true,
"**/.settings": true,
"**/.factorypath": true,
"jdk/": true
},
"terminal.integrated.env.windows": {
"JAVA_HOME": "${userJavaHome}"
},
}
// 後略
これでJavaのファイルがチェックされるようになります。
さっそくApplication.javaを開いてみます。
いきなり赤いですね……。
この警告、言っていることはまっとうですが、実はSpring Bootのために仕方ない部分です。
(デフォルトコンストラクタがないとSpring Bootが起動できません……)
そのため、先ほど設定で追加した抑止コメントで抑止してしまいます。
警告が消えました!
とりあえずこれで、警告が出ること・消せることの確認はできましたね。
まとめ
今回で、Javaのコーディングに向けた基本的な準備が完了しました。
とはいえ、まだ全然自分で作ったWebページなどが無い状況です。
次回は、自分が作ったWebページを表示する、つまりフロントエンドの実装に入っていこうと思います。
免責事項・ライセンス
この 作品 は クリエイティブ・コモンズ 表示 - 改変禁止 4.0 国際 ライセンスの下に提供されています。
弊社の当コンテンツに掲載されている情報の正確性・安全性などについての保証はなく、弊社は何らの責任を負うものではありません。
弊社の当コンテンツに掲載された内容によって生じた損害等の一切の責任を負いかねますので、ご了承ください。
Copyright © 2019 ANDCORP.
この記事が気に入ったらサポートをしてみませんか?