Java
システム開発
バージョン管理
統合開発環境

使用するJava API、統合開発環境、バージョン管理システム

ここは?

https://qiita.com/k73i55no5/items/9e0825cee4cc1cb078a6
当方がまとめている記事集で使うJAVA API、統合開発環境(IDE)、バージョン管理システムについて纏めています。
完全に自分用のメモです。なんせ人一倍に物事を忘れっぽいので。
デスクトップとかも、すぐアイコンばっかになって整理が追いつかないような性格なんですよ。

Java API

Java SE

インストール時のバージョンは8です。
無償版はJava SE 10まで出ているようですが、8を入れてからバージョンアップさせていません。

Java EE

ある程度の規模をもつWebアプリケーションの構築に役立つAPI集のようです。
ビューの処理の実装にバッキングビーンという機能を用いる点や、ビジネスロジックの実装にEJBと呼ばれる機能を利用する点など、DDD(ドメイン駆動設計)の考え方に基づき開発を進めていく上でいろいろと使えそうです。

  • インストール時のバージョン
    • Java EE 8
    • GlassFish 5(アプリケーションサーバー)

統合開発環境

Eclipse

大昔はVB使ってました。

  • インストールパッケージ

    • Pleiades All in One - http://mergedoc.osdn.jp/
    • EclipseとPleiades(日本語化プラグイン)がセットになっていて、すぐに日本語Eclipseを使えます。
  • インストール時のバージョン

    • Pleiades All in One 4.7.3a.v20180411
    • Eclipse 4.7 Oxygen 3a
    • JDK 8u162(インストールパッケージに同梱)

ここ数年ペーパープログラマーだったので、使い方をいろいろと忘れてます。
忙しくなってプログラミングしなくなって、バージョンアップに気づいてないとか、ざらにあると思います。

JDKについては、今の所PATHの設定やJAVA_HOMEの設定を特にいじっていません。
今後通す必要性が生じれば通します。
コンパイル用JDKは、インストールパッケージに同梱されているものを使っています。
jar実行用JDKは、手動インストールしたもの(JDK 8u172)を使っています。

初期設定

基本設定

  1. ワークスペース
    • 「この選択をデフォルト……」にチェックを入れ、[OK]をクリックする。
  2. コンパイラー準拠レベル
    • ウィンドウ>設定>Java>コンパイラー>JDK準拠>コンパイラーの準拠レベル
    • インストールしたJDKのバージョンに合っているか確認する。
  3. テキスト・ファイル・エンコード
    • ウィンドウ>設定>一般>ワークスペース>テキスト・ファイル・エンコード>その他
    • UTF-8に設定されているか確認する。
  4. テキスト・フォント
    • ウィンドウ>設定>一般>外観>色とフォント>基本>テキスト・フォント
  5. 空白文字
    • ウィンドウ>設定>一般>エディター>テキスト・エディター
    • 「空白文字を表示」にチェックを入れると、空白が表示されるようになる。
    • 不必要な空白の入力によるコンパイルエラーを防げる。
  6. Javaの自動有効化トリガー
    • ウィンドウ>設定>Java>エディター>コンテンツ・アシスト>Javaの自動有効化トリガー
    • 「.abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_」を入力
    • 上の文字のいずれかを入力すると、コードを補完してくれる。
  7. e(fx)clipse
    • ヘルプ>Eclipse マーケットプレイス
    • 「e(fx)clipse」で検索し、[インストール]をクリックする。
    • 任意のプロジェクトにライブラリー「JavaFX SDK」を追加することで、EclipseがJavaFX CSSを認識できる。
  8. JavaFX API ドキュメントの日本語参照
    • ウィンドウ>設定>Java>インストール済みのJRE
    • JREを選択し、[編集]をクリックする。
    • JREシステム・ライブラリの中から「jfxrt.jar」を選択し、[Javadoc ロケーション]をクリックする。
    • Javadocロケーション・パスに次のURLを入力する。

