jvm
28 verified fixes JVM errors
Reproduced on pinned JDK images, fixed and re-checked.
28 errors
- Unrecognized VM option 'UseConcMarkSweepGC'
`Unrecognized VM option 'UseConcMarkSweepGC'` の直し方（Java 8 から 17 に上げたら JVM が起動しない）
eclipse-temurin@sha256:89dc1a6e09920ea26b2ede6fddfcac1a7508b50159a6d04c918a46132953aab6 · -XX:+UseConcMarkSweepGC (and the CMS/ParNew/Perm companion flags) carried in JAVA_OPTS since Java 8; CMS was obsoleted in JDK 14 and the flag name is gone from JDK 15 on, so the VM refuses to start before main()Java 8 で動いていたアプリを JDK 17 で動かすと、起動した瞬間に終わります。
JVM 9 min read - FileWriter の出力が文字化けする（JDK 18 以降・エラーは出ない）
出力ファイルの文字コードが JDK 18 以降で変わる（charset 未指定の FileWriter・エラーは出ません）
eclipse-temurin@sha256:68868d04fa9cfd5f5c6abec0b5cef86d8de2bf9c62c37c7d3e4f0f80f5cfd7ff · java.io.FileWriter / FileReader with no Charset argument (JEP 400 changed the JDK default charset to UTF-8 in JDK 18) · upgrading from JDK 17 to JDK 18 or later on a host whose locale is not UTF-8 — the same source writes different bytes with no exception and no warning, so the breakage only shows up in whatever reads the fileCSV が別のツールで開けない。ログの日本語が化ける。取り込みバッチが弾く。書き出しているアプリのほうは
JVM 7 min read - Unsupported class file major version 65
Unsupported class file major version 65 の直し方（Gradle が新しい JDK を読めない）
eclipse-temurin:21-jdk · Gradle 7.6.4's bundled ASM cannot read class file major version 65 (JDK 21) while parsing the build script itselfJDK を 21 に上げたあと、Gradle のビルドが次のエラーで落ちることがあります。
JVM 11 min read - Could not start Gradle Test Executor 1: Failed to load JUnit Platform.
Failed to load JUnit Platform の直し方（Gradle 9 で junit-platform-launcher の暗黙注入が消えた）
gradle@sha256:8894a410d9e3e2f744718ad7b3caff179b88f9f1ba2e35d247633eaf807d5a7e · Gradle 9.0+ (automatic loading of test framework implementation dependencies removed); junit-jupiter 5.12+ on Gradle 8 hits the same cause · gradle test without testRuntimeOnly junit-platform-launcher, after upgrading Gradle to 9.0+ (or after upgrading junit-jupiter to 5.12+ while staying on Gradle 8)Gradle を 9 に上げると、テストが 1 件も起動せずにビルドが止まります。
JVM 8 min read - does not "opens java.util" to unnamed module
InaccessibleObjectException: module java.base does not "opens java.util" の直し方
eclipse-temurin:17-jdk · setAccessible(true) on a JDK-internal field; strong encapsulation became the default in Java 16 (JEP 396) and --illegal-access was removed in 17 (JEP 403)Java 8 や 11 で動いていたアプリを Java 17 で起動すると、次の例外で落ちることがあります。
JVM 6 min read - package com.fasterxml.jackson.databind does not exist
package com.fasterxml.jackson.databind does not exist の直し方（Spring Boot 4 / Jackson 3 の部分改名）
maven@sha256:2b4496088e7b80ae10a8c9f74e574ea21380325a006ec684532ad6bad5bc7273 · spring-boot-starter-json (Spring Boot 4 ships Jackson 3: databind/core renamed to tools.jackson, while jackson-annotations stays at com.fasterxml 2.20) · upgrading Spring Boot 3.x to 4.0.0 with imports still on com.fasterxml.jackson.databind — annotations imports keep compiling on the same classpath, so only databind/core call sites failSpring Boot を 3 系から 4 に上げた直後のビルドが、次のコンパイルエラーで止まります。
JVM 6 min read - tools.jackson.databind.exc.MismatchedInputException: Cannot map `null` into type `int`
Cannot map `null` into type `int` の直し方（Spring Boot 4 / Jackson 3 で null が例外になる）
maven@sha256:2b4496088e7b80ae10a8c9f74e574ea21380325a006ec684532ad6bad5bc7273 · spring-boot-starter-json (Spring Boot 4 manages tools.jackson.core:jackson-databind:3.0.2, where FAIL_ON_NULL_FOR_PRIMITIVES defaults to enabled) · upgrading Spring Boot 3.x to 4.0.0 with a primitive int field receiving JSON null — same code and JSON succeed on Boot 3.4.1 by silently converting null to 0Spring Boot 3 系で動いていた JSON のデシリアライズが、Boot 4 に上げると次の例外で止まります。
JVM 6 min read - package javax.mail does not exist
package javax.mail does not exist の直し方（jakarta.mail-api は 2.0.0 から中身が jakarta.mail になる）
eclipse-temurin:17-jdk · jakarta.mail:jakarta.mail-api (the Maven coordinate moved from com.sun.mail:javax.mail at 1.6.3, but its classes stayed in javax.mail; the package moves to jakarta.mail only at 2.0.0) · bumping jakarta.mail-api from 1.6.x to 2.x while imports still say javax.mail — the coordinate already said jakarta, so the migration looked done依存を jakarta.mail:jakarta.mail-api に切り替えて版を上げたら、コンパイルが次のエラーで止まることがあります。
JVM 6 min read - java.lang.NoClassDefFoundError: javax/servlet/Filter
NoClassDefFoundError: javax/servlet/Filter の直し方（自分は jakarta に移行したのに、依存が javax を要求する）
eclipse-temurin:17-jdk · spring-web / spring-context (Spring 5's GenericFilterBean implements javax.servlet.Filter; Spring 6's implements jakarta.servlet.Filter — the app itself references neither) · running a jakarta.servlet application that still has a pre-Jakarta library on the classpath — it compiles when nothing in your own source statically references the old library's typesjakarta.servlet へ移行して、自分のコードから javax.* の import を全部消した。コンパイルも通る。
JVM 7 min read - java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
NoClassDefFoundError: javax/xml/bind/JAXBException の直し方（Java 11 以降で JAXB が JDK から消えた）
eclipse-temurin:17-jdk · JEP 320 removed the Java EE modules in Java 11; a class built for Java 8 fails at runtime on 17Java 8 では動いていたアプリを Java 11 や 17 で起動すると、次のエラーで落ちることがあります。
JVM 8 min read - cannot find symbol
Lombok の getter が cannot find symbol になる（JDK 23 以降は注釈処理が既定で走らない）
eclipse-temurin@sha256:68868d04fa9cfd5f5c6abec0b5cef86d8de2bf9c62c37c7d3e4f0f80f5cfd7ff · javac annotation processing default policy (JDK 23 stopped running class-path-discovered processors implicitly) + Lombok 1.18.x + maven-compiler-plugin 3.13.0 · upgrading the build JDK to 23 or later with Lombok declared only as a normal compile-scope dependency — the processor never starts, so every call to a generated accessor fails with cannot find symbol and nothing in the error names Lombok@Getter を付けたフィールドの getter が、コンパイルの時点で存在しないものとして扱われます。
JVM 9 min read - Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
Tests run: 0 のままビルドが成功する（JUnit 4 のテストを JUnit 5 のエンジンが拾っていない）
eclipse-temurin@sha256:68868d04fa9cfd5f5c6abec0b5cef86d8de2bf9c62c37c7d3e4f0f80f5cfd7ff · maven-surefire-plugin provider auto-detection + JUnit Platform engines (junit-jupiter-engine discovers only org.junit.jupiter.api.Test; junit-vintage-engine is what discovers org.junit.Test) · adding JUnit 5 to a project that still has JUnit 4 tests without also adding junit-vintage-engine — Surefire switches to the JUnit Platform provider, no engine claims the JUnit 4 tests, and the build reports Tests run: 0 with BUILD SUCCESSmvn test は成功します。終了コードは 0、赤くなる箇所もありません。実行されたテストだけが 0 件です。
JVM 8 min read - JaCoCo のカバレッジ母数が減る（Lombok 更新後も BUILD SUCCESS）
Lombok を上げると JaCoCo のカバレッジ母数が縮む（率は上がり、閾値は通る）
eclipse-temurin@sha256:68868d04fa9cfd5f5c6abec0b5cef86d8de2bf9c62c37c7d3e4f0f80f5cfd7ff · Lombok 1.18.34+ (adds lombok.@Generated to generated members by default) + jacoco-maven-plugin (filters members annotated @Generated since 0.8.2) · bumping Lombok past 1.18.32 in a project measured with JaCoCo — generated accessors leave the coverage denominator, so the reported ratio rises and a jacoco:check threshold that was failing starts passing, with no error, no warning and no test added変えたのは Lombok の版だけ。ソースもテストも JaCoCo の版もそのままで、カバレッジレポートの数字が入れ替わります。
JVM 7 min read - Java 25 (69) is not supported by the current version of Byte Buddy which officially supports Java 23 (67)
Java 25 (69) is not supported by the current version of Byte Buddy の直し方（Mockito が引く Byte Buddy が JDK の版を知らない）
maven@sha256:1b1fc6d0168ea616afd1c861d6f32ec37c9ec2ffe88a0351b3771dd4ad86b0d8 · mockito-core 5.13.0 (pulls net.bytebuddy:byte-buddy 1.15.0 transitively, which knows class file versions up to 67 / Java 23) · raising the JDK to 24 or later while mockito-core stays pinned — javac and the application still work, only Mockito's inline mock maker stops, and the top of the exception chain names the user's own classJDK を上げたあと、アプリケーションのコードも pom.xml のテスト依存も変えていないのに、モックを作るテストだけが落ちます。コンソールに最初に出るのは、自分が書いたクラスの名前です。
JVM 10 min read - Public Key Retrieval is not allowed
Public Key Retrieval is not allowed の直し方（MySQL 8・allowPublicKeyRetrieval を足す前に）
mysql@sha256:7dcddc01f13bab2f15cde676d44d01f61fc9f99fe7785e86196dfc07d358ae2b · com.mysql:mysql-connector-j 8.0.33 · connecting to MySQL 8 with useSSL=false as a caching_sha2_password user (the server's auth cache is cold)MySQL を 5.7 から 8 に上げた直後、アプリのコードも接続 URL も変えていないのに、Java の接続だけが落ちるようになります。
JVM 9 min read - java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer; の直し方
eclipse-temurin:17-jdk · built with -source/-target 8 on JDK 17 (which does not restrict the API), then run on a Java 8 JVM; Buffer methods became covariant in Java 9新しい JDK でビルドしたアプリを古い JVM で動かすと、次のエラーで落ちることがあります。
JVM 5 min read - org/postgresql/shaded/com/ongres/scram/client/ScramClient$ChannelBinding
NoClassDefFoundError: .../scram/client/ScramClient$ChannelBinding の直し方（pgjdbc 42.2.0 だけ SCRAM の実装が入っていない）
postgres@sha256:33f923b05f64ca54ac4401c01126a6b92afe839a0aa0a52bc5aeb5cc958e5f20 · org.postgresql:postgresql 42.2.0 — the release that added SCRAM-SHA-256 support but shipped a jar without the shaded scram/client package (fixed in 42.2.1) · following the common advice to upgrade pgjdbc to 42.2.0 or later after hitting 'The authentication type 10 is not supported', and landing exactly on 42.2.0 — the first error disappears and the SCRAM handshake stops on a missing class insteadPostgreSQL への接続が認証タイプ 10 で落ちたので pgjdbc を「SCRAM 対応版」に上げた——その直後に、
JVM 6 min read - The authentication type 10 is not supported
The authentication type 10 is not supported の直し方（PostgreSQL の scram-sha-256 に古い pgjdbc で接続している）
postgres@sha256:33f923b05f64ca54ac4401c01126a6b92afe839a0aa0a52bc5aeb5cc958e5f20 · org.postgresql:postgresql (pgjdbc) — SCRAM support first appeared in 42.2.0, and the shipped implementation from 42.2.1 · connecting to a PostgreSQL 14 or later server (or any server whose password_encryption is scram-sha-256) with a pgjdbc older than 42.2.0 — the error text points at pg_hba.conf, but the connection stops because the driver cannot read authentication request code 10 (AuthenticationSASL)PostgreSQL のサーバを上げた、あるいは新しいマネージドの PostgreSQL に向けた直後から、Java のアプリが接続で
JVM 8 min read - Failed to create a Robolectric sandbox: Android SDK 36 requires Java 21 (have Java 17)
Android SDK 36 requires Java 21 (have Java 17) の直し方（Robolectric）
eclipse-temurin:17-jdk · Robolectric test requesting Android SDK 36 while the test JVM is Java 17Robolectric のテストが、実行の直前に次のエラーで落ちます。
JVM 8 min read - WorkManager is not initialized properly
`WorkManager is not initialized properly` の直し方（Robolectric のテストで WorkManager を取り出せない）
eclipse-temurin@sha256:89dc1a6e09920ea26b2ede6fddfcac1a7508b50159a6d04c918a46132953aab6 · WorkManager.getInstance() in a Robolectric test where no startup initializer ran; the fix is WorkManagerTestInitHelper.initializeTestWorkManager() from androidx.work:work-testing, which yields a WorkManager driven by TestScheduler (a TestDriver you can advance)Robolectric のテストで WorkManager.getInstance(context) を呼ぶと、テストが例外で落ちます。
JVM 6 min read - A command line option has attempted to allow or enable the Security Manager
A command line option has attempted to allow or enable the Security Manager（JDK 24 以降で JVM が起動しない）の直し方
eclipse-temurin@sha256:68868d04fa9cfd5f5c6abec0b5cef86d8de2bf9c62c37c7d3e4f0f80f5cfd7ff · -Djava.security.manager=allow left in JVM args from the JDK 18 workaround; JEP 486 makes the same flag refuse VM startup from JDK 24Java 21 まで動いていたアプリを JDK 25 で起動すると、アプリのログが 1 行も出ないまま、次のエラーで終わることがあります。
JVM 9 min read - Socket constructor does not support creation of datagram sockets
Socket constructor does not support creation of datagram sockets の直し方（JDK 25 で古い Socket コンストラクタが例外になる）
eclipse-temurin@sha256:68868d04fa9cfd5f5c6abec0b5cef86d8de2bf9c62c37c7d3e4f0f80f5cfd7ff · JDK 25 (Socket(InetAddress,int,boolean) with stream=false now throws IllegalArgumentException; deprecated-for-removal through 24) · legacy code using new Socket(addr, port, false) to make a UDP/datagram socket, run on JDK 25 where the deprecated stream=false path throws IllegalArgumentException (JDK 17/21/24 only warned)長く使ってきた new Socket(address, port, false) の形が、JDK 25 に上げると実行時に次の例外で止まります。
JVM 6 min read - package javax.persistence does not exist
package javax.persistence does not exist の直し方（Spring Boot 3 で javax.persistence が消える）
eclipse-temurin:17-jdk · spring-boot-starter-data-jpa (Spring Boot 3 carries the Jakarta EE 9 namespace, so javax.persistence is absent from the compile classpath; Spring itself did not rename it) · upgrading Spring Boot 2.x to 3.x with entity imports still on javax.persistence — the version bump, not any Spring setting, changes which namespace is on the classpathSpring Boot 2 系で動いていたアプリを 3 系に上げると、エンティティのコンパイルが次のエラーで止まります。
JVM 5 min read - Spring Boot 4 で Flyway の migration が実行されない（起動は成功する）
Spring Boot 4 で Flyway の migration が実行されない（flyway-core だけでは自動設定が入らない）
maven@sha256:2b4496088e7b80ae10a8c9f74e574ea21380325a006ec684532ad6bad5bc7273 · spring-boot 4.0.0 with flyway-core only (the Flyway auto-configuration moved to the separate spring-boot-flyway module, reached through spring-boot-starter-flyway) · upgrading to Spring Boot 4 while keeping a direct flyway-core dependency — the application still starts and logs nothing about Flyway, so the missing schema only surfaces when code first touches a migrated table, typically on a clean database in CI or a new environmentSpring Boot を 4 に上げたあと、アプリケーションは今までどおり起動します。 起動ログに Flyway の行は出ず、エラーも警告も出ません。止まるのは、migration で作られるはずだったテーブルに最初にアクセスした時点です。
JVM 6 min read - Maven のテスト失敗メッセージだけ文字化けする（surefire-reports のファイルは無事）
テストの失敗メッセージだけ文字化けする（JDK 18 以降は stdout だけ native encoding のまま）
maven@sha256:c3c9d3ac4ce8431a3995c0318b8d390f448e693dd4fabc16e9b68d2e1f3d7b46 · maven-surefire-plugin 3.5.4 on Eclipse Temurin 21.0.11 (JEP 400 applies to file.encoding only; stdout.encoding / stderr.encoding became standard properties in JDK 19) · moving from JDK 17 to JDK 18 or later in a container or CI whose locale is not UTF-8 — the Surefire report file turns UTF-8 while the console keeps writing in the native encoding, so only the failure message on the console is unreadableMaven でテストを走らせると、失敗したテストの説明文だけが読めない文字列になります。アサーションのメッセージに
JVM 9 min read - has been compiled by a more recent version of the Java Runtime (class file version 61.0)
UnsupportedClassVersionError: class file version 61.0 の直し方（Java）
eclipse-temurin:17-jdk · class compiled with a newer JDK executed on an older JVM (release 17 -> Java 8)Java 8 のまま動いていたアプリを、新しい JDK でビルドし直した。あるいは CI の JDK だけが上がった。すると実行時にこれが出ます。
JVM 6 min read - Unrecognized VM option 'UseBiasedLocking'
`Unrecognized VM option 'UseBiasedLocking'` の直し方（JDK 17 から 21 に上げたら JVM が起動しない）
eclipse-temurin@sha256:1eeacc8c295ed4805f6ffead2417b1936aad296b02ea9e56b457230befc9e98d · -XX:+UseBiasedLocking left in JAVA_OPTS; it warns but starts on JDK 17 (LTS), is ignored on 18, and is unrecognized from 19 on — so an LTS-only 17 to 21 migration never sees the version-naming noticeLTS を 17 から 21 に上げたら、アプリが起動しなくなります。
JVM 9 min read - Unrecognized option: -Xnoagent
Unrecognized option: -Xnoagent の直し方（JDK 23 以降で JVM が起動しない）
eclipse-temurin@sha256:83177670e43c17769a5402a60601545318e45e63adf634fb5022340e516cded4 · A legacy -X launcher option (-Xnoagent, -Xfuture, -checksource) left in JVM args; the java launcher rejects it as an unrecognized option once the JDK removes itデバッグ用の起動オプションを昔からそのまま持ち回っているプロジェクトが、JDK 23 で止まります。
JVM 6 min read
条件に一致するエラーはありません。フィルタを緩めてください。