HCL Domino 14 vs Earlier Versions: A Reference for Admins and Developers

Your org is planning to upgrade Domino from V11 or V12 to 14.5 — the admin pages through release notes, the developer reads the Designer 14 docs, and in the end neither is sure which of their existing pieces will actually break versus which are just nice-to-haves.

The reality: Domino 14.x’s truly structural changes — the ones that affect existing deployments — concentrate in a handful of areas. Not every release-notes line item deserves equal attention. This article organises the 14.0 / 14.5 / 14.5.1 differences along five dimensions: where files live, the Java environment, the XPages editor, new modules, and the full deprecation list. Every entry is tagged with its starting version and an official source, and the article closes with a pre-upgrade checklist you can run through.

TL;DR

• Java jumps twice: Domino 14.0 lifts the main JVM from Java 8 to Java 17 LTS (Win / Linux / AIX); Domino 14.5 lifts it again to Java 21 LTS. IBM i only catches up to Java 17 in 14.5.
• notes.ini can no longer live in the executable directory — the 14.0 Windows installer dropped that support; the 14.5 installer actively moves it into data directory and updates the service registry to match.
• JAR placement: jvm/lib/ext stops working in 14.x — V12 (Java 8) auto-scanned that location into classpath; that’s a real and load-bearing deployment pattern many shops relied on. Starting with 14.0 the main JVM is Java 17, which removed the ext mechanism entirely (deprecated in Java 9, dropped in Java 11). Jars in jvm/lib/ext are no longer picked up; ndext is the practical fallback.
• The XPages editor was replaced wholesale — 14.5 ships TinyMCE 6.7 instead of CKEditor 4, with no opt-out (CKEditor no longer ships with Domino).
• 14.5 removes 5 things: iNotes UI, SNMP MIB server start/stop/restart, Domino Configuration Tuner, Server Load Utility from the install panel, and the “Send upgrade notifications” action on pubnames.ntf.
• 14.0 additions: AdminCentral (admincentral.nsf), AutoUpdate, 64-bit-only Notes clients, Domino Restyle UI.
• 14.5 additions: Domino IQ (server-embedded LLM inference engine), DQL integration of @FTSearch, external meeting invitation description limit lifted from 40 KB to 1 MB.
• 14.5.1 additions: Copy method on NotesJSONArray / NotesJSONObject / NotesJSONElement, new NotesSession methods (LotusScript + Java) for acquiring tokens from the Domino OIDC Provider, and the XPages file upload UI now supports multiple selections by default.

1. Where files live

notes.ini location — narrowed in 14.0, auto-moved in 14.5

In V11 / V12, notes.ini on Windows could sit in the Domino executable directory (C:\Program Files\HCL\Domino\). Starting with 14.0, the Windows installer no longer supports that location. In 14.5, the installer goes further: it actively moves notes.ini into data directory (e.g. C:\Domino\Data\notes.ini) and updates the service registry to point at the new path.

Operational fallout to plan for:

• Existing add-on programs, batch jobs, monitoring scripts that hard-code the old path need to be audited and updated
• Third-party backup tools using notes.ini as a server-identity fingerprint will need reconfiguration
• Custom monitoring scripts reading notes.ini for dynamic config need to follow the path

Windows Extension Manager API search path tightened

In 14.5, the Extension Manager API (invoked via the ExtMgr_Addins notes.ini variable) no longer searches the system PATH for unqualified library names. The default search path drops to three locations:

1. Notes / Domino executable directory
2. Windows System directory
3. Windows directory

To add more search paths, use ExtMgr_Dir<#>=<path> (<#> is 1–9):

ExtMgr_Dir1=C:\MyExtensions
ExtMgr_Dir2=D:\ThirdParty\Bin

This is a security hardening — searching PATH made it too easy for a malicious DLL in the wrong location to get loaded. But legacy environments that relied on PATH to find their in-house extensions will need to set these variables explicitly post-upgrade.