JAVA EE関連の設定

  1. GlassFish(アプリケーションサーバー)の導入
    • ヘルプ>新規ソフトウェアのインストール
    • 作業対象に次のURLを入力し、[追加]をクリックする。
    • 名前に任意の文字列を入力する。(GlassFish Toolsなど)
    • ツール>Oracle Jave EE Tools>次へ
    • 次へ>使用条件の条項に同意します>完了
    • インストール完了後、[今すぐ再起動]をクリックする。
  2. サーバーの設定
    • ウィンドウ>設定>サーバー>ランタイム環境
    • 「新規ローカル・サーバーの作成」にチェックを入れ、[追加]をクリックする。
    • GlassFish locationには「{インストールディレクトリ}/galssfishx(xはバージョン)/glassfish」を指定し、Java locationには利用するJavaSEのインストールディレクトリを指定する。
    • 次へ>完了
  3. サーバービューの表示
    • ウィンドウ>ビューの表示>その他>サーバー
  4. ホットデプロイの設定
    • サーバービューでサーバー設定をダブルクリックし、[公開]タブを開く。
    • 「リソースの変更時に自動的に公開」にチェックを入れ、保存する。
    • これにより、サーバーの停止、再始動を行わなくとも、変更内容を即時適用できる。

参考:https://ittoybox.com/archives/509

サーバーの起動実行時に"deploy is failing=Application with name [...] is not deployed"と出てデプロイできない場合は、以下の設定によりエラーを回避できます。

  • 起動するサーバーを右クリックし、[プロパティー]をクリックする。
  • GlassFishを選択し「Use JAR archives for deployment」にチェックを入れる。

参考:https://argrath.ub32.org/annex/2016/04/14-02.html

新規プロジェクト作成

一般

執筆中

Mavenプロジェクト

執筆中

参考:https://ittoybox.com/archives/553

よく使うショートカットキー

  • Ctrl+Space
    • 何文字か入力して使うと、コードを補完してくれる。
  • Ctrl+1
    • 警告が出ている箇所で使うと、可能な修正方法を表示する。
  • Ctrl+Shift+B
    • ブレークポイントの設定と解除を切り替える。
  • Ctrl+/
    • コメントアウトの設定と解除を切り替える。
  • Alt+Shift+R
    • メソッド名の変更などで、1箇所名前を変更するだけで全部変更してくれる。

ソースコード及びバージョン管理

Github

https://github.com/
作ったプログラムはここにうpしてます。
バージョン管理も後述するGitを使って出来るみたいなんで。

ローカルリポジトリ

通常は、ホームディレクトリ下にgitフォルダを作成し、その中に作ったプログラムを納めていくかと思います。
私の環境では、デフォルト設定のままディレクトリにごちゃごちゃファイルを置かれるのは嫌なので、
Git Bashを使用するときのみ、環境変数HOMEを一時的に書き換え動作するように設定しています。

ホームディレクトリの変更は、通常、環境変数HOMEの値を書き換えることで行えますが、
他のアプリケーションの動作に悪影響を及ぼす恐れを考慮し、そのような処置を施しています。

動作自体は、Git Bashのショートカットのプロパティ「リンク先」を設定することで可能です。
例えば、Git Bashのインストールディレクトリが「C:\Program Files\Git」であって、
変更したいホームディレクトリを「D:\hogehoge」としたい場合は、

C:\Windows\System32\cmd.exe /c "set HOME=D:\hogehoge&"C:\Program Files\Git\bin\sh.exe" --login -i"

と入力します。

リモートリポジトリ

https://github.com/k73i55no5/Samples
名前はSamplesにしました。

Git

https://gitforwindows.org/
こんな便利なツールがあるんですねぇ。知らなんだ。
早速インストールして、説明書見ながらいじってます。

