How to solve JDK VERSION Mismatch during dbTechStack

Cloning an Oracle E-Business Suite (EBS) environment is a routine task for DBAs, but sometimes even a successful preclone can lead to unexpected failures during the dbTechStack configuration phase.

Toady we are facing JDK version mismatch, which results in the failure of:

perl adcfgclone.pl dbTechStack

In this blog, we will walk through a real-world issue, analyze the error, identify the root cause, and provide a step-by-step solution to fix the problem and successfully complete the cloning process.

---

Problem Statement

During execution, the clone fails at 0% with the following error:

RC-00110: Fatal: Error occurred while relinking of ApplyDBTechStack
ERROR: Failed to execute adclone.pl

Error log reveals:

java.lang.UnsupportedClassVersionError:
Unsupported major.minor version 51.0

---

Analyze Log Files

Navigate to the logs directory:

cd /DBA/8010_JAN26/12.1.0/appsutil/logs
ls -lrt

Check the error log:

cat oraInstall*.err

Key Error:

Unsupported major.minor version 51.0

---

Verify Current JDK Version on Target

cd /DBA/8010_JAN26/12.1.0/jdk/bin
./java -version

Output:

java version "1.6.0_75"

---

Compare with Source / Working Environment

./java -version

Output:

java version "1.7.0_351"

---

Root Cause

The source production system was running on JDK 1.7, while the cloned environment contained JDK 1.6.

This mismatch caused the Java runtime to fail with:

Unsupported major.minor version 51.0

here is the logfile with the complete error:

Exception java.lang.UnsupportedClassVersionError: oracle/sysman/ccr/collector/install/InvalidValueException : Unsupported major.minor version 51.0 occurred..
java.lang.UnsupportedClassVersionError: oracle/sysman/ccr/collector/install/InvalidValueException : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at oracle.sysman.oii.oiif.oiifw.OiifwOCMInfoWCDE.(OiifwOCMInfoWCDE.java:103)
at oracle.sysman.oii.oiic.OiicCloneSession.getIterElements(OiicCloneSession.java:1133)
at oracle.sysman.oii.oiic.OiicPullSession.initialize(OiicPullSession.java:1423)
at oracle.sysman.oii.oiic.OiicSessionWrapper.initialize(OiicSessionWrapper.java:784)
at oracle.sysman.oii.oiic.OiicSessionWrapper.initialize(OiicSessionWrapper.java:768)
at oracle.sysman.oii.oiic.OiicInstaller.run(OiicInstaller.java:568)
at oracle.sysman.oii.oiic.OiicInstaller.runInstaller(OiicInstaller.java:969)
at oracle.sysman.oii.oiic.OiicInstaller.main(OiicInstaller.java:906)

Classes compiled with Java 7 cannot run on Java 6.

---

Solution: Replace JDK with Correct Version

Backup Existing JDK

cd /DBA/8010_JAN26/12.1.0
mv jdk XX_jdk_16075

---

Copy Correct JDK from Source

cp -RH jdk /DBA/8010_JAN26/12.1.0/

---

Set Proper Ownership

chown -R ora8010:dba /DBA/8010_JAN26/12.1.0/jdk

---

Verify Updated JDK

cd /DBA/8010_JAN26/12.1.0/jdk/bin
./java -version

Expected Output:

java version "1.7.0_351"

---

---

Re-run Clone:

perl adcfgclone.pl dbTechStack

---

Final Outcome

After applying the fix:

• ApplyDBTechStack completes successfully
• No more Java version errors

---

Conclusion

JDK version mismatch is a subtle but critical issue that can break the Oracle EBS cloning process, even when everything else seems correct.

By carefully analyzing logs and ensuring Java version consistency, you can quickly resolve errors like:

Unsupported major.minor version 51.0

This approach not only fixes the issue but also helps build a more reliable and repeatable cloning process for future deployments.

---