OS_DISABLE_CACHESET default flipped from 0 to 1

Starting with 14.5, OS_DISABLE_CACHESET defaults to 1 instead of 0. The reasoning: on Windows Server 2019 and later, Domino’s manipulation of the Windows File System cache actually causes performance problems, so the new default is to leave it alone.

If you manually set this to 0 chasing performance gains in the past, re-evaluate in 14.5 — keeping it at 1 is the right call in most scenarios.

Verse install path

Fresh 14.5 installs put Verse in the program directory, not data directory. On upgrades: if the Verse version hasn’t changed it stays put; if it has changed it moves to the program directory. Impact on backup paths and patch flows is minor, but any path-mapping tooling needs updating.

2. Java environment

Two JVM jumps

Neither jump is small — Java 8 → 17 skips one LTS (11), and 17 → 21 is another LTS. Most legacy code that relies on Java reflection, internal APIs, or sun.* packages will break on either 17 or 21. Compatibility testing before upgrade isn’t optional.

Starting with 14.0, Java applications need to explicitly add glassfish-corba-omgapi.jar to the classpath alongside the existing Notes.jar or NCSO.jar. Without it, some CORBA operations throw ClassNotFoundException.

Eclipse 4.22 → 4.30

In 14.5, Notes Standard, Domino Administrator, Domino Designer, and XPages all move from Eclipse 4.22 to 4.30. Biggest impact is on anyone shipping Eclipse plugins — Eclipse APIs aren’t always backward-compatible across minor versions, so in-house plugins need recompilation and testing.

JAR placement — fallout from Java 17 removing the ext mechanism

In the V11 / V12 era (Java 8), the ext class loader mechanism was still in play — jars dropped into <domino>/jvm/lib/ext/ got auto-scanned into classpath. That was a real, load-bearing deployment pattern; many shops kept in-house and third-party extensions there.

Starting with 14.0, the main JVM is Java 17 — Java 9 deprecated the ext mechanism, Java 11 removed it outright. On 14.x running Java 17, jvm/lib/ext is no longer scanned at all and jars sitting there silently stop loading. This is one of the highest-impact V12 → 14 upgrade traps — the class-load failures show up in places that don’t obviously point at the JVM change, costing hours of misdirected debugging.

Where to move things? Two paths worth keeping separate:

• JSDK.JAR (the Java Servlet Development Kit jar, for servlet compilation): the official documentation points at <domino>/ndext/. This isn’t a 14.5 change — the same page in Domino 12.0 had the same text.
• In-house / third-party extension jars: HCL hasn’t issued a blanket “every extension jar now belongs in ndext” announcement, but the practical fallback is ndext (the same directory as JSDK.JAR). Cleaner alternatives include packaging as an OSGi plugin or declaring the classpath explicitly in server config.

V12 path:   <domino>/jvm/lib/ext/yourlib.jar   (auto-scanned by Java 8 ext mechanism)
14.x path:  <domino>/ndext/yourlib.jar          (or OSGi / explicit classpath)

Upgrade action: enumerate every jar currently deployed to jvm/lib/ext, migrate it to ndext or change its load mechanism. Anything left in jvm/lib/ext will fail to load on 14.x.

64-bit Notes clients only

Starting with 14.0, Notes client is 64-bit only. Environments still running 32-bit need to confirm the client side can run 64-bit (most modern Windows installs are fine). AutoUpdate can upgrade 32-bit to 64-bit without a manual reinstall.

Designer 14.5 / 14.5.1 developer APIs

