JavaでAPIやバッチを開発していると、

Javaはコンパイルすると何になるのか
Javaの機能はどうやって呼び出されるのか
ShellからJavaを呼び出すのはなぜか
Javaから直接Javaの機能を呼ぶこともできるのか
新しく作るならShellとJavaのどちらがよいのか

といった疑問が出てくる。

これらは別々の話に見えるが、実際には、

プログラムをどう実行し、機能同士をどう接続するか

という一つの話としてつながっている。

1. そもそもJavaはどうやって実行される？

Javaでは、書いたソースコードをそのままCPUが実行しているわけではない。

Javaソースコード
Main.java
    ↓
javac
    ↓
Javaバイトコード
Main.class
    ↓
JVM
    ↓
インタプリタ / JITコンパイラ
    ↓
CPUが実行できる機械語

例えば、

public int add(int a, int b) {
    return a + b;
}

というJavaコードを書いたとする。

これをコンパイルすると、

Example.java
    ↓ javac
Example.class

となる。

.classファイルの中に入っているのがJavaバイトコードである。

Javaバイトコードは広い意味ではバイナリデータだが、

CPUが直接実行するネイティブ機械語ではない

という点が重要である。

JVM（Java Virtual Machine）がバイトコードを読み取り、実行する。

2. `.jar`とは？

Java開発では.jarというファイルもよく登場する。

大まかには、

複数の.classファイルや設定ファイルなどをまとめたもの

と考えると分かりやすい。

application.jar
│
├── Main.class
├── Service.class
├── Repository.class
└── 設定ファイルなど

Shellなどから、

java -jar application.jar

と実行できる。

3. ShellからJavaを呼び出す

バッチシステムなどでは、

ジョブ管理
    ↓
Shell
    ↓
Java
    ↓
業務処理
    ↓
DB / ファイル / 外部システム

という構成を取ることがある。

例えば、

java -jar batch.jar input.csv

のようにJavaプログラムを起動する。

Shellは、

Javaを起動
    ↓
引数を渡す
    ↓
終了を待つ
    ↓
終了コードを確認
    ↓
次の処理を決める

という処理の制御役を担当できる。

4. なぜShellを使うのか？

Shellには、

OS上のプログラムやファイルを簡単につなぎ合わせられる

という強みがある。

例えば、

Shell
 ├─ JavaバッチAを起動
 ├─ ファイル存在確認
 ├─ ファイルを移動
 ├─ JavaバッチBを起動
 └─ 終了コード確認

といった処理はShellが得意である。

5. JavaからJavaの機能を直接呼ぶこともできる

同じJavaアプリケーション内なら、普通のメソッド呼び出しとして実現できる。

Result result = functionA.execute();

if (result.isSuccess()) {
    functionB.execute(result);
}

例えばSpring Bootなら、

HTTP Request
    ↓
Controller
    ↓
Service A
    ↓
Service B
    ↓
Repository
    ↓
PostgreSQL

という構成も作れる。

6. Shell → Java と Java → Java の違い

Shell → Java

Shell
 ↓
Javaプログラム

Shellが別のプログラムを起動する。

java -jar batchA.jar

Java → Java

同じJVM・同じアプリケーションなら、

Java Application
 ├─ Service A
 │      ↓
 └─ Service B

として、

serviceB.execute(data);

のように直接呼び出せる。

7. ShellとJavaのメリット・デメリット

観点	Shell	Java
単純な処理の手軽さ	◎	○
プログラム起動	◎	△
OS操作	◎	△
ファイル操作	◎	○
複雑な業務ロジック	△	◎
型安全性	△	◎
エラー処理	△	◎
単体テスト	△	◎
IDE支援	△	◎
大規模化した場合の保守	△	◎

重要なのは、

ShellとJavaのどちらが優れているかではなく、何を担当させるか

である。

8. 一から作るならShellのほうが手軽なのか？

単純なプログラム起動ならShellはかなり手軽である。

java -jar functionA.jar

if [ $? -eq 0 ]; then
    java -jar functionB.jar
fi

一方、業務処理そのものを連携させるなら、

Result result = functionA.execute();

if (result.isSuccess()) {
    functionB.execute(result);
}

のようにJavaで表現したほうが自然な場合が多い。

9. 現在の開発では手軽さと可読性のどちらを取る？

基本的には、

最初に書くときの手軽さだけでなく、長期的な可読性・保守性を重視する

と考える。

ただし、

可読性重視
 ↓
何でもJava

という意味ではない。

単純な起動だけなら、

java -jar batch.jar

のほうがむしろ分かりやすい。

重要なのは、

その処理を最も単純に表現できる技術を使うこと

である。

10. プロセス・JVM・モジュール・サービスの境界は何が違うのか？

