java uuid generator
1.0.0
JUG adalah sekumpulan kelas Java untuk bekerja dengan UUID: menghasilkan UUID menggunakan metode standar apa pun, menghasilkan keluaran secara efisien, mengurutkan, dan sebagainya. Ini menghasilkan UUID sesuai dengan spesifikasi UUID (RFC-4122) (lihat halaman UUID Wikipedia untuk penjelasan lebih lanjut)
JUG ditulis oleh Tatu Saloranta ([email protected]) aslinya pada tahun 2002 dan telah diperbarui selama bertahun-tahun. Selain itu, banyak orang lain yang telah membantu memperbaiki bug dan menerapkan fitur baru: silakan lihat release-notes/CREDITS untuk daftar lengkapnya.
JUG dilisensikan di bawah Lisensi Apache 2.0.
JUG mendukung kedua versi "klasik" yang ditentukan dalam RFC 4122]:
1 : berdasarkan waktu/lokasi3 dan 5 : berbasis hash nama4 : berdasarkan angka acakdan varian baru (pada 2022-2024) yang diusulkan (lihat uuid6 dan RFC-4122 bis):
6 : menyusun ulang varian versi 1 (dengan urutan leksikografis)7 : Stempel waktu Unix + varian berbasis acak (juga dengan pemesanan leksikografis) | Jenis | Status |
|---|---|
| Membangun (CI) | |
| Artefak | |
| Sponsor OSS | |
| Javadocs | |
| Cakupan kode (5.x) | |
| Skor OpenSSF |
JUG dapat digunakan sebagai alat baris perintah (melalui kelas com.fasterxml.uuid.Jug ), atau sebagai komponen yang dapat dicolokkan.
Koordinat Maven adalah:
< dependency >
< groupId >com.fasterxml.uuid</ groupId >
< artifactId >java-uuid-generator</ artifactId >
< version >5.1.0</ version >
</ dependency >Gradasi:
implementation ' com.fasterxml.uuid:java-uuid-generator:5.1.0 ' Satu-satunya ketergantungan untuk JUG adalah perpustakaan logging:
log4j digunakan, opsional (ketergantungan runtime)slf4j API digunakan: implementasi logging disediakan dengan memanggil aplikasi Sejak versi 3.2.0 , JUG mendefinisikan module-info.class yang kompatibel dengan JDK9+, dengan nama modul com.fasterxml.uuid .
Untuk unduhan langsung, lihat Project Wiki.
Kasus penggunaan asli JUG adalah pembuatan nilai UUID. Hal ini dilakukan dengan terlebih dahulu memilih jenis generator yang akan digunakan, dan kemudian memanggil metode generate() -nya. Misalnya:
UUID uuid = Generators . timeBasedGenerator (). generate (); // Version 1
UUID uuid = Generators . randomBasedGenerator (). generate (); // Version 4
UUID uuid = Generators . nameBasedgenerator (). generate ( "string to hash" ); // Version 5
// With JUG 4.1+: support for https://github.com/uuid6/uuid6-ietf-draft versions 6 and 7:
UUID uuid = Generators . timeBasedReorderedGenerator (). generate (); // Version 6
UUID uuid = Generators . timeBasedEpochGenerator (). generate (); // Version 7
// With JUG 5.0 added variation:
UUID uuid = Generators . timeBasedEpochRandomGenerator (). generate (); // Version 7 with per-call random valuesJika Anda ingin menyesuaikan generator, Anda mungkin juga ingin mempertahankan instance generator:
TimeBasedGenerator gen = Generators . timeBasedGenerator ( EthernetAddress . fromInterface ());
UUID uuid = gen . generate ();
UUID anotherUuid = gen . generate (); Jika mesin Anda memiliki pengaturan jaringan IP standar, metode pabrik Generators.defaultTimeBasedGenerator (ditambahkan di JUG 4.2) akan mencoba menentukan antarmuka jaringan mana yang sesuai dengan rute default untuk semua lalu lintas jaringan keluar, dan menggunakannya untuk membuat generator berbasis waktu. Ini mungkin merupakan pilihan yang baik untuk skenario penggunaan umum jika Anda menginginkan generator UUID versi 1.
TimeBasedGenerator gen = Generators . defaultTimeBasedGenerator ();
UUID uuid = gen . generate ();
UUID anotherUuid = gen . generate ();Generator sepenuhnya aman untuk thread, sehingga satu instance dapat dibagikan ke beberapa thread.
Javadocs untuk informasi lebih lanjut dapat ditemukan dari Project Wiki.
java.util.UUID menjadi byte[] Terkadang Anda mungkin ingin mengonversi dari java.util.UUID menjadi serialisasi eksternal: misalnya, sebagai array String atau byte ( byte[] ). Konversi ke String mudah dilakukan dengan UUID.toString() (disediakan oleh JDK), tetapi tidak ada fungsi serupa untuk mengonversi menjadi byte[] .
Namun kelas UUIDUtil menyediakan metode untuk konversi yang efisien:
byte[] asBytes = UUIDUtil.asByteArray(uuid);
// or if you have longer buffer already
byte[] outputBuffer = new byte[1000];
// append at position #100
UUIDUtil.toByteArray(uuid, outputBuffer, 100);
java.util.UUID dari String, byte[] Nilai UUID sering kali diteruskan sebagai java String s atau byte[] s (byte array), dan konversi diperlukan untuk mendapatkan instance java.util.UUID yang sebenarnya. JUG telah mengoptimalkan fungsionalitas konversi yang tersedia melalui kelas UUIDUtil (paket com.fasterxml.uuid.impl ), digunakan sebagai berikut:
UUID uuidFromStr = UUIDUtil.uuid("ebb8e8fe-b1b1-11d7-8adb-00b0d078fa18");
byte[] rawUuidBytes = ...; // byte array with 16 bytes
UUID uuidFromBytes = UUIDUtil.uuid(rawUuidBytes)
Perhatikan bahwa meskipun JDK memiliki fungsi untuk membuat UUID dari String , seperti:
UUID uuidFromStr = UUID.fromString("ebb8e8fe-b1b1-11d7-8adb-00b0d078fa18");
ini agak lebih lambat dibandingkan versi JUG: untuk informasi lebih lanjut, baca Mengukur kinerja Java UUID.fromString().
Toples JUG dibuat berdasarkan target/ :
target/java-uuid-generator-5.1.0-SNAPSHOT.jar
juga dapat digunakan sebagai alat pembuatan UUID baris perintah sederhana.
Untuk melihat penggunaan Anda dapat melakukan sesuatu seperti:
java -jar target/java-uuid-generator-5.1.0-SNAPSHOT.jar
dan dapatkan instruksi lengkap, tetapi untuk menghasilkan 5 UUID berbasis acak, Anda akan menggunakan:
java -jar target/java-uuid-generator-5.1.0-SNAPSHOT.jar -c 5 r
(di mana -c (atau --count ) berarti jumlah UUID yang akan dihasilkan, dan r berarti versi berbasis Acak)
CATATAN: fungsi ini disertakan pada JUG 4.1 -- dengan versi sebelumnya Anda memerlukan pemanggilan yang lebih lama karena metadata Jar tidak menentukan "Kelas Utama". Jika demikian, Anda perlu menggunakannya
java -cp target/java-uuid-generator-5.1.0-SNAPSHOT.jar com.fasterxml.uuid.Jug -c 5 r
JUG versi 3.1 dan yang lebih baru memerlukan JDK 1.6 agar dapat berfungsi, sebagian besar agar dapat mengakses alamat MAC Ethernet lokal. Versi sebelumnya (3.0 dan sebelumnya) bekerja pada 1.4 (yang memperkenalkan java.util.UUID ).
JUG versi 5.0 dan yang lebih baru memerlukan JDK 8 agar berfungsi.
java.util.UUID JDK memiliki implementasi yang cacat pada compareTo() , yang menggunakan perbandingan nilai 64-bit yang naif. Ini TIDAK berfungsi seperti yang diharapkan, mengingat konten yang mendasarinya untuk semua tujuan tidak ditandatangani. Misalnya dua UUID:
7f905a0b-bb6e-11e3-9e8f-000000000000
8028f08c-bb6e-11e3-9e8f-000000000000
akan diurutkan dengan yang kedua terlebih dahulu, karena perluasan tanda (nilai kedua dianggap negatif, dan karenanya "lebih kecil").
Oleh karena itu, Anda harus selalu menggunakan pembanding eksternal, seperti com.fasterxml.uuid.UUIDComparator , yang mengimplementasikan urutan pengurutan yang diharapkan yaitu pengurutan sederhana tanpa tanda tangan, yang juga sama dengan pengurutan UUID leksikografis (abjad) (bila mengasumsikan kapitalisasi seragam) .
Tersedia sebagai bagian dari Langganan Tidelift.
Pengelola java-uuid-generator dan ribuan paket lainnya bekerja sama dengan Tidelift untuk memberikan dukungan komersial dan pemeliharaan untuk dependensi sumber terbuka yang Anda gunakan untuk membangun aplikasi Anda. Menghemat waktu, mengurangi risiko, dan meningkatkan kesehatan kode, sekaligus membayar pengelola dependensi yang Anda gunakan. Pelajari lebih lanjut.
Untuk laporan bug dan perbaikan sederhana, serta permintaan fitur, cukup gunakan Pelacak Masalah proyek, dengan pengecualian masalah terkait keamanan yang kami sarankan untuk mengajukan kontak keamanan Tidelift (CATATAN: Anda TIDAK harus menjadi pelanggan untuk melakukan ini).
Ada banyak generator UUID lain yang tersedia untuk umum. Misalnya:
java.util.UUID sejak 1.4, tetapi menghilangkan metode pembuatan (khususnya yang berbasis waktu/lokasi), memiliki kinerja di bawah standar untuk banyak operasi dan mengimplementasikan perbandingan dengan cara yang tidak bergunaPerhatikan bahwa meskipun beberapa paket mengklaim lebih cepat daripada yang lain, hal ini tidak jelas:
jadi seringkali yang terbaik adalah memilih berdasarkan stabilitas paket dan API.