LINUXとかいじったことない人でも大丈夫です。
そのまま特に何もいじらずOK連打しインストールして、
Windowsの方は「Git Bash」っての起動すればいいので。
Mac又はその他OSご利用の方は・・・今メインで使ってないんで、恐れ入りますがググって調べてください。

とりあえずGithubに垢を登録してある前提で、綴っていきます。

初期設定

最低でも、名前とメールアドレスの設定はしとかないとエラーを吐くみたいです。
ローカルにメールアドレスとか設定する場所を増やすと、後々変更になった時に面倒くさいんですよね。
まあ、そう変更する機会は無いと思いますが。

$ git config --global user.name "Piyo"
$ git config --global user.email piyo@piyo.com

とりあえず、piyoで登録しときました。
多分、実務で使わない(個人で使ってる)間は、本物を設定する必要性をあまり感じられないので。
必要性を感じたら、修正することにします。

設定されたかどうか確認したい場合は、次のコマンドを実行します。

% git config --list
...
(途中省略)
user.name=Piyo
user.email=piyo@piyo.com

SSH鍵の生成

大学でそういえば、そんなこと習ったなぁ・・・。
と、昔の呑気な学生生活を思い出しつつ。

$ ssh-keygen -t rsa -b 4096 -C "piyo@piyo.com"
Generating public/private rsa key pair.
Enter a file in which to save the key (/c/Users/***/.ssh/id_rsa):

どうやらデフォルトでは、設定ファイルはユーザーディレクトリ下になるようです。
そのままエンターキーを押さずに、例えば「/d/.ssh/id_rsa」と入力すれば、Dドライブ直下に保存されます。
私の環境では、「.ssh」ディレクトリがないとエラーを吐いたので、先に用意しておいたほうが良いかもしれません。

その後パスフレーズの入力を求められますが、これも先程と同様の考えで、空白にしました。

秘密鍵・公開鍵

パスフレーズの入力が完了すると、秘密鍵(id_rsa_github)と公開鍵(id_rsa_github.pub)のペアが生成されます。
秘密鍵は、秘密なので公開厳禁。

.pubの拡張子がついている方を、GitHub等のSSH接続を使うサービスに登録して使います。
SSH通信時に、手元の秘密鍵と通信先に登録した公開鍵との照合成功をもって、認証となるようです。

https://help.github.com/articles/adding-a-new-ssh-key-to-your-github-account/
ここを参考に登録。登録した鍵のタイトルはpiyo。

configファイルの作成

$ vim ~/.ssh/config

SSHのconfigファイルを編集します。
SSH通信時に、任意の管理名を予め登録しておくことで、
将来秘密鍵を複数管理する時に、どの秘密鍵を指定するのかを管理できます。

https://qiita.com/okamos/items/c97970ab34ff55ff3167
vimの扱い方をすっかり忘れていたので、参考。

挙動 キー
挿入モード i
コマンドモード ESC
上書き保存 :w
保存して閉じる :x
閉じる :q
Host <管理名>
  HostName github.com
  User git
  IdentityFile <秘密鍵のあるディレクトリ>

管理名にあってはgithubで、秘密鍵のあるディレクトリにあっては「~/.ssh/id_rsa」で登録しました。

リポジトリの初期化及びコピー

ローカルリポジトリのディレクトリ下で、初期化します。
リポジトリとして管理すべき情報を含んだ.gitディレクトリ(隠しファイル)が作成されます。

$ git init

起動時に作業ディレクトリに移動されている状態にしたければ、
Git Bashのショートカットのプロパティ「作業フォルダー」を設定することで可能です。
その時、「リンク先」に--cd-to-homeがついていたら、そのコマンドは削除してください。

次に、リモートリポジトリの内容をローカルにコピーします。

$ git clone git@github.com:k73i55no5/Samples.git

SSH通信

以下の行を入力すれば、指定したホスト名、ユーザー名及び秘密鍵でSSH通信ができます。

