2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

2026年!初アウトプットをしよう
@noah-devtech

Processing 4を他のIDEで書きたいんじゃい！【Gradle + Java 17向けテンプレート】

Last updated at Posted at 2026-01-04

この記事は「ProcessingをPDE以外のIDE（IntelliJ / VS Code / Eclipse 等）で書きたい人」向けです。
こんな人におすすめです。

  • ProcessingをIntelliJ/VS Code等で書きたい
  • P2D/P3Dレンダラーを使いたい
  • チーム開発やバージョン管理をしっかりやりたい

ご案内
今回のこのプロジェクトで初めてGradleやKotlinに触れ、Java自体も勉強し始めなので、
設計やベストプラクティスの観点で至らない点があるかもしれません。
気づいた点があれば、コメントやIssue/PRでフィードバックをいただけると嬉しいです。

動機

私の学部学科、コース、研究室では作品を作る、可視化を行う場合によくProcessingを用います。
確かにProcessingはインタラクティブアートやデータビジュアライゼーションをしたい初心者でも使いやすい面白いプログラミング言語（厳密にはJavaをベースにした開発環境／フレームワーク）だなと思います。

ただそれでも他のIDEを使って書きたい！と思ったのは次のような理由からです。

  1. オートコンプリートの弱さ
    クラス名やメソッド名の補完が限定的であること。

  2. シンタックスハイライト
    配色の自由度が低く、設計が雑になりがちな僕にとってはより見づらかったこと。

  3. エラーメッセージの曖昧さ
    実行時にエラーが発生した際、どこの行でエラーが起きているのか等エラーメッセージが見づらかったこと。

  4. デバッガーの操作性
    組み込みのデバッガーは存在しますが、変数の監視やステップ実行の使い勝手が悪かったこと。

  5. PythonモードがJython
    ProcessingにもPythonを使って書けるPython Modeというものがありますが、一般的に使われるCPythonではなくJavaによるリファレンス実装のJythonを用いています。
    これによってCPythonとは違った動作があったりして開発スピードが特徴であるはずのPythonを上手く活かせていないこと。

などがあります。
要するに 「Processing のお作法はそのままに、IDE や Java/Gradle のエコシステムの恩恵を全部受けたい！」 というのが今回のモチベーションです。

幸い公式のProcessingコミュニティがMaven CentralにProcessingのコアライブラリをアップロードしてくれています。
2026年1月4日現在でPre-releaseのProcessing4.5まで既にあがっているので、すぐにGradle/Mavenで使えなくなるということはないんじゃないかなと個人的に思います。

我々を阻む壁

「Gradleで org.processing:core を読み込めば終わりでしょ？」
最初はそう思っていましたが、甘かったです。
難しいことをしようとすると他の問題が発生してくるかもしれませんが、私は以下のような壁にぶつかりました。

P2D/P3Dレンダラーのライブラリ

ざっくり言うと、P2D/P3Dを使うには「OSごとに違うOpenGLネイティブライブラリ」を拾ってこないと動かない、という問題があります。
Processing 4.x（P2D/P3Dレンダラー）は、裏側で OpenGL を使用しており、JavaからOpenGLを触るためのライブラリ JOGL (Java Binding for the OpenGL API) と GlueGen に依存しています。

processing-core だけを依存関係に入れても、実行時に「JOGLがない」と怒られます。
さらにJOGLはOS（Windows, macOS, Linux）やCPUアーキテクチャ（amd64, arm64）ごとに異なる ネイティブライブラリ を要求します。

自分のPCだけで動けばいいならハードコードでもいいですが、

  • 「Windowsの友人にコードを渡したら動かない」
  • 「MacをIntelからM1に買い替えたら動かない」

といった悲劇（おま環）が容易に起こります。

Java 17の「モジュールシステム」

依存関係をすべて解決し、いざ実行！という段階になって、Java 17（Processing 4の推奨環境）が立ちはだかります。

