You may have read my blog post from the other day about patching my environments with the January 2021 Release Updates. But as I installed now Java in all my databases for testing purposes, I will quickly demonstrate how Patching all my environments with the January 2021 OJVM Bundles works.

Photo by Anni Denkova on Unsplash
Security Alert January 2021
Let me start with the Security Alert for January 2021. And don’t forget to take a look at the Oracle Database Server Risk Matrix for January 2021. This time, the is a 4.8 risk score issue with Java VM fixed.

Oracle Database Server Risk Matrix January 2021
The impact of OJVM issues has been decreased a bit over the last security alerts. I created a graph a while ago just highlighting the highest score OJVM issue per security alert since January 2015. There may be security alerts with more than one OJVM issue.

Highest OJVM Risk Score per Security Alert since January 2015
Hence, I’d highly recommend you to patch in case you have OJVM on in your databases.
Please don’t misinterpret the above graph. It is not meant to demonstrate that OJVM has a security problem. As OJVM is so powerful, as soon as there is a security issue, it has a drastic effect in many cases. But please instead read this graph as an explanation why you need to patch on a regular basis.
Downloading OJVM Patch Bundles
You can patch the database home and the OJVM in this home separately – but you could also download the Combo patches which are supposed to contain everything. I still prefer the standalone patches for my demos but in a real world environment you may want to do it as efficiently as possible.
As for the database, the same MOS Note: 2725756.1 – Critical Patch Update (CPU) Program Jan 2021 Patch Availability Document (PAD) contains the links to the downloads for the OJVM Release Updates as well.
- OJVM Release Update 19.10.0.0.210119 Patch 32067171 (size: 119MB on Linux)
- Readme
- Please be aware that OJVM Bundles are not Data Guard Standby First installable
- OPatch requirement: 12.2.0.1.19 minimum
- OJVM Release Update 12.2.0.1.210119 Patch 32119931 (size: 111MB for Linux)
- Readme
- OJVM patch bundles are not DG Standby First installable
- OPatch requirement: 12.2.0.1.17 minimum
What really amazes me is the difference in the layout of both readmes.
If you have a RAC environment, this MOS Note: 2217053.1 – RAC Rolling Install Process for the “Oracle JavaVM Component Database PSU/RU” (OJVM PSU/RU) Patches is very important for you.
Applying the OJVM Bundles to my 19c home
I don’t need to update my OPatch installations as I did this already for Patching my environments with the January 2021 Release Updates. As you can see above in the bullet point list, the requirements for OPatch for the OJVM bundle is lower than for the database. Still, I’d highly recommend to always use the newest OPatch.
For the below tests, I download and unzip the patch bundle into a separate directory. Then I change into this patch directory, either ./32067171 or ./32119931 .
- Checking the prerequesites
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./ Oracle Interim Patch Installer version 12.2.0.1.23 Copyright (c) 2021, Oracle Corporation. All rights reserved. PREREQ session Oracle Home : /u01/app/oracle/product/19 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/19/oraInst.loc OPatch version : 12.2.0.1.23 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-01-20_19-40-02PM_1.log Invoking prereq "checkconflictagainstohwithdetail" Prereq "checkConflictAgainstOHWithDetail" passed. OPatch succeeded.
- Applying the OJVM RU
$ $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 12.2.0.1.23 Copyright (c) 2021, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/19 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/19/oraInst.loc OPatch version : 12.2.0.1.23 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-01-20_19-46-05PM_1.log Verifying environment and performing prerequisite checks... OPatch continues with these patches: 32067171 Do you want to proceed? [y|n] y User Responded with: Y All checks passed. Please shutdown Oracle instances running out of this ORACLE_HOME on the local system. (Oracle Home = '/u01/app/oracle/product/19') Is the local system ready for patching? [y|n] y User Responded with: Y Backing up files... Applying interim patch '32067171' to OH '/u01/app/oracle/product/19' Patching component oracle.javavm.server, 19.0.0.0.0... Patching component oracle.javavm.server.core, 19.0.0.0.0... Patching component oracle.rdbms.dbscripts, 19.0.0.0.0... Patching component oracle.rdbms, 19.0.0.0.0... Patching component oracle.javavm.client, 19.0.0.0.0... Patch 32067171 successfully applied. Log file location: /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2021-01-20_19-46-05PM_1.log OPatch succeeded.
- Applying the SQL changes
SQL*Plus: Release 19.0.0.0.0 - Production on Wed Jan 20 19:53:52 2021 Version 19.10.0.0.0 Copyright (c) 1982, 2020, Oracle. All rights reserved. Connected to an idle instance. SQL> startup ORACLE instance started. Total System Global Area 1577055352 bytes Fixed Size 9135224 bytes Variable Size 536870912 bytes Database Buffers 1023410176 bytes Redo Buffers 7639040 bytes Database mounted. Database opened. SQL> alter pluggable database all open SQL> exit Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.10.0.0.0 [CDB2] oracle@hol:~/patch/32067171 $ $ORACLE_HOME/OPatch/datapatch -verbose SQL Patching tool version 19.10.0.0.0 Production on Wed Jan 20 19:54:19 2021 Copyright (c) 2012, 2020, Oracle. All rights reserved. Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_6616_2021_01_20_19_54_19/sqlpatch_invocation.log Connecting to database...OK Gathering database info...done Note: Datapatch will only apply or rollback SQL fixes for PDBs that are in an open state, no patches will be applied to closed PDBs. Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation (Doc ID 1585822.1) Bootstrapping registry and package to current versions...done Determining current state...done Current state of interim SQL patches: Interim patch 32067171 (OJVM RELEASE UPDATE: 19.10.0.0.210119 (32067171)): Binary registry: Installed PDB CDB$ROOT: Not installed PDB PDB$SEED: Not installed Current state of release update SQL patches: Binary registry: 19.10.0.0.0 Release_Update 210108185017: Installed PDB CDB$ROOT: Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 20-JAN-21 01.03.57.749255 AM PDB PDB$SEED: Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 20-JAN-21 01.03.58.234326 AM Adding patches to installation queue and performing prereq checks...done Installation queue: For the following PDBs: CDB$ROOT PDB$SEED No interim patches need to be rolled back No release update patches need to be installed The following interim patches will be applied: 32067171 (OJVM RELEASE UPDATE: 19.10.0.0.210119 (32067171)) Installing patches... Patch installation complete. Total patches installed: 2 Validating logfiles...done Patch 32067171 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/32067171/23947975/32067171_apply_CDB2_CDBROOT_2021Jan20_19_54_36.log (no errors) Patch 32067171 apply (pdb PDB$SEED): SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/32067171/23947975/32067171_apply_CDB2_PDBSEED_2021Jan20_19_55_19.log (no errors) SQL Patching tool complete on Wed Jan 20 19:55:22 2021
As you can see, I didn’t start my database in UPGRADE mode. See below why I didn’t do that. But as I have to take down the Oracle stack, whether you start in STARTUP UPGRADE or not is just a matter of an extra minute or two usually.
- Checking successful patch application
In order to check whether the patch scripts have been applied to ALL your containers, you need to set _exclude_seed_cdb_view=FALSE.CON_ID ACTION_TIME PATCH_ID PATCH_TYPE ACTION DESCRIPTION SOURCE_VERSI TARGET_VERSI ---------- -------------------- ---------- ---------- ---------- ------------------------------------------------------ ------------ ------------ 1 2019-04-28 29517242 RU APPLY Database Release Update : 19.3.0.0.190416 (29517242) 19.1.0.0.0 19.3.0.0.0 1 2019-10-16 30125133 RU APPLY Database Release Update : 19.5.0.0.191015 (30125133) 19.3.0.0.0 19.5.0.0.0 1 2020-01-21 30557433 RU APPLY Database Release Update : 19.6.0.0.200114 (30557433) 19.5.0.0.0 19.6.0.0.0 1 2020-04-15 30869156 RU APPLY Database Release Update : 19.7.0.0.200414 (30869156) 19.6.0.0.0 19.7.0.0.0 1 2020-07-15 31281355 RU APPLY Database Release Update : 19.8.0.0.200714 (31281355) 19.7.0.0.0 19.8.0.0.0 1 2020-10-21 31771877 RU APPLY Database Release Update : 19.9.0.0.201020 (31771877) 19.8.0.0.0 19.9.0.0.0 1 2021-01-20 32067171 INTERIM APPLY OJVM RELEASE UPDATE: 19.10.0.0.210119 (32067171) 19.10.0.0.0 19.10.0.0.0 1 2021-01-20 32218454 RU APPLY Database Release Update : 19.10.0.0.210119 (32218454) 19.9.0.0.0 19.10.0.0.0 2 2019-04-28 29517242 RU APPLY Database Release Update : 19.3.0.0.190416 (29517242) 19.1.0.0.0 19.3.0.0.0 2 2019-10-16 30125133 RU APPLY Database Release Update : 19.5.0.0.191015 (30125133) 19.3.0.0.0 19.5.0.0.0 2 2020-01-21 30557433 RU APPLY Database Release Update : 19.6.0.0.200114 (30557433) 19.5.0.0.0 19.6.0.0.0 2 2020-04-15 30869156 RU APPLY Database Release Update : 19.7.0.0.200414 (30869156) 19.6.0.0.0 19.7.0.0.0 2 2020-07-15 31281355 RU APPLY Database Release Update : 19.8.0.0.200714 (31281355) 19.7.0.0.0 19.8.0.0.0 2 2020-10-21 31771877 RU APPLY Database Release Update : 19.9.0.0.201020 (31771877) 19.8.0.0.0 19.9.0.0.0 2 2021-01-20 32067171 INTERIM APPLY OJVM RELEASE UPDATE: 19.10.0.0.210119 (32067171) 19.10.0.0.0 19.10.0.0.0 2 2021-01-20 32218454 RU APPLY Database Release Update : 19.10.0.0.210119 (32218454) 19.9.0.0.0 19.10.0.0.0 16 rows selected.
You may recognize that the output for the OJVM patch is not entirely correct. The SOURCE_VERSION column should not say 19.10.0.0.0 as I clearly didn’t install it in 19.10.0. I just didn’t patch it before but I installed JVM in 19.9.0.
Applying the OJVM Bundles to my 12.2.0.1 home
- Checking the prerequesites
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./ Oracle Interim Patch Installer version 12.2.0.1.23 Copyright (c) 2021, Oracle Corporation. All rights reserved. PREREQ session Oracle Home : /u01/app/oracle/product/12.2.0.1 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/12.2.0.1/oraInst.loc OPatch version : 12.2.0.1.23 OUI version : 12.2.0.1.4 Log file location : /u01/app/oracle/product/12.2.0.1/cfgtoollogs/opatch/opatch2021-01-20_20-10-51PM_1.log Invoking prereq "checkconflictagainstohwithdetail" Prereq "checkConflictAgainstOHWithDetail" passed. OPatch succeeded.
- Applying OJVM
$ $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 12.2.0.1.23 Copyright (c) 2021, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/12.2.0.1 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/12.2.0.1/oraInst.loc OPatch version : 12.2.0.1.23 OUI version : 12.2.0.1.4 Log file location : /u01/app/oracle/product/12.2.0.1/cfgtoollogs/opatch/opatch2021-01-20_20-12-48PM_1.log Verifying environment and performing prerequisite checks... OPatch continues with these patches: 32119931 Do you want to proceed? [y|n] y User Responded with: Y All checks passed. Please shutdown Oracle instances running out of this ORACLE_HOME on the local system. (Oracle Home = '/u01/app/oracle/product/12.2.0.1') Is the local system ready for patching? [y|n] y User Responded with: Y Backing up files... Applying interim patch '32119931' to OH '/u01/app/oracle/product/12.2.0.1' Patching component oracle.javavm.server, 12.2.0.1.0... Patching component oracle.javavm.server.core, 12.2.0.1.0... Patching component oracle.rdbms.dbscripts, 12.2.0.1.0... Patching component oracle.javavm.client, 12.2.0.1.0... Patching component oracle.rdbms, 12.2.0.1.0... Patch 32119931 successfully applied. Log file location: /u01/app/oracle/product/12.2.0.1/cfgtoollogs/opatch/opatch2021-01-20_20-12-48PM_1.log OPatch succeeded.
- Applying SQL changes
SQL*Plus: Release 12.2.0.1.0 Production on Wed Jan 20 20:14:34 2021 Copyright (c) 1982, 2016, Oracle. All rights reserved. Connected to an idle instance. SQL> startup ORACLE instance started. Total System Global Area 1258291200 bytes Fixed Size 8620224 bytes Variable Size 452986688 bytes Database Buffers 788529152 bytes Redo Buffers 8155136 bytes Database mounted. Database opened. SQL> exit Disconnected from Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production [DB12] oracle@hol:~/patch/32119931 $ $ORACLE_HOME/OPatch/datapatch -verbose SQL Patching tool version 12.2.0.1.0 Production on Wed Jan 20 20:14:58 2021 Copyright (c) 2012, 2021, Oracle. All rights reserved. Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_9504_2021_01_20_20_14_58/sqlpatch_invocation.log Connecting to database...OK Bootstrapping registry and package to current versions...done Determining current state...done Current state of SQL patches: Patch 31312468 (): Not installed in the binary or the SQL registry Patch 32119931 (OJVM RELEASE UPDATE 12.2.0.1.210119): Installed in the binary registry only Bundle series DBRU: ID 210119 in the binary registry and ID 210119 in the SQL registry Adding patches to installation queue and performing prereq checks... Installation queue: Nothing to roll back The following patches will be applied: 32119931 (OJVM RELEASE UPDATE 12.2.0.1.210119) Installing patches... Patch installation complete. Total patches installed: 1 Validating logfiles... Patch 32119931 apply: SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/32119931/23943202/32119931_apply_DB12_2021Jan20_20_15_11.log (no errors) SQL Patching tool complete on Wed Jan 20 20:15:41 2021
- Verifying patch application
CON_ID ACTION_TIME ACTION STATUS DESCRIPTION VERSION PATCH_ID BUND ---------- ------------ ---------- ---------- -------------------------------------------------------------------------------- ---------- ---------- ---- 1 2019-04-18 APPLY SUCCESS DATABASE APR 2019 RELEASE UPDATE 12.2.0.1.190416 12.2.0.1 29314339 DBRU 1 2019-10-16 APPLY SUCCESS DATABASE OCT 2019 RELEASE UPDATE 12.2.0.1.191015 12.2.0.1 30138470 DBRU 1 2020-01-21 APPLY SUCCESS DATABASE JAN 2020 RELEASE UPDATE 12.2.0.1.200114 12.2.0.1 30593149 DBRU 1 2020-04-14 APPLY SUCCESS DATABASE APR 2020 RELEASE UPDATE 12.2.0.1.200414 12.2.0.1 30886680 DBRU 1 2020-07-15 APPLY SUCCESS DATABASE JUL 2020 RELEASE UPDATE 12.2.0.1.200714 12.2.0.1 31312468 DBRU 1 2020-10-21 APPLY SUCCESS DATABASE OCT 2020 RELEASE UPDATE 12.2.0.1.201020 12.2.0.1 31741641 DBRU 1 2021-01-20 APPLY SUCCESS DATABASE JAN 2021 RELEASE UPDATE 12.2.0.1.210119 12.2.0.1 32228578 DBRU 1 2021-01-20 APPLY SUCCESS OJVM RELEASE UPDATE 12.2.0.1.210119 12.2.0.1 32119931 2 2019-04-18 APPLY SUCCESS DATABASE APR 2019 RELEASE UPDATE 12.2.0.1.190416 12.2.0.1 29314339 DBRU 2 2019-10-16 APPLY SUCCESS DATABASE OCT 2019 RELEASE UPDATE 12.2.0.1.191015 12.2.0.1 30138470 DBRU 2 2020-01-21 APPLY SUCCESS DATABASE JAN 2020 RELEASE UPDATE 12.2.0.1.200114 12.2.0.1 30593149 DBRU 2 2020-04-14 APPLY SUCCESS DATABASE APR 2020 RELEASE UPDATE 12.2.0.1.200414 12.2.0.1 30886680 DBRU 2 2020-07-15 APPLY SUCCESS DATABASE JUL 2020 RELEASE UPDATE 12.2.0.1.200714 12.2.0.1 31312468 DBRU 2 2020-10-21 APPLY SUCCESS DATABASE OCT 2020 RELEASE UPDATE 12.2.0.1.201020 12.2.0.1 31741641 DBRU 2 2021-01-20 APPLY SUCCESS DATABASE JAN 2021 RELEASE UPDATE 12.2.0.1.210119 12.2.0.1 32228578 DBRU 2 2021-01-20 APPLY SUCCESS OJVM RELEASE UPDATE 12.2.0.1.210119 12.2.0.1 32119931 3 2019-04-18 APPLY SUCCESS DATABASE APR 2019 RELEASE UPDATE 12.2.0.1.190416 12.2.0.1 29314339 DBRU 3 2019-10-16 APPLY SUCCESS DATABASE OCT 2019 RELEASE UPDATE 12.2.0.1.191015 12.2.0.1 30138470 DBRU 3 2020-01-21 APPLY SUCCESS DATABASE JAN 2020 RELEASE UPDATE 12.2.0.1.200114 12.2.0.1 30593149 DBRU 3 2020-04-14 APPLY SUCCESS DATABASE APR 2020 RELEASE UPDATE 12.2.0.1.200414 12.2.0.1 30886680 DBRU 3 2020-07-15 APPLY SUCCESS DATABASE JUL 2020 RELEASE UPDATE 12.2.0.1.200714 12.2.0.1 31312468 DBRU 3 2020-10-21 APPLY SUCCESS DATABASE OCT 2020 RELEASE UPDATE 12.2.0.1.201020 12.2.0.1 31741641 DBRU 3 2021-01-20 APPLY SUCCESS DATABASE JAN 2021 RELEASE UPDATE 12.2.0.1.210119 12.2.0.1 32228578 DBRU 3 2021-01-20 APPLY SUCCESS OJVM RELEASE UPDATE 12.2.0.1.210119 12.2.0.1 32119931
All fine!
Really STARTUP UPGRADE?
Well, this is an old discussion. In a non-RAC environment you may or may not care. But in case you have doubts whether you will need to do a startup upgrade or not, please check this blog post: Do you need STARTUP UPGRADE for OJVM?
Mitigation Patch?
Do you need to do this patching when you operate your database with the Mitigation Patch and the Java subsystem disabled?
Patching OJVM won’t harm you. But if you disabled the JVM, nobody can do anything with it.
Please see OJVM and the Mitigation Patch – Things to know in 2020 for further information.
Further Information and Links
- Patching my environments with the January 2021 Release Updates
- MOS Note: 2725756.1 – Critical Patch Update (CPU) Program Jan 2021 Patch Availability Document (PAD)
- MOS Note: 2217053.1 – RAC Rolling Install Process for the “Oracle JavaVM Component Database PSU/RU” (OJVM PSU/RU) Patches
- Do you need STARTUP UPGRADE for OJVM
- MOS Note: 1929745.1 – Oracle Recommended Patches — “Oracle JavaVM Component Database PSU and Update” (OJVM PSU and OJVM Update) Patches
- Why you need to set _exclude_seed_cdb_view=FALSE
- OJVM and the Mitigation Patch – Things to know in 2020
–Mike
Hi Mike,
We use OJVM with RAC DB, until now we are in 11204, so we had to start the db in upgrade mode to run the datapatch (equivalent) script. Now with 19c, we are planning to use rolling method for applying the quarterly RU + OJVM patch.
1) Does running datapatch on a busy system (assuming we don’t use any java components) causes any performance issues while datapatch is running ?
2) Does datapacth INVALIDATES any sys packages ? If application objects has a dependency on sys packages, application objects will become invalid, if app is running we will not be able to compile the invalid objects.
3) Any other gotcha items that we need to aware while running datapatch on a busy system ?
Hi Rakesh,
I can’t answer all your questions unfortunately with 100% certainty. But I will try.
Datapatch may take a bit – but you can run it on a busy system as well. It is VERY beneficial if you run utlrp.sql BEFORE you invoke datapatch.
Datapatch execution can invalidate sys packages of course – but they will be automatically recompiled when touched. Your app won’t become invalid.
Cheers,
Mike
Hi Mike,
Thanks for discussing patching subject in your blog posts….I have a question, if the database has NO JAVA component installed when querying DBA_REGISTRY view and if I apply the OJVM patch on it…the patch will be applied successfully and dictionary view DBA_REGISTRY_SQLPATCH will be updated that OJVM patch is applied. should this happen ? I mean the Opatch utility is not smart to check if the destination database has NO JAVA installed and “stop” from applying the patch ?!!
Thanks,
Emad Al-Mousa
Sabah Emad,
yes and no 😉 Actually, you need to differ between “home” and “database”. It could be that you have 20 databases running from the same home. 2 have JAVAVM, 18 don’t have it. So opatch does not care or can’t check as it would need to check with all your databases whether JAVAVM is there or not.
But the good news:
If you don’t have JAVAVM in your databases, and still apply the OJVM patch to your home, it won’t harm.
“datapatch” should ideally recognize if a component is there. But OJVM is treated as a one-off/interim patch as you can see from CDB_REGISTRY_SQLPATCH. And hence, having it in the database would at least signal that OJVM is patched already once you install it tomorrow into the database.
Cheers,
Mike
Hi Mike,
we usually download the Combo OJVM/GI RU for 12.2.0.1. I’m using the Assistant (Doc ID 2118136.2) as usual but end up downloading the non-Combo RU instead. There is even the same Patch Number either searching for Combo or non-Combo. Did I miss something or is it just a glitch this time?
Cheers,
Björn
Hi Bjoern,
I think you can’t download the Combo with the Assistant note. But instead with this one here:
Oracle Support Document 2725756.1 (Critical Patch Update (CPU) Program Jan 2021 Patch Availability Document (PAD)) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2725756.1
Combo OJVM Release Update 12.2.0.1.210119 and Database Release Update 12.2.0.1.210119 Patch 32126871 for UNIX, or
Combo OJVM Release Update 12.2.0.1.210119 and GI Release Update 12.2.0.1.210119 Patch 32126883, or
Database Jan2021 Release Update 12.2.0.1.210119 Patch 32228578 for UNIX
Cheers,
Mike
Hi Mike, Yesterday I attended the webinar on Performance tuning. Very informative and well presented. Thank you and your team for giving the best presentation.
I have a question on upgrade. I am trying to migrate Oracle 12.2 database to Oracle 19c. could you please advise if I should install 19.3 or 19.10 released in Jan,2021. I heard that 19.9 has issues and hence I donot want to install 19.9.
Any insight into this will be very helpful.
Thank You
Hi Surya,
thanks for your feedback – and clearly 19.10.0. Check out the DBMS_OPTIM_BUNDLE issue I was referring to on the blog already and apply the patch right away in addition.
Cheers,
Mike
Hello Mike,
We are transitioning to Exa C@C. Just got access and checked patch levels. I noticed that the following is applied to GI home:
32162391;JDK BUNDLE PATCH 19.0.0.0.210119
I always thought that GI home does not need any kind of Java patch. Has something changed with Exa C@C?
Thanks,
Arun
Hi Arun,
this is something we discussed for a long while with the GI folks … I won’t comment here.
Please log an SR and ask for a way to remove it safely.
Cheers,
Mike