ここまで理解すると、次に重要になるのが**「境界」**である。

Javaシステムを見ていると、

モジュール
JVM
プロセス
サービス

という言葉が出てくる。

これらはすべて「何かを分ける」という意味を持っているが、分けているものが違う。

まず全体像を単純化すると、

OS
│
├─ Process A
│    │
│    └─ JVM
│         │
│         ├─ Module A
│         ├─ Module B
│         └─ Module C
│
└─ Process B
     │
     └─ JVM
          │
          ├─ Module D
          └─ Module E

さらに、これらのプロセスを独立したシステム機能として運用すると、

Service A
   │
   └─ Process
        └─ JVM
             ├─ Module A
             └─ Module B

             HTTP / Message

Service B
   │
   └─ Process
        └─ JVM
             └─ Module C

のような構成になることがある。

11. モジュールの境界

モジュールは、

コードや責務を整理するための境界

である。

例えば、

Application
│
├─ Contract Module
│
├─ Billing Module
│
└─ File Module

と分割する。

しかし、これらは同じJavaアプリケーションの中に存在できる。

billingService.calculate();

のように直接呼び出すことも可能である。

つまり、

Module A
   ↓ メソッド呼び出し
Module B

となる。

この場合、

同じプロセス
同じJVM
同じメモリ空間

で動いている可能性がある。

したがって、

モジュールを分けたからといって、プログラムそのものが別々に動いているとは限らない。

ここは非常に重要である。

12. JVMの境界

JVMは、

Javaバイトコードを実行するための実行環境

である。

例えば、

java -jar app.jar

と実行すると、通常そのJavaアプリケーションを動かすJVMが起動する。

イメージとしては、

JVM
│
├─ ContractService
├─ BillingService
├─ FileService
│
├─ Heap
├─ Threads
└─ Garbage Collector

となる。

同じJVMの中にいるJavaオブジェクト同士なら、

billingService.execute(data);

のような通常のJava呼び出しができる。

しかしJVMが分かれると、

JVM A

ContractService
      │
      │ 直接メソッド呼び出しはできない
      ↓
JVM B

BillingService

となる。

別JVMのJavaオブジェクトを、そのまま普通のJavaメソッドとして呼び出すことはできない。

そこで、

HTTP
RPC
Message Queue
Socket

などの通信方法が必要になる。

13. プロセスの境界

プロセスとは、

OSが管理する実行中のプログラムの単位

である。

例えば、

java -jar appA.jar
java -jar appB.jar

を別々に起動すると、通常は別々のJavaプロセスとして動く。

OS
│
├─ Process A
│    └─ JVM A
│         └─ appA
│
└─ Process B
     └─ JVM B
          └─ appB

プロセスが違えば、基本的にメモリ空間も分離される。

そのため、

Process A
    ↓
   ×
    ↓
Process B

と直接オブジェクトを渡すことはできない。

代わりに、

Process A
    ↓
HTTP / RPC / File / Message
    ↓
Process B

などを使う。

Shellから、

java -jar batchA.jar
java -jar batchB.jar

と起動する場合も、

Shell
 ├─ Java Process A
 └─ Java Process B

という境界が生まれる。

14. JVMとプロセスは何が違う？

ここは少し紛らわしい。

Javaアプリケーションでは多くの場合、

Java Process
     │
     └─ JVM

となるため、

「JVMが違う」

と

「Javaプロセスが違う」

がほぼ同時に起きる。

ただし概念としては、

Process
＝OSが管理する実行単位

JVM
＝Javaを実行する仮想マシン

であり、意味は違う。

15. サービスの境界

サービスは少し性質が違う。

サービスとは、

ある業務・機能上の責務を外部に提供する単位

として考えると分かりやすい。

例えば、

注文サービス
決済サービス
在庫サービス

という分割がある。

それぞれを独立したアプリケーションとして動かせば、

Order Service
     ↓ HTTP
Payment Service
     ↓ HTTP
Inventory Service

のようになる。

マイクロサービスでは特に、

Service A
・独立した責務
・独立したデプロイ

Service B
・独立した責務
・独立したデプロイ

という独立性が重要になる。

16. サービス = プロセスではない

ここも重要である。

「サービス」という言葉は論理的・アーキテクチャ的な概念であり、

「プロセス」はOS上の実行単位である。

そのため、

サービス
≠
必ず1プロセス

である。

例えば負荷が高くなれば、

Order Service

     ┌→ Process A
Request
     ├→ Process B
     │
     └→ Process C

のように、同じサービスを複数プロセス・複数インスタンスで動かすこともある。

Kubernetesなどで、

Order Service
│
├─ Pod A
├─ Pod B
└─ Pod C

とスケールさせるイメージにもつながる。

したがって、

サービスは「何を提供するか」の境界、プロセスは「どう実行されているか」の境界

