Android runtime fails to start HTTPS due to javax.naming.ldap.LdapName dependency in org.eclipse.jetty.util.ssl.X509

[yang1318]

Jetty version(s)
9.4.51.v20230217

Jetty Environment
N/A (embedded Jetty on Android, not jetty-12 core/ee8/ee9/ee10/ee11)

HTTP version
HTTP/1.1

Java version/vendor (use: java -version)
Android Runtime (ART), Android 13

OS type/version
Android 13

Description
I found an Android compatibility issue when starting an embedded Jetty HTTPS server inside an Android app.

HTTP works, but enabling HTTPS fails during Jetty startup.

The failure happens because org.eclipse.jetty.util.ssl.X509 references javax.naming.ldap.LdapName, which is not available on the Android runtime.

Observed stack trace:

java.lang.NoClassDefFoundError: Failed resolution of: Ljavax/naming/ldap/LdapName;
at org.eclipse.jetty.util.ssl.X509.<init>(X509.java:104)
at org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:345)
at org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:244)

This causes HTTPS connector startup to fail before the server can accept TLS connections.

I understand Jetty 9 is EOL, but I wanted to report this compatibility issue for reference and ask whether this dependency is intentional, or whether a fallback approach without LdapName would be acceptable in a maintained branch.

How to reproduce?

1. Run an Android 13 app that starts an embedded Jetty 9.4.x server.
2. Configure HTTPS using SslContextFactory.Server, SslConnectionFactory, and ServerConnector.
3. Start the server.
4. Jetty fails during HTTPS initialization with NoClassDefFoundError for javax.naming.ldap.LdapName.

Example flow:

• Create Server
• Create HttpConfiguration with SecureRequestCustomizer
• Create SslContextFactory.Server
• Create ServerConnector with SslConnectionFactory(sslContextFactory, "http/1.1")
• Call server.start()

Result:
HTTPS startup fails with:

java.lang.NoClassDefFoundError: Failed resolution of: Ljavax/naming/ldap/LdapName;

Relevant stack trace:

java.lang.NoClassDefFoundError: Failed resolution of: Ljavax/naming/ldap/LdapName;
at org.eclipse.jetty.util.ssl.X509.<init>(X509.java:104)
at org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:345)
at org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:244)
at org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:97)
at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:234)
at org.eclipse.jetty.server.Server.doStart(Server.java:401)

Expected behavior:
Jetty should either avoid the hard dependency on javax.naming.ldap.LdapName in this path, or fail more gracefully on runtimes where JNDI is unavailable.

[sbordet]

Thanks for your interest, but Jetty 9.4.x is at EOL and won't receive public updates anymore.
We also do not accept public pull requests for changes to 9.4.x; this repository is now read-only.

You may contact Webtide for commercial support for Jetty 9.4.x.

The dependency is intentional and present also in recent Jetty versions, as we need to parse the distinguished name of a certificate, and this parsing is already done by JDK classes LdapName and Rdn, so we did not have to rewrite the parsing.

If you would like to contribute this parsing for Jetty 12.1.x will be great, but then you'll need Java 17 Android support.

My understanding of the Android support is that even if you solve this issue, there will be others that will pop up due to other incompatibilities between OpenJDK and Android.
I'd be happy to be wrong on this, so if you know better I'll be happy to know.

[yang1318]

Thank you for the clarification.

I understand that Jetty 9.4.x is EOL and that this dependency is intentional.
My use case is an embedded HTTPS server running inside an Android application.

I will do some experiments with Jetty 12.1.x on Android and see how far I can go.
Thank you again for your explanation and guidance.

[yang1318]

I did one additional Android compatibility check for reference.

To verify whether this was only a Jetty 9 HTTPS / SSL path issue, I also tested a minimal Jetty 12 HTTP server on Android 13.

This test did not use:

• HTTPS
• servlet
• multipart
• application-specific logic

It was only:

• new Server()
• one connector
• one minimal handler

However, Jetty 12 also failed in my environment, this time during Server() construction, with:

java.lang.NoSuchMethodError: No static method of(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path;

Stack trace starts from:

• org.eclipse.jetty.util.IO.asPath(IO.java:780)
• org.eclipse.jetty.util.IO.asFile(IO.java:808)
• org.eclipse.jetty.server.Server$ServerContext.<init>(Server.java:920)
• org.eclipse.jetty.server.Server.<init>(Server.java:87)

So in my testing, the Android compatibility issue does not seem limited to Jetty 9 HTTPS only.
Jetty 12 minimal HTTP startup also fails on Android 13 in this environment.

[sbordet]

Yes, unfortunately the difference in runtime support between Android and OpenJDK is large and our only option would be to create and maintain an Android-compatible version of Jetty, which is a huge task.

We did it in the past, but there was no traction from the community, so we gave up.

[joakime]

java.lang.NoSuchMethodError: No static method of(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path;

You need to be using Android API level 34 or better for that API to function.

See: https://developer.android.com/reference/java/nio/file/Path#of(java.lang.String,%20java.lang.String[])

[joakime]

Keep in mind that Jetty 12.0.x and 12.1.x require Java 17 or better (due to Jakarta EE minimums).
The next jump, likely Jetty 13.x will be Java 25 or better (again, to keep up with Jakarta EE minimums).

[yang1318]

Thank you for the kind and detailed explanation.

From what you described, it seems that Android compatibility issues are much broader than just replacing LdapName with a custom parser, similar to the previous Android-related efforts you mentioned.

For reference, I also tested newer Android API levels:

• API 34: even the minimal HTTP server failed due to a Java/runtime compatibility issue.
• API 35/36: the minimal HTTP server started successfully, but the HTTPS server still failed because of LdapName.

Given that, I will probably look for a different approach for an Android-compatible HTTPS web server instead of pursuing a custom LdapName parser on my side.

Thank you again to everyone for the thoughtful explanation and for taking the time to respond.

[sbordet]

@yang1318 would be great if you could remove the usage of LdapName and Rdn and see if Jetty works on API 36.
If so, we would be keen to replace the usage of those classes.