Javaでアプリを作るときは、新規Android、既存Androidの保守、業務用Webのどれかを最初に区別します。
同じJavaでも、必要な画面技術、実行環境、配布方法は用途ごとに異なります。
既存資産を活かすのか、新しい製品を作るのかが、言語を継続する判断の分かれ目です。
Javaを含む開発方式や依頼先を目的別に整理したガイドでは、既存システムの改修と新規開発を相談する際の論点をまとめています。
| 開発対象 | Javaの位置付け | 最初の判断 |
|---|---|---|
| 既存Androidアプリ | 現行コードを保守する主要言語 | Java資産とKotlin追加部分の境界 |
| 新規Androidアプリ | 選択可能だがKotlinも比較 | 公式API、チーム経験、既存部品 |
| 業務Web、API | サーバー側の業務処理 | 実行環境、データベース、運用体制 |
| PC向けツール | JVM上で動く処理と画面 | 配布先のJDKと更新方法 |
Javaを続ける理由を開発対象ごとに分ける
Javaは言語だけでなく、JDK、ビルドツール、ライブラリ、実行環境と組み合わせて使います。
Oracleが提供するLearn Javaでは、言語の基礎からクラス、例外、コレクションなどを学ぶ経路が整理されています。
一方、Android DevelopersはAndroidをKotlinファーストで開発する方針を明示しています。
| 状況 | Javaを選ぶ根拠 | Kotlinも比べる理由 |
|---|---|---|
| 既存Androidの小改修 | 既存コードとテストを保ちやすい | 新しい画面やAPIの公式例を追いやすい |
| 新規Android | Java経験者を活かせる | 新規機能の資料やライブラリとの整合 |
| 業務API | JVM資産と運用知識を使える | Androidとは別問題として扱う |
既存Androidでは、全体を書き換えることと、今後の新機能だけKotlinで書くことを分けて検討します。
新規Androidでは、Javaを使えるという理由だけで決めず、対象APIの公式例、採用予定のライブラリ、保守担当者が追える資料を確認します。
在庫APIは要求から保存までの責任を分ける
業務用途のJavaは、商品、顧客、申請などの記録をWeb APIで扱う場面に向きます。
SpringのRESTful Web Serviceの公式ガイドは、HTTP要求を受けてJSON応答を返す小さな例を示しています。
在庫照会APIなら、次の責任を別の部品へ分けます。
- ControllerはURL、入力値、HTTPの応答形式を扱います。
- Serviceは引当可能数や公開範囲などの業務ルールを判断します。
- Repositoryはデータベースへの検索と保存を担当します。
- Domain Modelは商品、倉庫、在庫移動の状態を表します。
- 監査ログは誰がいつ在庫を変えたかを追跡できる形で残します。
Springのサンプル構成を入口にしつつ、実務では認証、入力検証、永続化、例外処理を追加します。
在庫数をControllerで直接計算すると、バッチ処理や別APIから同じルールを使えなくなるため、業務判断をServiceへ集めます。
JDK、ビルド、実行環境を配布契約にする
Javaファイルがコンパイルできても、利用者やサーバーで同じように動くとは限りません。
JDKの版、ビルド手順、依存ライブラリ、起動引数、文字コード、タイムゾーンを配布契約として記録します。
OracleのJava学習ドキュメントで言語機能を確認した後は、プロジェクトが利用するJDKとビルドツールの版を固定します。
| 契約項目 | 記録する内容 | ずれたときの症状 |
|---|---|---|
| JDK | ベンダーとメジャー版 | 起動不能、利用APIの差 |
| 依存関係 | 名前、版、取得元 | ビルド失敗、挙動変更 |
| 設定 | 環境変数と既定値 | 接続先や機能の誤動作 |
| 地域条件 | 文字コード、時刻、ロケール | 文字化け、日付ずれ |
| 起動方法 | コマンド、権限、監視 | 再起動不能、ログ欠落 |
開発者のPCだけにある設定をなくし、空の環境から同じ配布物を作れるかを確認します。
サーバー運用では、実行中のJava版、アプリ版、設定の識別子を障害時に取得できるようにします。
AndroidのJava資産は境界を決めて更新する
既存AndroidアプリへKotlinを追加する場合は、画面単位や機能単位で境界を切ります。
AndroidのKotlinファーストの説明は、Javaとの相互運用を前提に新しいコードをKotlinで書く選択肢を示しています。
移行候補は、変更頻度、不具合件数、テストの有無、外部APIへの依存で並べます。
ほとんど触らない安定したJavaコードを先に変えるより、仕様変更が続くがテストを追加できる機能から境界を整える方が効果を測れます。
移行前後で、起動時間、画面遷移、通信結果、クラッシュ件数を同じ端末条件で比べます。
言語の置換自体を目的にせず、保守の負担や新しいAPIへの追随が改善したかを判定します。
Javaアプリは運用シナリオで完成を判定する
業務アプリでは、正常な一件登録だけでなく、同時更新、入力やり直し、再起動、データ移行が起きます。
リリース判定には、機能テストとは別に運用シナリオを用意します。
- 同じ在庫を二人が更新したとき、片方の変更が無言で消えないことを確認します。
- データベース接続が切れたとき、再試行可能な失敗と運用対応が必要な失敗を分けます。
- 新版でデータ構造が変わる場合、移行前後の件数と合計値を照合します。
- アプリを再起動しても処理中の要求を二重実行しないことを確認します。
- 旧版へ戻す条件と、戻せないデータ変更をリリース前に共有します。
Androidでも業務Webでも、実行環境とデータを含めて再現できることが保守性につながります。
Javaのコード品質だけでなく、ログ、監視、配布手順、移行証拠までを完成条件に含めます。
Javaアプリ開発のよくある質問
Javaで新しいAndroidアプリを作るべきですか？
既存資産やチーム経験によっては選択できますが、新規開発ではKotlinも比較します。
対象APIの公式例、使うライブラリ、保守担当者、Java資産との境界を確認し、言語の好みだけで決めないことが重要です。
Javaは業務Webアプリに向きますか？
JVMの運用経験や既存ライブラリがあり、複数の業務ルールとデータを長期保守する用途では有力です。
規模だけで決めず、実行環境、監視、データ移行を担当できる体制まで含めて評価します。
Javaの実行環境はどう管理しますか？
JDKのベンダーと版、ビルドツール、依存関係、起動引数、文字コード、タイムゾーンを文書と自動化へ残します。
開発環境と本番環境で同じ配布物を使い、稼働中の版をログや監視から特定できるようにします。
Javaは既存資産と運用契約を結んで使う
Javaの採否は言語機能だけでなく、残したい資産と支えられる実行環境で決まります。
- 新規Androidと既存Android保守ではJavaを選ぶ理由が異なります。
- 業務APIはHTTP、業務ルール、保存、監査の責任を分けます。
- JDK、依存関係、設定、地域条件、起動方法を配布契約として固定します。
- Kotlinへの移行は変更頻度とテスト可能性から対象を選びます。
- 完成判定には同時更新、障害、再起動、データ移行を含めます。
ブラウザとサーバーを同じ言語系で構成する案は、JavaScriptによるWeb、モバイル開発の比較で実行環境ごとの境界を確認できます。