• 14.5: new 64-bit NotesSession API (LotusScript)
• 14.5: XPages adds unsafe-inline CSP support, opt-in on the server (inline scripts in XPages used to hit CSP policy walls; now there’s a path)
• 14.5.1: NotesJSONArray / NotesJSONObject / NotesJSONElement gain a Copy method (copying JSON structures used to mean walking the tree; now there’s a native API — see the site article on the JSON trio)
• 14.5.1: new NotesSession method (LotusScript) and Session method (Java) for acquiring an access token from the Domino OIDC Provider
• 14.5.1: the XPages file upload UI now supports multiple selections by default — verbatim: “The XPages file upload UI now supports multiple selections by default.” Users can now select multiple files at once; the fileUpload control’s default behaviour changed, no extra attribute needed

3. The XPages editor swap: CKEditor → TinyMCE

This is the single biggest 14.5 change for XPages developers.

What changed

Starting with Domino Designer 14.5, the XPages default rich text editor switched from CKEditor 4 to TinyMCE 6.7. No opt-out — CKEditor no longer ships with Domino, so you can’t reach back for the old one post-upgrade.

Why HCL made the swap

Community observation (frostillic.us’s writeup) points to two reasons:

1. CKEditor 4 reached EOL in June 2023 — no more security updates
2. CKEditor 5 dropped the MPL licence option — commercial use is now paid-only

HCL apparently didn’t want to pay for extended CKE4 support or for a CKE5 commercial licence, so TinyMCE it is.

Two common ways your customisation will break

If you’ve customised CKEditor before, two patterns won’t work on TinyMCE:

1. Toolbar configuration as a string preset

<!-- CKEditor accepts a preset profile -->
<xp:attr name="toolbarType" value="Large"/>

TinyMCE treats the same attribute as a space-delimited list of action names, and "Large" isn’t one of TinyMCE’s built-in actions — so it silently breaks: the editor renders, but the toolbar is wrong.

2. JavaScript expressions for dynamic attribute values

CKEditor runs certain attributes through eval(), so this works:

<xp:attr name="toolbar" value="${javascript:getUserToolbar(...)}"/>

TinyMCE does not support that — values must be resolved up front.

Cross-version-compatible workaround

The community pattern is to use @Version build-number checks and conditionally load both configurations:

<xp:dataContext var="isTinyMce"
                value="${javascript:parseInt(session.evaluate('@Version')[0], 10) >= 495}"/>

<!-- For 14.5 and below — CKEditor style -->
<xp:attr name="toolbar" value="Slim" loaded="${not isTinyMce}"/>

<!-- For 14.5+ — TinyMCE style (space-delimited actions) -->
<xp:attr name="toolbar" value="undo redo styles" loaded="${isTinyMce}"/>

Not an official recommendation, but practical for code that has to deploy across multiple Domino server versions.

What still works

Simple static attributes (skin="oxide-dark", height="400", etc.) work on both — no changes needed.

Bonus: Dojo upgraded too

Domino 14.5 also lifts Dojo from 1.9.7 to 1.17.3 — same “cross-major-version compatibility isn’t guaranteed” story. XPages components built on Dojo need re-testing.

4. New modules

This section is “new arrivals only”; deep-dives are linked to their own articles:

Domino IQ — server-embedded LLM inference engine (14.5)

Domino 14.5 brings an LLM inference engine into the server process — Domino apps can call a local AI model without round-tripping to OpenAI / Azure. New NotesLLMRequest / NotesLLMResponse classes (covered in a dedicated article) let LotusScript and Java interact directly. With RAG configuration, NSFs can serve as the knowledge base.

DQL @FTSearch integration (14.0)

Domino 14 integrated FTSearch as a DQL term — write @FTSearch('query') or @FTS('query') to mix text-search predicates into structured queries. One query expresses both shapes; no more two-stage chains needed.

AdminCentral — new admin app (14.0)

Starting with 14.0, AdminP automatically creates admincentral.nsf, putting most day-to-day admin tasks in either Notes Standard client or Nomad web — no need for the classic Domino Administrator. Big quality-of-life improvement for web-admin-first shops.

AutoUpdate — automated Domino updates (14.0; reinforced in 14.5)