こちらもざっくり言うと、「昔はこっそり触れていたJavaの内部APIに、Java 17からは原則アクセスできなくなった」 ため、そのままではJOGLが動かない、という問題です。
Processingが使用しているOpenGLライブラリ（JOGL）は、高速な描画を実現するために、Javaの標準的な画面描画の仕組み（AWT/Swing）の「裏側」に直接アクセスする必要があります。しかし今のJavaでは内部構造（sun.* パッケージ など）へのアクセスが厳格に禁止されています（強いカプセル化）。

全部入りのテンプレートを作りました

上記の「めんどくさいこと」を全て build.gradle.kts に押し込め、誰でも・どのOSでも・一発で起動できるテンプレートリポジトリを作成しました。

注意

  • Processing 4.3.3 時点での動作確認です。マイナーアップデートでレンダラー周りの動作が変わることは稀ですが、将来のバージョンで挙動が変わる可能性があります。
  • Video / Sound ライブラリはまだサポートしていません（今後対応予定）。
build.gradle.kts
plugins {
    id("java")
    id("application")
}

group = "org.example"
version = "1.0-SNAPSHOT"

repositories {
    mavenCentral()
    maven { url = uri("https://jogamp.org/deployment/maven") }
}

java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(17))
    }
}

val processingVersion = "4.3.3"
val joglVersion = "2.5.0"

dependencies {
    // kotlin-stdlib
    implementation("org.jetbrains.kotlin:kotlin-stdlib:2.2.20")
    // Processing Core
    implementation("org.processing:core:$processingVersion")

    // JOGL & GlueGen
    val joglModules = listOf("jogl", "nativewindow", "newt")

    joglModules.forEach { module ->
        implementation("org.jogamp.jogl:$module:$joglVersion")
    }
    implementation("org.jogamp.gluegen:gluegen-rt:$joglVersion")

    // Native libraries for each platform
    val platforms = listOf("windows-amd64", "macosx-universal", "linux-amd64")
    platforms.forEach { platform ->
        joglModules.forEach { module ->
            runtimeOnly("org.jogamp.jogl:$module:$joglVersion:natives-$platform")
        }
        runtimeOnly("org.jogamp.gluegen:gluegen-rt:$joglVersion:natives-$platform")
    }

    testImplementation(platform("org.junit:junit-bom:5.10.0"))
    testImplementation("org.junit.jupiter:junit-jupiter")
}

application {
    mainClass.set("org.example.Main")
    applicationDefaultJvmArgs =
        listOf(
            "--add-exports=java.desktop/sun.awt=ALL-UNNAMED",
            "--add-opens=java.desktop/sun.awt=ALL-UNNAMED",
            "--add-exports=java.desktop/sun.java2d=ALL-UNNAMED",
            "--add-opens=java.desktop/sun.java2d=ALL-UNNAMED"
        )
}

tasks.withType<JavaCompile> {
    options.encoding = "UTF-8"
}

tasks.run {
    standardInput = System.`in`
}

このテンプレートがやっていること（技術的な解決策）

このリポジトリの build.gradle.kts では、前述の課題を以下のように解決しています。

  1. JOGL依存関係とネイティブライブラリの自動解決
    platforms リストに windows-amd64, macosx-universal, linux-amd64 の3つを定義し、ループを回してそれら全てのネイティブライブラリを runtimeOnly で一括投入しています。これにより、WindowsでもMacでもLinuxでも、Gradleが勝手に適切なライブラリを引っ張ってきます。
    JOGLやGlueGenはProcessingの内部が依存しているのでimplementation としていますがネイティブライブラリはruntimeOnly で大丈夫です。

    val joglModules = listOf("jogl", "nativewindow", "newt")
val platforms = listOf("windows-amd64", "macosx-universal", "linux-amd64")

