[疑問]JVMCFRE 003 bad major version,offset=6
今日のDeploy静的リソースパッケージは、データベース接続情報、SQLクエリー文などの静的リソースファイルにのみ適用されます.導入に成功した後、サービスを開始すると次のエラーが発生しました.
分析と調査を経て、我々はローカルRAD(eclipseの一種)のJDK level問題と考え、server上のjavaバージョンは1.7であり、Antパッケージに関するsourceとtargetはいずれも1.7であるが、ローカルRADのJDKコンパイルバージョンは1.8であり、それを1.7に変更し、パッケージ配置後、プロセスは正常に起動した.
この問題について、ネット上では「高バージョンのJDKコンパイルJava classファイルを使用して低バージョンのJVM上で実行しようとしているため」と一般的に言われているため、解決策は通常、ローカルJDKコンパイル環境を変更するものであり、典型的な例はこれである:UnsupportedClassVersionError: JVMCFRE003 bad major version in WebSphere AS 7.しかし、このcaseでは、私のdeployの部分はコンパイルされたclassには関与していません.2つの疑問があります offset=6ってどういう意味ですか? JDKコンパイル環境バージョンは静的リソースのコンパイルに影響しますか?
この部分を自動化パッケージおよび導入ツール(UCD)を用いて導入するのは初めてである.生産環境なので、このChangeをする前はまだ緊張していましたが、予想される問題は主に2つあります:1,Deploy process問題,2,静的資源の文字化けし問題.1つ目は確かに少し故障してbinパスの変更はありませんが、processのステップで「allow failure」が選択されていないので、binフォルダをコピーするときにフォルダが空のエラーと報告して実行を停止します.allow failureを選択すればよい.2,文字化けしの問題は従来通りであるが,このバージョンの変更ではcurrency記号「ファイルは東欧コードISO-8859-2の形式でしか保存できない.これには、utf 8および他のフォーマットの符号化に対するソースコードの処理ロジックをさらに調べる必要がある.今度は予想していた問題が起こらなかったのに、変な問題が出て、みんな緊張していたので、問題はもう解決した.しかし、もっと調査が必要です.
how to check the jdk version used to compile a .class file - duplicate
Exception in thread "main" java.lang.UnsupportedClassVersionError: JVMCFRE003 bad major version; class=support/operations/gtm/iosbackendmanager/BackendManager, offset=6
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:324)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:155)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:715)
at java.net.URLClassLoader.access$400(URLClassLoader.java:94)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1169)
at java.security.AccessController.doPrivileged(AccessController.java:492)
at java.net.URLClassLoader.findClass(URLClassLoader.java:598)
at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:777)
at java.lang.ClassLoader.loadClass(ClassLoader.java:750)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:341)
at java.lang.ClassLoader.loadClass(ClassLoader.java:731)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
分析と調査を経て、我々はローカルRAD(eclipseの一種)のJDK level問題と考え、server上のjavaバージョンは1.7であり、Antパッケージに関するsourceとtargetはいずれも1.7であるが、ローカルRADのJDKコンパイルバージョンは1.8であり、それを1.7に変更し、パッケージ配置後、プロセスは正常に起動した.
この問題について、ネット上では「高バージョンのJDKコンパイルJava classファイルを使用して低バージョンのJVM上で実行しようとしているため」と一般的に言われているため、解決策は通常、ローカルJDKコンパイル環境を変更するものであり、典型的な例はこれである:UnsupportedClassVersionError: JVMCFRE003 bad major version in WebSphere AS 7.しかし、このcaseでは、私のdeployの部分はコンパイルされたclassには関与していません.2つの疑問があります
この部分を自動化パッケージおよび導入ツール(UCD)を用いて導入するのは初めてである.生産環境なので、このChangeをする前はまだ緊張していましたが、予想される問題は主に2つあります:1,Deploy process問題,2,静的資源の文字化けし問題.1つ目は確かに少し故障してbinパスの変更はありませんが、processのステップで「allow failure」が選択されていないので、binフォルダをコピーするときにフォルダが空のエラーと報告して実行を停止します.allow failureを選択すればよい.2,文字化けしの問題は従来通りであるが,このバージョンの変更ではcurrency記号「ファイルは東欧コードISO-8859-2の形式でしか保存できない.これには、utf 8および他のフォーマットの符号化に対するソースコードの処理ロジックをさらに調べる必要がある.今度は予想していた問題が起こらなかったのに、変な問題が出て、みんな緊張していたので、問題はもう解決した.しかし、もっと調査が必要です.
how to check the jdk version used to compile a .class file - duplicate