と考えると区別しやすい。

17. 4つを比較する

境界	何を分ける？	分かれると何が起きる？
モジュール	コード・責務	コード上の依存関係を整理できる
JVM	Java実行環境	Javaオブジェクトを直接共有できなくなる
プロセス	OS上の実行単位	メモリ・実行状態などが分離される
サービス	システム・業務上の責務	API等を契約として独立して連携できる

つまり、分離のレベルが全部同じではない。

18. 具体例で考える

例えば、

契約
請求
ファイル出力

という3機能があるとする。

パターンA：同じJavaアプリケーション

1 Process
└─ 1 JVM
    │
    ├─ Contract Module
    ├─ Billing Module
    └─ File Module

呼び出しは、

billingService.execute();

のようにできる。

これはコード上では分割されているが、実行環境としては一緒である。

モジュラーモノリスなどでは、このような構造が考えられる。

パターンB：別Javaプログラムとして実行

Shell
│
├─ Process A
│    └─ JVM
│         └─ Contract
│
├─ Process B
│    └─ JVM
│         └─ Billing
│
└─ Process C
     └─ JVM
          └─ File

この場合、Javaプログラム同士は直接メソッド呼び出しできない。

Shell、ファイル、DBなどを介して処理をつなぐことになる。

パターンC：サービスとして分離

Contract Service
      │
      │ HTTP / Message
      ↓
Billing Service
      │
      │ HTTP / Message
      ↓
File Service

各サービスを独立して起動・デプロイできる。

ただし、その代わり、

ネットワーク通信
タイムアウト
リトライ
APIのバージョニング
障害時の扱い
分散トレーシング

など、分散システム特有の問題も考える必要が出てくる。

19. 境界を強くすると独立性は上がるが、コストも上がる

ここがアーキテクチャを考えるうえでかなり重要である。

同じJVMなら、

A
↓
B

というメソッド呼び出しだけで済む。

非常に速く、単純である。

一方、サービスを分けると、

Service A
 ↓
JSONへ変換
 ↓
HTTP
 ↓
Network
 ↓
Service B
 ↓
JSONをJavaオブジェクトへ変換

のような処理が必要になる。

さらにService Bが落ちている可能性もある。

つまり、

境界が弱い
↓
連携が簡単
↓
独立性が低い


境界が強い
↓
独立性が高い
↓
連携が複雑

というトレードオフがある。

そのため、

「分割できるから分割する」のではなく、「分割するメリットが複雑さを上回るか」を考える

必要がある。

20. Shellの話ともつながる

最初の疑問だった、

ShellからJavaを呼ぶのと、JavaからJavaを呼ぶのは何が違う？

も、境界として見ると理解しやすい。

Java
 ↓ メソッド
Java

＝同じJVM内で完結できる

一方、

Shell
 ↓
java -jar A.jar

Shell
 ↓
java -jar B.jar

なら、通常は、

Process A / JVM A

Process B / JVM B

というプロセス・JVMの境界ができる。

つまりShellを挟むことは、単なる「書き方の違い」ではなく、場合によっては実行単位そのものを分離する設計にもつながる。

21. 最終的に見るべきポイント

システムを見るとき、

「機能ごとに分かれています」

と言われただけでは、実は情報が足りない。

次のように考える必要がある。

機能は分かれている？
        ↓
コードのModuleだけ？

それとも
        ↓
別JVM？

それとも
        ↓
別Process？

それとも
        ↓
独立Service？

例えば、

機能A
機能B
機能C

と分かれていても、

1 JVM
├─ A
├─ B
└─ C

なのか、

JVM A
JVM B
JVM C

なのかでは、アーキテクチャとして全く意味が違う。

22. まとめ

Javaシステムを見るときは、次の4つを区別すると理解しやすい。

Module
    ↓
コード・責務の境界

JVM
    ↓
Java実行環境の境界

Process
    ↓
OS上の実行単位の境界

Service
    ↓
システム・業務責務の境界

そして、

1 Process
└─ JVM
   ├─ Module A
   ├─ Module B
   └─ Module C

という構成もあれば、

Service A
└─ Process / JVM

        ↓ HTTP

Service B
└─ Process / JVM

という構成もある。

重要なのは、

「機能が分かれているか」だけではなく、「どの境界で分かれているのか」を確認すること。

これが分かると、

モノリスなのか
モジュラーモノリスなのか
複数のバッチプログラムなのか
サービスとして分割されているのか
マイクロサービスなのか

を判断するための材料が増える。

そして設計するときも、

どこまでを同じJVMに置き、どこでプロセスを分け、どこを独立したサービスとして扱うのか

という形で考えられるようになる。

これはまさに、アーキテクチャにおける「境界を設計する」という考え方につながっている。