Как удалить ссылки com.sun.jndi.ldap из моего проекта Java? - PullRequest
Новая
       59

Как удалить ссылки com.sun.jndi.ldap из моего проекта Java?

0 голосов
/ 08 марта 2019

Я реорганизую здесь инструмент Ldap с интенсивным использованием com.sun.jndi.ldap.* классов.

Как и ожидалось, я получаю предупреждения типа

[...] является внутренним проприетарным API и может быть удален в будущем выпуске

от компилятора Java. Я хотел бы устранить эти предупреждения в чистом виде.

Могу я как-нибудь это сделать? Я подозреваю, что, возможно, должен быть доступен тот же пакет maven, содержащий те же или очень похожие вызовы API, но с «лучшим» путем к пакету (например, org.something.jndi.ldap.*).

1 Ответ

1 голос
/ 08 марта 2019

Я могу придумать следующие варианты, ни один из них не идеален:

  1. Как уже упоминалось @Konrad, вы можете попробовать переписать свой инструмент LDAP, чтобы использовать javax.naming.ldap API. Если это работает, это (IMO) наиболее «перспективное» решение, но нет никаких сомнений в том, что это будет значительным усилием по кодированию.

    Проблема заключается в том, что javax.naming.ldap API, скорее всего, не предоставляют необходимую вам функциональность LDAP. Вероятно, именно поэтому ваш инструмент LDAP использует «внутренние» интерфейсы в первую очередь. В этом случае перенос инструмента для использования javax.naming.ldap API недопустим.

  2. Найдите / выберите альтернативный Java LDAP API и перепишите свой инструмент LDAP, чтобы использовать его. В отличие от предыдущего варианта, этот вариант является жизнеспособным.

    Некоторые возможные альтернативные библиотеки LDAP перечислены здесь: https://directory.apache.org/api/java-api.html

  3. Загрузите исходное дерево OpenJDK для последней версии LTS JDK (в настоящее время Java 11). Затем извлеките исходное дерево для классов com.sun.jndi.ldap.* и выполните рефакторинг кода, используя вашу любимую IDE для переименования пакетов.

    Базы кода OpenJDK лицензируются по «GPLv2 с исключением Classpath». Насколько я понимаю, если строго соблюдать требования GPLv2, вам будет разрешено распространять модифицированную версию дерева на тех же условиях лицензии. Однако Я не юрист. Вам следует обратиться за советом к юристу.

    Недостатками этого подхода являются:

    • возможный юридический риск,
    • теперь вам нужно поддерживать параллельную кодовую базу с той, что в OpenJDK, и
    • вероятность того, что Oracle может радикально пересмотреть или удалить классы из дерева исходных текстов OpenJDK.

  4. Переключитесь на использование другого инструмента LDAP, написанного кем-то другим, на основе лучшей (более открытой) библиотеки LDAP. Запишите свою текущую кодовую базу. Вероятно, это наиболее экономичное решение вашей проблемы технического долга.

Кроме того, вы можете просто проигнорировать предупреждения и продолжить текущий подход. Инструмент может стать непригодным для использования в будущем, но это еще не произошло (Java 11) и может никогда не произойти.

Если ваша настоящая цель состоит в том, чтобы просто «убрать предупреждения», чтобы достичь какой-то цели качества кода, навязанной самим себе или руководством, то есть (IMO) пустая трата времени и ресурсов. Просто игнорируйте предупреждения и примите меры, чтобы сделать качественную цель более реалистичной. (Если вы можете объяснить руководству, что эти предупреждения состоят из нескольких человеко-месяцев, они должны принять правильное решение.)

Мне неизвестна API-совместимая альтернатива com.sun.jndi.ldap.*, доступная с исходным кодом.

...