On Fri, 13 Feb 2026 21:13:00 GMT, Anirvan Sarkar <[email protected]> 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@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@14a2f921 Got object instance java.rmi.MarshalledObject@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
