by cowtowncoder

cowtowncoder /java-uuid-generator

Java Uuid Generator (JUG) is a library for generating all (3) types of UUIDs on Java. See (http://gi...

446 Stars 83 Forks Last release: Not found Apache License 2.0 140 Commits 11 Releases

Available items

No Items, yet!

The developer of this repository has not created any items for sale yet. Need a bug fixed? Help with integration? A different license? Create a request here:

Java Uuid Generator (JUG)

JUG is a set of Java classes for working with UUIDs: generating UUIDs using any of standard methods, outputting efficiently, sorting and so on. It generates UUIDs according to the UUID specification (RFC-4122) (also see Wikipedia UUID page for more explanation)

JUG was written by Tatu Saloranta ([email protected]) originally in 2002 and has been updated over years. In addition, many other individuals have helped fix bugs and implement new features: please see

for the complete list.

JUG is licensed under Apache License 2.0.


Build Status Javadoc Tidelift


JUG can be used as a command-line tool (via class 'com.fasterxml.uuid.Jug`), or as a pluggable component.

Via Maven

Maven coordinates are:



The only dependency for JUG is the logging library:

  • For versions up to 3.x,
    is used, optionally (runtime dependency)
  • For versions 4.x and up,
    API is used: logging implementation to be provided by calling application

JDK9+ module info

Since version

, JUG defines JDK9+ compatible
, with module name of


For direct downloads, check out Project Wiki.

Using JUG

Generation itself is done by first selecting a kind of generator to use, and then calling its

method, for example:
UUID uuid = Generators.randomBasedGenerator().generate();
UUID uuid = Generators.timeBasedGenerator().generate();

If you want customize generators, you may also just want to hold on to generator instance, for example:

TimeBasedGenerator gen = Generators.timeBasedGenerator(EthernetAddress.fromInterface());
UUID uuid = gen.generate();
UUID anotherUuid = gen.generate();

Generators are fully thread-safe, so a single instance may be shared among multiple threads.

JavaDocs for project can be found from Project Wiki.


JUG versions 3.1 and later require JDK 1.6 to work, mostly to be able to access local Ethernet MAC address. Earlier versions (3.0 and before) worked on 1.4 (which introduced


Known Issues


has flawed implementation of
, which uses naive comparison of 64-bit values. This does NOT work as expected, given that underlying content is for all purposes unsigned. For example two UUIDs:

would be ordered with second one first, due to sign extension (second value is considered to be negative, and hence "smaller").

Because of this, you should always use external comparator, such as

, which implements expected sorting order that is simple unsigned sorting, which is also same as lexicographic (alphabetic) sorting of UUIDs (when assuming uniform capitalization).

Enterprise support

Available as part of the Tidelift Subscription.

The maintainers of

and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use. Learn more.


For simple bug reports and fixes, and feature requests, please simply use projects Issue Tracker, with exception of security-related issues for which we recommend filing Tidelift security contact (NOTE: you do NOT have to be a subscriber to do this).

Alternative JVM UUID generators

There are many other publicly available UUID generators. For example:

Note that although some packages claim to be faster than others, it is not clear whether:

  1. Claims have been properly verified (or, if they have, can be independently verified), AND
  2. It is not likely that performance differences truly matter: JUG, for example, can generate a millions of UUID per second per core (sometimes hitting the theoretical limit of 10 million per second) -- and it seems unlikely that generation will be bottleneck for about any use case

so it is often best to choose based on stability of packages and API.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.