Haruskah perpustakaan perangkat lunak kecil saya menghindari menggunakan perpustakaan lain?

Saya baru saja merilis perpustakaan Java kecil yang hanya menawarkan beberapa kelas dan metode. Karena saya membangun proyek dengan Maven, saya segera menggunakan beberapa perpustakaan pihak ketiga untuk mencapai tujuan saya, khususnya:

commons-lang3 (untuk beberapa hal umum Java)
slf4j-api (untuk logging)
commons-io (untuk sedikit file-file kecil - secara harfiah membaca file sekali, saya pikir)

Saya tidak ingin perpustakaan saya tampak kembung di mata orang lain. Haruskah saya mencoba menghilangkan ketergantungan saya pada perpustakaan ini untuk meminimalkan jejak saya? Adakah saran tentang jenis perpustakaan apa yang sebaiknya dihindari ketika mempertimbangkan untuk menggunakan lebih banyak di masa depan?

java libraries maven

— Duncan Jones
sumber

bagian konkret dari pertanyaan Anda terlihat dapat dijawab: proyek Anda ditambah lib konkret ditambah apakah itu OK. Masalahnya adalah, Anda mengejanya bersama dengan bagian umum "harus ... kecil ... hindari". Seperti yang ada saat ini, pertanyaan ini tidak cocok untuk format Tanya Jawab kami. Kami berharap jawaban didukung oleh fakta, referensi, atau keahlian khusus, tetapi pertanyaan ini kemungkinan akan mengundang debat, argumen, polling, atau diskusi panjang. Jika Anda merasa bahwa pertanyaan ini dapat diperbaiki, lihat FAQ untuk panduan.

— nyamuk

@gnat Permintaan maaf saya. Sebagai pengguna Stack Overflow biasa, saya cenderung mengasumsikan pertanyaan subyektif yang dapat diterima pada Programmer. Apakah ada situs Stack Exchange di mana masalah seperti itu OK? Sementara itu, saya akan menghapus ketidakjelasan dari pertanyaan saya.

— Duncan Jones

@gnat Pertanyaan ini baik-baik saja, bahkan dalam bentuk aslinya.

— Thomas Owens

@ThomasOwens dengan segala hormat, saya rasa tidak; untuk versi asli, saya dengan cepat menemukan dua jawaban dengan rekomendasi yang berlawanan, keduanya masuk akal: permainan polling selamat datang

— agas

@gnat Hanya dua? Tidak apa-apa. Biarkan mereka diposting dan dipilih. Dua jawaban yang berpotensi benar dengan alasan dan alasan yang berlawanan tidak membuat pertanyaan menjadi buruk. Baik 3 atau 4 atau bahkan 5. Ini adalah pertanyaan yang dibentuk dengan baik yang merupakan masalah yang harus dihadapi oleh pengembang perpustakaan, dan bebannya kemudian diletakkan pada jawaban untuk menjadi jawaban yang baik .

— Thomas Owens

Jawaban:

Saya menjawab ini dengan mempertimbangkan situasi spesifik Anda. Saya akan mengatakan tidak apa-apa menggunakan perpustakaan itu. Pastikan slf4j-api Anda tidak membawa serta implementasinya. Maksud saya, menandai ketergantungan implementasi sebagai "tes". MISALNYA:

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

Ini dijelaskan secara rinci pada FAQ SLF4j.

Adapun dua lainnya, IME, mereka selalu kompatibel ke belakang. Karena itu, jika 5 tahun dari sekarang saya perlu menggunakan perpustakaan Anda tetapi Anda menggunakan versi lama dari itu, saya hanya bisa mengecualikan dependensi Anda dan kode kami masih akan berfungsi. Dengan kata lain, dengan menggunakan perpustakaan khusus ini Anda tidak akan memperkenalkan neraka-neraka untuk orang lain.

Jika saya menggunakan perpustakaan Anda melalui pakar, saya tidak akan melihat apakah perpustakaan Anda membengkak atau tidak. Saya hanya akan bergantung pada milik Anda dan menggunakannya. Saya pikir lebih penting bahwa kode Anda berfungsi dengan benar daripada mendapat jejak yang lebih kecil. Saya lebih suka Anda menggunakan commons-io daripada menciptakan kembali roda dengan bug di dalamnya.

— Daniel Kaplan
sumber

Terima kasih atas tanggapannya, saya pikir kami secara luas menyetujui pendekatan yang harus saya ambil. Hanya untuk memperbaiki satu bit - cara seseorang harus memasukkan slf4j dalam proyek perpustakaan adalah dengan memasukkan slf4j-apidan tidak ada artefak terkait lainnya, yang disediakan atau tidak. Lihat slf4j.org/manual.html#projectDep .

— Duncan Jones

Saya ingat beberapa latihan yang merusak otak (milyaran excludes iirc) saya harus membuat ketika modul tertentu dalam dependensi saya tidak bisa "setuju" pada versi slf4j. Dari jawaban Anda sepertinya perancang modul akan mengeksposnya provided, tidak akan ada masalah seperti itu, benar?

— nyamuk

@gnat Biasanya itu akan diselesaikan (setidaknya dalam Maven), dengan mendeklarasikan satu versi yang disukai dalam POM Anda. Maven mengambil versi "terdekat" yang ditentukan untuk artefak dan POM langsung melebihi ketergantungan transitif. Mungkin ini adalah perubahan perilaku selama rilis Maven 2.x.

— Duncan Jones

+1 untuk menentukan slf4j sebagai provided- sangat tidak mengganggu.

— Gary Rowe

@DuncanJones terima kasih, saya mungkin melewatkan ini saat itu. Versi pakar saya adalah 2.2 atau 2.3, tidak dapat mengingat yang mana (meskipun saya yakin ingat bagaimana mvn dependency:analyzemembawa versi omong kosong sampai dikecualikan :)

— agung

Tidak.

"Kembung" adalah mitos. Tidak peduli berapa banyak kode yang ada di pustaka Anda, jika sebagian dari kode itu tidak pernah digunakan, kode itu tidak akan dipetakan - tidak akan berdampak apa pun pada kinerja atau jejak memori.

Di sisi lain, jika Anda membutuhkan fungsionalitas ekstra itu, Anda memiliki dua pilihan. Anda dapat menulis sendiri dan menghabiskan banyak waktu dan upaya memecahkan masalah yang sudah diselesaikan orang lain sebelumnya, atau Anda dapat memilih untuk menggunakan solusi yang sudah ada (dan telah diuji / di-debug / dll).

Itu membuat kami memiliki ukuran unduhan dan jejak ruang disk, dan kecuali Anda berbicara angka-angka konyol, pada tahun 2013 itu adalah dua faktor yang harusnya dekat dengan bagian bawah daftar hal-hal yang perlu Anda khawatirkan.

— Maximus Minimus
sumber