RFR [11u]: 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider

[Lindenmaier, Goetz]

Hi Christoph, 

You just pinged for a review, but I was looking at it anyways.

I think this looks good. The basic functionality is the same, 
you added functionality to access LdapDnsProviderService
without having it in the same module. 
Our jck tests are green with the change as you implemented it.

One nit, I think the comment here is too complicated, maybe
shorten the sentences a bit?
http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderServiceInternal.java.html

  34  * It is implemented by jdk.naming.ldap and the singleton instance is registered
  35  * in LdapCtxFactory to which provides access to the service mechanism
  36  * of jdk.naming.ldap/com.sun.jndi.ldap.spi for module java.naming.
--> 
  34  * It is implemented by jdk.naming.ldap. LdapDnsProviderService. A singleton instance is registered
  35  * in LdapCtxFactory. This singleton provides access to the service mechanism
  36  * of jdk.naming.ldap/com.sun.jndi.ldap.spi for module java.naming.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On Behalf
> Of Langer, Christoph
> Sent: Tuesday, August 11, 2020 5:52 PM
> To: jdk-updates-dev at openjdk.java.net
> Cc: Osipov, Michael <michael.osipov at siemens.com>
> Subject: [CAUTION] RFR [11u]: 8160768: Add capability to custom resolve
> host/domain names within the default JNDI LDAP provider
> 
> Hi,
> 
> I've been working on backporting JDK- 8160768: "Add capability to custom
> resolve host/domain names within the default JNDI LDAP provider" to
> OpenJDK 11u. This seems to be quite an important enhancement for usage in
> more complex LDAP setups so there is a certain demand for this backport.
> Oracle has backported it to their JDK8 and 11 releases already.
> 
> Backporting is not so trivial, though, as the original change introduced a new
> package with two classes in the javax namespace: javax.naming.ldap.spi with
> classes LdapDnsProvider and LdapDnsProviderResult. To facilitate
> backporting without having to change the spec, this backport creates
> package com.sun.jndi.ldap.spi instead of javax.naming.ldap.spi to provide
> the new service interface. So people wanting to leverage the feature in a JDK
> < 12 will have to build against the com.sun.jndi.ldap.spi implementation.
> Furthermore, we can't publicly export package com.sun.jndi.ldap.spi from
> module java.naming as this is not allowed for a module in the java
> namespace. So I introduced a new module jdk.naming.ldap for being able to
> export the new service interface. The service is hooked into java.naming's
> class LdapCtxFactory by reflective lookup of class
> com.sun.jndi.ldap.dns.LdapDnsProviderService and triggering its initialization.
> This in turn will register the LdapDnsProviderServiceInternal singleton for
> accessing com.sun.jndi.ldap.spi service implementations from java.naming. If
> a JDK was jlink'ed without module jdk.naming.ldap, the missing
> LdapDnsProvider facility would then just be ignored quietly.
> 
> In my backport I also include the adaptations to the test from the already
> backported change of JDK-8139965 to improve test stability.
> 
> I had to create a backport CSR as well for which I'd also need a review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8160768
> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8192975
> Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a
> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251380
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/
> 
> Thanks in advance for looking at this.
> 
> Best regards
> Christoph