RFR: 8296183: jndiprovider.properties contains properties pointing to non-existing classes [v2]

[Jaikiran Pai]

On Fri, 13 Feb 2026 21:13:00 GMT, Anirvan Sarkar <asarkar at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add reference to DefaultResponseControlFactory in javadoc
>
>>Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8)
> 
> It seems these classes were never part of the JDK.
> These classes were part of the (legacy?) JNDI/LDAP booster pack `ldapbp.jar` available as a separate download.
> The download file is currently `ldap-1_2_4.zip` in the Oracle Java Archive for Java Platform Technologies [1].
> 
> Software vendors required `ldapbp.jar` to be added to the `CLASSPATH`.
> The very old JNDI tutorial also references `ldapbp.jar` [2].
> 
> Booster pack has the following packages:
> 
> |          Package           |                     Contents                      |
> |----------------------------|---------------------------------------------------|
> | com.sun.jndi.ldap.obj      | RMI, CORBA support for LDAP Service Provider for JNDI |
> | com.sun.security.sasl.misc | CRAM-MD5, Anonymous, and Plain SASL Drivers       |
> | com.sun.jndi.ldap.ctl      | Controls for LDAP Service Provider for JNDI       |
> 
> The packages `com.sun.security.sasl.misc` and `com.sun.jndi.ldap.ctl` became obsolete when its support was included in the JDK 5.
> 
> I suspect the classes of package `com.sun.jndi.ldap.obj` were not included in JDK, as RFC 2713 & RFC 2714 were not standardized unlike other RFCs related to LDAP.
> 
> The booster pack is also available on Maven repository [3].
> Do you think any of its dependencies could be impacted by removal of `jndiprovider.properties` file?
> Should this removal be mentioned in the release notes? 
> 
> If you want to look at the booster pack’s source code, it’s included in GlassFish 5 [4].
> 
> [1] : https://www.oracle.com/java/technologies/java-archive-downloads-java-plat-downloads.html#7110-jndi-1.2.1-oth-JPR
> [2] : https://docs.oracle.com/javase/jndi/tutorial/objects/storing/index.html
> [3] : https://mvnrepository.com/artifact/com.sun/ldapbp
> [4] : https://github.com/javaee/glassfish/tree/master/appserver/ldapbp/src/main/java/com/sun/jndi/ldap

Thank you for those details @AnirvanSarkar. This helped understand where these values came from.

> Do you think any of its dependencies could be impacted by removal of jndiprovider.properties file? Should this removal be mentioned in the release notes?

Having read and reviewed those details, I think this will need a release note and also a CSR. The `jndiprovider.properties` that is shipped by the `java.naming` module references classes that don't belong to the JDK. Yet, some of the (seemingly outdated) documentation (including the tutorial you pointed to) instruct applications to include a LDAP provider specific JAR file in the classpath of the application and expect the LDAP provider to load the classes configured in the `java.naming` module's `jndiprovider.properties`.

Before the changes in this PR, code like the following


public class Test {
    public static void main(final String[] args) throws Exception {
        final Hashtable<String, String> envProps = new Hashtable<>();
        envProps.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
        envProps.put("java.naming.ldap.version", "3");
        envProps.put(Context.PROVIDER_URL, "ldap://127.0.0.1:12345"); // LDAP server
        final Context ctx =  NamingManager.getInitialContext(envProps);
        System.out.println("Got context " + ctx);
        final Object obj = NamingManager.getObjectInstance(new java.rmi.MarshalledObject<String>(new String("foo")), new LdapName("CN=foo"), ctx, envProps);
        System.out.println("Got object instance " + obj + " type " + obj.getClass());
    }
}


when launched with the LDAP booster pack JAR in the application classpath would return:


java -cp ldapbp-1.0.jar Test.java

Got context com.sun.jndi.ldap.LdapCtx at 1f3f4916
Got object instance foo type class java.lang.String

(notice the return type of `obj` is `java.lang.String`)

What this implies is that the LDAP service provider in the JDK picked up the `jndiprovider.properties` from the `java.naming` module and noticed the:


java.naming.factory.object=com.sun.jndi.ldap.obj.AttrsToCorba:com.sun.jndi.ldap.obj.MarshalledToObject


property value and loaded the `com.sun.jndi.ldap.obj.MarshalledToObject` from the JAR file in the application classpath and invoked it to return the `java.lang.String` output.

With the proposed change, the LDAP provider will no longer by default set the `java.naming.factory.object` (and the other two) properties. Thus the LDAP provider will no longer attempt to load `com.sun.jndi.ldap.obj.MarshalledToObject` and as a result, the same application code will now see the following result:



java -cp ldapbp-1.0.jar Test.java

Got context com.sun.jndi.ldap.LdapCtx at 14a2f921
Got object instance java.rmi.MarshalledObject at a546def5 type class java.rmi.MarshalledObject

(notice how the return type is now `java.rmi.MarshalledObject`)

So yes, this change will have an impact on applications.

The javadoc of `javax.naming.Context` specifies how/where the environment properties are picked up https://docs.oracle.com/en/java/javase/25/docs/api/java.naming/javax/naming/Context.html#resource-files-heading. With the change being proposed in this PR, the applications will now have to explicitly pass the values for:


java.naming.factory.control
java.naming.factory.object
java.naming.factory.state

if they want those values to be used by the LDAP service provider. So the application would have to do something like:


...
envProps.put("java.naming.factory.object", "com.sun.jndi.ldap.obj.AttrsToCorba:com.sun.jndi.ldap.obj.MarshalledToObject");
...


to instruct LDAP provider to use those classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29712#issuecomment-3907698917