$ ssh github

ブランチの作成

ブランチの作成
$ git branch <new-branch-name>
作業ブランチの変更
$ git checkout <branch-name>

ブランチの作成及び作業ブランチの変更は、
まずはじめに後述する管理対象の追加を行い、初回コミットをしないと機能しないようです。

ブランチ名は、それこそメソッド名みたいに「動詞(+目的語)」みたいな命名にしたほうが良いのかな・・・?
ぱっと見て、把握できるような名前のほうがいいですよね、きっと。

管理対象の追加

ファイル又はディレクトリを管理対象に追加
$ git add <add-files>
// 次のコマンドで、カレントディレクトリ以下のすべてのファイルを管理対象に追加
$ git add .
ステータスと差分の確認
$ git status
$ git diff
// 確認対象に追加後は、次のコマンドで差分を確認できる
$ git diff --cached

まだ細かく使ってないのでなんとも言えないのですが、
どうやら基本は「ブランチの作成→作業ブランチとする→管理対象を追加→コミット→プッシュ」の流れみたいです。
これで一つ一つの修正、加筆、削除等をブランチ単位で管理できるということなのでしょう。

コミット

コミット
// メッセージを指定したコミット
$ git commit -m <message>
// コミット後は、それぞれ次のコマンドでログを確認できる
$ git log
$ git log --oneline      // 1コミットにつき1行だけの簡易的な表示
$ git log -p <file-path> // 1ファイルにおける変更の詳細を表示
$ git log --stat         // 変更があったそれぞれのファイルにおける変化の割合を表示

コミットは、複数人で一つの作品に携わる上で、
意思疎通を図りながら作業するために必要不可欠というわけですね。たぶん。

言葉的に「約束する」とか「同意する」って意味なので、あくまで直訳的解釈ですが。

コミットメッセージの書き方については、こちらを参考。
https://qiita.com/itosho/items/9565c6ad2ffc24c09364

コミットメッセージを修正する詳しい方法は、こちらを参照。
https://www.granfairs.com/blog/staff/git-commit-fix

コミットメッセージの修正
// 直前のコミットメッセージを修正
$ git commit --amend -m <message>
// 2つ以上前のコミットメッセージを修正
// commitNoは直前のコミットを1として、修正したいコミットまでの数
$ git rebase -i HEAD~<commitNo>
// vim編集後、再コミット
$ git commit --amend -m <message>
$ git rebase --continue
// 強制プッシュ
$ git push -f

rebaseは、vimでの編集作業となります。
編集によってコミットメッセージを変更する以外に、コミットを入れ替えたり、削除したりできます。
(複数人でリポジトリを共有している場合は、操作に注意が必要な場合があります。)
rebase処理がうまく行かなかった場合は--abortオプションで編集を取り消せます。

再コミットは通常pushだとエラーになるので、git push -fで強制プッシュします。

プッシュ

コミットが済んだらプッシュし、
ローカルリポジトリの内容を、リモートリポジトリに反映させます。

プッシュ
$ git push -u origin master
// 作業ブランチがmasterでなければ、次のコマンドでプッシュ
$ git push -u origin <current-branch-name>
// 2回目以降は、特にオプションをつけなくても、masterにプッシュしてくれる
$ git push
直前のプッシュ取り消し
$ git reset HEAD^

git reset HEAD^の後に管理対象の編集やコミット作業をやり直して強制プッシュすれば、
直前のプッシュをやり直すことができます。

プル

コミットやプッシュのやり直しで通常プッシュをした時に下のエラーを吐くことがあります。

error: failed to push some refs to 'git@github.com:***/***.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.

その時にgit pullしてしまうと、リモートの内容がローカルで編集していた内容に上書きされてしまい、
ややこしいことになるので注意してください。

参考

もくじに戻る

https://qiita.com/k73i55no5/items/9e0825cee4cc1cb078a6