// 全プラットフォームのネイティブライブラリをRuntime依存に追加
platforms.forEach { platform ->
    joglModules.forEach { module ->
        runtimeOnly("org.jogamp.jogl:$module:$joglVersion:natives-$platform")
    }
    runtimeOnly("org.jogamp.gluegen:gluegen-rt:$joglVersion:natives-$platform")
}

  2. Java 17 起動オプションの自動付与
    InaccessibleObjectException を回避するためのJVMオプション（--add-opens 等）を、application プラグインの設定に埋め込みました。 ユーザーがコマンドライン引数を手入力する必要はありません。

    application {
    applicationDefaultJvmArgs = listOf(
        "--add-exports=java.desktop/sun.awt=ALL-UNNAMED",
        "--add-opens=java.desktop/sun.awt=ALL-UNNAMED",
        // ...他多数
    )
}

使い方（クイックスタート）

  1. リポジトリをClone（またはDownload）

    git clone https://github.com/noah-devtech/Processing4-Gradle-Template.git

  2. ディレクトリ移動 & 実行
    Gradle Toolchainが自動で用意してくれるので手動でのJava 17のインストールすら不要なはずです。

    # Windows
gradlew.bat run

# macOS / Linux
chmod +x gradlew
./gradlew run

  3. 開発開始
    src/main/java/org/example/Main.java を好きなIDEで開いて書くだけ！

今後の展望（ToDo）

現状は「とりあえず動く最小構成」ですが、もっと便利にするために実装したい機能がいくつかあります。
（もし「これ欲しい！」とか「実装したよ！」という方がいれば、IssueやPRをお待ちしています！）

1. 配布用Jar（Fat Jar）生成のサポート

現状は gradle run での開発実行のみですが、作品を友人に配布したり展示したりするためには、依存ライブラリをすべて含んだ単一のJarファイル（Fat Jar / Shadow Jar）を生成する必要があります。
Gradleの Shadow プラグインなどを導入して、コマンド一発で .exe や .jar を書き出せるようにしたいです。

2. Processing標準ライブラリ（Video, Sound等）の導入サポート

Core以外のライブラリ（特に Video や Sound）も、Core同様にネイティブライブラリへの依存が激しく、導入が面倒です。
これらを簡単に取り込めるような仕組み（依存関係のプリセット化など）を build.gradle.kts に組み込みたいと考えています。

3. プラットフォーム最適化

今現在はとりあえずcloneして実行できるようにすべてのプラットフォーム向けのネイティブライブラリを引っ張って来るようにしています。ただいざ成果物を他人に配布したりするなどの場合、全部入りのままだと嬉しくはありません。
そのため ビルド時の引数やOS判定ロジックを用いて、特定のバイナリのみをダウンロードする ことにも取り組みたいです。

run や build では全てのプラットフォーム向けライブラリをダウンロードしつつ、
配布用ビルドではターゲットOSだけを選んで含めるような installDist タスクを用意したい、というイメージです。

4. data フォルダの自動コピー設定

Processingのスケッチでは、画像やフォントなどの資産を data フォルダに置くのが標準です。しかし、IDE経由で実行するとカレントディレクトリ（Working Directory）がプロジェクトルートになったりして、loadImage("data.png") が失敗することがよくあります。
Gradleのタスク設定でこのあたりを自動解決し、「いつもの場所に置けば動く」状態を目指したいです。

おわりに

Processing標準のエディタも手軽で良いですが、規模が大きくなってくるとIDEのパワーが恋しくなります。
「ProcessingをJavaで書きたいけど環境構築で挫折した」という過去の自分のような人の助けになれば幸いです。

謝辞

本テンプレートを作成するにあたり、P2D/P3Dレンダラーの起動エラー（JOGLのネイティブライブラリ周り）の原因究明において、Katsuya Endoh様 (enkatsu) に多大なるご協力をいただきました。この場を借りて深く感謝申し上げます。

参考文献

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?