OpenAM has doubled in size since version 14

[FireBurn]

I noticed 16 was a lot bigger than it used to be so got Claude to take a look, here's what it came up with - some of these can totally be ignored (like including embedded OpenDJ)

The WAR contains 318 JARs. Here's what stands out as genuinely problematic:

Duplicate/conflicting stacks:

• Two Cassandra Java drivers: java-driver-core-4.17.0.jar AND java-driver-core-4.19.2.jar — two different versions of the same DataStax driver coexist. Same story with java-driver-query-builder-4.17.0.jar sitting alongside java-driver-core-4.19.2.jar. That's not a transitive conflict that got mediated — both physically landed in the WAR.
• Two shaded Guava copies for Cassandra: java-driver-guava-shaded-4.19.2.jar AND java-driver-shaded-guava-25.1-jre-graal-sub-1.jar — two separately-shaded Guava bundles from the two driver versions.
• Two Restlet copies: org.restlet-16.0.6.jar (the Jakarta-transformed version) AND org.restlet-2.4.4.jar (the original) — both are in the WAR simultaneously, along with the Jakarta-transformed ext JARs (org.restlet.ext.jackson-16.0.6.jar etc.) but also org.restlet.ext.freemarker-2.4.4.jar from the original. That's two full Restlet runtimes.
• Two aopalliance JARs: aopalliance-1.0.jar and aopalliance-repackaged-3.0.6.jar — different coordinates, same API.
• Two javax.activation / jakarta.activation stacks: javax.activation-api-1.2.0.jar alongside jakarta.activation-2.0.1.jar and jakarta.activation-api-2.0.1.jar.
• Two JAXB generations: jaxb-api-2.3.1.jar + jaxb-core-2.3.0.1.jar + jaxb-impl-2.3.2.jar (JAXB 2.x) alongside jaxb-core-3.0.2.jar + jaxb-runtime-3.0.2.jar (JAXB 3.x/Jakarta). Both fully present.
• Two javax.xml.soap / jakarta.xml.soap stacks: javax.xml.soap-api-1.4.0.jar and jakarta.xml.soap-api-2.0.1.jar.
• Two validation-api JARs: validation-api-1.1.0.Final.jar (Bean Validation 1.1, javax) and jakarta.validation-api-3.0.2.jar (Jakarta). Both present.
• Two HTTP client generations: Apache HttpClient 4.x (httpclient-4.5.13.jar, httpcore-4.4.14.jar, httpclient-osgi-4.5.13.jar, httpasyncclient-4.1.4.jar, httpcore-nio-4.4.14.jar, httpcore-osgi-4.4.14.jar) alongside HttpClient 5.x (httpclient5-5.3.1.jar, httpcore5-5.2.4.jar, httpcore5-h2-5.2.4.jar). That's two complete Apache HTTP stacks.
• Two BouncyCastle families: bc-fips-2.1.2.jar + bcpkix-fips-2.1.10.jar + bctls-fips-2.1.22.jar + bcutil-fips-2.1.5.jar (the FIPS suite) and bcpkix-shaded-16.0.6.jar (the shaded non-FIPS version). So yes, two BC stacks physically present.

Genuinely alarming items:

• jruby-9.2.20.1.jar + jruby-core-9.2.20.1.jar + jruby-stdlib-9.2.20.1.jar — a full JRuby runtime is in there. This is almost certainly pulled in by asciidoctorj-2.5.3.jar (AsciidocJ requires JRuby to run). AsciidocJ is a documentation generation tool — it has absolutely no business being in a production server WAR.
• asciidoctorj-2.5.3.jar + asciidoctorj-api-2.5.3.jar — confirms above. These are build/doc tools.
• mssql-jdbc-12.10.2.jre11.jar + mysql-connector-j-9.2.0.jar + postgresql-42.7.8.jar + ojdbc8-23.7.0.25.01.jar — all four major JDBC drivers bundled. You'll only ever use one (or none, if using LDAP/DJ for everything). Three of these are always dead weight.
• groovy-all-2.4.21.jar — the full groovy-all monolith rather than just groovy-core. This includes the Groovy compiler, Swing bindings, SQL module, test framework, etc.
• servlet-api-2.4.jar — a 2004-era Servlet 2.4 API JAR sitting in WEB-INF/lib alongside modern Jakarta Servlet. This should be provided scope and never land in the WAR.
• batik-* JARs (SVG rendering library from Apache) — batik-constants, batik-css, batik-i18n, batik-util, batik-shared-resources + xmlgraphics-commons, jai-imageio-core. This is a heavyweight SVG/graphics rendering stack used by the legacy console's image generation. Not needed for auth/SSO operations.
• nashorn-core-15.4.jar — a Nashorn JavaScript engine polyfill for Java 15+ (Nashorn was removed from the JDK). Since OpenAM also has Rhino (rhino-1.7.14.1.jar), there are now two JavaScript engines in the WAR.
• xalan-2.7.3.jar + xercesImpl-2.12.2.jar + xml-apis-1.4.01.jar — the ancient Xalan XSLT and Xerces XML parser stack, both redundant when modern Java has built-in XML support. Xalan in particular has a long CVE history.
• neko-htmlunit-3.11.1.jar — an HTML parser, appears to be pulled in by the WebAuthn or scripting module.
• jdmkrt-2007-01-10.jar — a 2007 Sun JDMK (Java DMK) runtime for SNMP monitoring. Ancient and large.
• isorelax-20030108.jar — a 2003 RELAX NG schema library. Almost certainly dead.
• bsh-2.0b6.jar — BeanShell scripting engine, another scripting runtime alongside Groovy, Rhino, JRuby, and Nashorn.

Here's the full picture visually:A few things stand out that are worth calling out beyond what's in the visual:

The JRuby situation is the most egregious. asciidoctorj is a library for rendering AsciiDoc documentation — it has zero runtime function in a running auth server. It likely crept in as a dependency of openam-documentation or something in the audit/reporting modules that generates docs during build but was mistakenly scoped as compile instead of being excluded. The JRuby stdlib alone is roughly 20 MB. Filing this as a bug upstream would be entirely reasonable.

The dual Cassandra driver versions strongly suggest the two Cassandra submodules (openam-cassandra-datastore and openam-cassandra-cts) have diverged and aren't pinned to the same driver version in their own POMs. One is pulling 4.17.0 and the other 4.19.2, and Maven's dependency mediation didn't collapse them because they both physically ended up in the WAR rather than being resolved at the classpath level (since both submodule JARs are included as first-class dependencies).

The dual Restlet situation (2.4.4 + 16.0.6) is a consequence of the Jakarta transform approach — the project creates transformed copies at the project version but didn't add packagingExcludes entries for the original 2.4.4 originals. The org.restlet.ext.freemarker-2.4.4.jar sitting alongside the transformed 16.0.6 versions is a particularly clear sign of this.

On OpenDJ specifically: opendj-ldap-toolkit contains the command-line administration tools (ldapsearch, ldapmodify etc.) — there is no reason these need to be in a production WAR. opendj-rest2ldap is the REST-to-LDAP gateway component, also not needed inside the WAR. Those two alone are probably several MB that serve zero purpose at runtime.

For a practical attack plan in rough effort/reward order: remove AsciidocJ+JRuby (trivial exclusion, massive reward), fix the packagingExcludes to drop the pre-transform Restlet 2.4.4 JARs, align the Cassandra driver versions across the two submodules, add packagingExcludes for the three JDBC drivers you don't use, and add <scope>provided</scope> to servlet-api-2.4.