Должна ли моя небольшая библиотека программного обеспечения избегать использования других библиотек?

Я только что выпустил небольшую библиотеку Java, которая предлагает только несколько классов и методов. Поскольку я создавал проект с Maven, я сразу использовал несколько сторонних библиотек для достижения своих целей, а именно:

commons-lang3 (для некоторых общих вещей Java)
slf4j-api (для регистрации)
commons-io (для небольшого количества файлового материала - я думаю, буквально читая файл один раз)

Я не хочу, чтобы моя библиотека выглядела раздутой в глазах других. Должен ли я пытаться убрать свою зависимость от этих библиотек, чтобы свести к минимуму мой след? Любой совет, какие типы библиотек лучше всего избегать при рассмотрении вопроса об использовании большего количества в будущем?

java libraries maven

— Дункан Джонс
источник

конкретная часть вашего вопроса выглядит отвечающей: ваш проект плюс конкретные библиотеки плюс все в порядке. Проблема в том, что вы написали это вместе с общей частью "следует ... мало ... избегать". В настоящее время этот вопрос не очень подходит для нашего формата вопросов и ответов. Мы ожидаем, что ответы будут подкреплены фактами, ссылками или конкретными знаниями, но этот вопрос, скорее всего, вызовет дебаты, споры, опрос или расширенное обсуждение. Если вы считаете, что этот вопрос может быть улучшен, см. FAQ для руководства.

— комнат

@gnat Мои извинения. Будучи обычным пользователем переполнения стека, я склонялся к предположению, что на программистов допускаются слегка субъективные вопросы. Есть ли на сайте Stack Exchange такие проблемы? А пока я уберу неопределенность с моего вопроса.

— Дункан Джонс

@gnat Этот вопрос в порядке, даже в оригинальном виде.

— Томас Оуэнс

@ThomasOwens при всем уважении, я так не думаю; для оригинальной версии я быстро вычислил два ответа с противоположными рекомендациями, оба разумно обоснованы: добро пожаловать игра на опрос

— комнат

@gnat Только два? Все в порядке. Пусть они будут опубликованы и проголосовали. Два потенциально правильных ответа с оправданием и аргументацией, которые противоположны, не делают вопрос плохим. Ни 3, ни 4, ни даже 5. Это правильно сформулированный вопрос, с которым разработчики библиотек должны иметь дело, и затем бремя ложится на ответы, чтобы получить хорошие ответы .

— Томас Оуэнс

Ответы:

Я отвечаю на это с учетом вашей конкретной ситуации. Я бы сказал, что это нормально - использовать эти библиотеки. Просто убедитесь, что ваш slf4j-api не несет с собой реализацию. Под этим я подразумеваю пометить зависимость реализации как «тест». НАПРИМЕР:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.7.2</version>
    <scope>test</scope>
</dependency>

Это подробно описано в FAQ по SLF4j.

Что касается двух других, IME, они всегда обратно совместимы. Поэтому, если через 5 лет мне нужно будет использовать вашу библиотеку, а вы используете старую ее версию, я могу просто исключить ваши зависимости, и наш код все равно будет работать. Другими словами, используя эти специфические библиотеки, вы не будете использовать jar-hell для других.

Если я использую вашу библиотеку через Maven, я не буду замечать, если ваша библиотека раздутая или нет. Я просто буду зависеть от твоего и использовать его. Я думаю, что более важно, чтобы ваш код работал правильно, а не занимал меньше места. Я предпочитаю использовать commons-io, а не изобретать велосипед с ошибкой.

— Даниэль Каплан
источник

Спасибо за ответ, я думаю, что мы в целом согласны с подходом, который я должен использовать. Просто чтобы исправить один бит - способ, которым нужно включить slf4j в проект библиотеки, состоит в том, чтобы просто включить slf4j-apiи никаких других связанных артефактов, предоставленных или нет. См. Slf4j.org/manual.html#projectDep .

— Дункан Джонс

Я вспоминаю некоторые повреждающие мозг упражнения (zillions excludes iirc), которые мне приходилось выполнять, когда определенные модули в моих зависимостях не могли «договориться» о версии slf4j. Из вашего ответа похоже, что если бы разработчики модулей выставили его как provided, не было бы таких проблем, верно?

— комнат

@gnat Обычно это можно решить (по крайней мере, в Maven), объявив одну предпочитаемую версию в вашем POM. Maven выбирает «ближайшую» версию, определенную для артефакта, и немедленное POM перевешивает переходные зависимости. Возможно, это было поведенческое изменение во время релиза Maven 2.x.

— Дункан Джонс

+1 за указание slf4j как provided- очень ненавязчиво.

— Гэри Роу

@DuncanJones спасибо, я, наверное, пропустил это тогда. Моя версия maven была 2.2 или 2.3, я не могу вспомнить, какая из них (хотя я точно помню, как mvn dependency:analyzeприносила дерьмовые версии, пока не была исключена :)

— gnat

Нет.

«Раздувание» - это миф. Независимо от того, сколько кода находится в вашей библиотеке, если часть этого кода никогда не используется, он не будет перемещаться по страницам - это никак не повлияет ни на производительность, ни на объем памяти.

С другой стороны, если вам нужна дополнительная функциональность, у вас есть два варианта. Вы можете написать его самостоятельно и потратить много времени и усилий на решение проблем, которые другие уже решали ранее, или вы можете использовать решение, которое уже существует (и было проверено / отлажено / и т. Д.).

Это оставляет нам размер загружаемого файла и объем дискового пространства, и если вы не говорите глупых цифр, в 2013 году это два фактора, которые должны быть ближе к нижней части списка вещей, о которых вам нужно беспокоиться.

— Максимус Минимус
источник