Shipped in 14.0: pull new versions from the My HCLSoftware Portal, distribute to designated server groups. Fully automated updates on Windows / Linux start in 14.5 (set Product Updates to “Notify, Download and Update”); AIX in 14.5 can serve as a download server or target for distribution but not as an install target.

64-bit NotesSession API (14.5)

14.5 adds a NotesSession API specifically tuned for 64-bit — better performance and memory characteristics for large workloads.

Other additions

• Mac C API Kit ships with an upgraded compiler (14.5)
• External meeting invitation description ceiling raised from 40 KB to 1 MB (14.5)
• DAOSmgr Repair Tell command scans the DAOS catalog for missing objects (14.0)
• Domino Restyle harmonised UI palette (14.0)
• InstallAnywhere upgraded to 2024 R1 on all platforms; Notes client switched to InstallShield 2023 R1 (14.5)

5. Deprecation / removal list (14.5)

Items explicitly no longer included in Domino 14.5:

iNotes removal is the heaviest hit on this list — orgs with iNotes users still around need a Verse transition plan upfront, or they have to keep a legacy server around as a stopgap (not recommended long-term).

6. Security / authentication (covered in dedicated site articles)

14.5 has two changes that hit existing deployments hard; both have dedicated articles on the site:

• Mandatory port encryption (14.5): see the mandated-port-encryption article
• TLS trust store moves from cacerts.pem to the Domino Directory (14.5): see the NotesHTTPRequest 14.5 trust-store article

Both will cause “code that worked yesterday won’t connect today” failures post-upgrade — strongly recommend reading both before scheduling the upgrade.

Pre-upgrade checklist

Organised into an admin / dev checklist you can run through:

Admin

• Audit every in-house batch / scheduled / monitoring script for hardcoded notes.ini paths
• List every library loaded via ExtMgr_Addins; check which relied on PATH search and add ExtMgr_Dir<#>= entries as needed
• Drop any manual OS_DISABLE_CACHESET=0 setting — confirm the 14.5 default works
• If iNotes users remain: schedule the Verse transition
• If SNMP MIB drove server start/stop automation: switch tooling
• If DCT was part of your health-check flow: find an alternative
• Upgrading IBM i to 14.5: confirm OS is at 7.4 or 7.5 and Java 17 patch level matches

Developer

• Migrate every in-house / third-party jar deployed to jvm/lib/ext on V12 to ndext (or OSGi / explicit classpath) — Java 17 removed the ext mechanism so 14.x no longer scans that location. JSDK.JAR was already in ndext as of the 12.0 docs, but plain extension jars still loaded from jvm/lib/ext on V12 (Java 8) and must move for 14.x
• Add glassfish-corba-omgapi.jar to the Java application classpath
• In 32-bit Notes client environments: confirm 64-bit migration is feasible
• XPages apps: grep for CKEditor usage; check toolbar / toolbarType attributes that might break
• XPages apps: grep for ${javascript:...} expressions on CKEditor attributes; replace with static values or @Version-conditioned attributes
• Run a full XPages regression after upgrade, paying particular attention to Dojo-based components
• In-house Eclipse plugins (if any): rebuild and test against Eclipse 4.30
• Code using Java reflection: compatibility-test against Java 17 / 21
• Post-14.5.1: revisit any in-house fileUpload customisation that assumed single-file selection — the default behaviour now allows multiple files

Closing

Domino 14.x isn’t a V8-to-V9-style UI refresh — it’s “the underlying runtime got swapped out from underneath you” — two Java jumps, tightened file paths, an editor swap, and a slate of security hardening.

For existing deployments, the thing that bites isn’t “missing a new feature” — it’s “missing that an old pattern no longer works”. The items in this article — notes.ini path, jvm/lib/ext, CKEditor customisations especially — are real-world breakage points, not nice-to-know release-notes entries.

When you’re scheduling the actual upgrade, take this checklist against your systems item by item. It’ll save you a lot of troubleshooting hours down the road.

← Back to all posts