Minor README, javadoc improvements

cowtowncoder · cowtowncoder · commit 3404d4f63c5a · 2023-01-07T18:41:23.000-08:00
diff --git a/README.md b/README.md
@@ -61,8 +61,12 @@ The original use case for JUG was generation of UUID values. This is done by fir
 For example:
 
 ```java
-UUID uuid = Generators.randomBasedGenerator().generate();
-UUID uuid = Generators.timeBasedGenerator().generate();
+UUID uuid = Generators.timeBasedGenerator().generate(); // Variant 1
+UUID uuid = Generators.randomBasedGenerator().generate(); // Variant 4
+UUID uuid = Generators.nameBasedgenerator().generate("string to hash"); // Variant 5
+// With JUG 4.1+:
+UUID uuid = Generators.timeBasedReorderedGenerator().generate(); // Variant 6
+UUID uuid = Generators.timeBasedEpochGenerator().generate(); // Variant 7
 ```
 
 If you want customize generators, you may also just want to hold on to generator instance:
@@ -187,9 +191,9 @@ There are many other publicly available UUID generators. For example:
 * JDK has included `java.util.UUID` since 1.4, but omits generation methods (esp. time/location based ones), has sub-standard performance for many operations and implements comparison in useless way
 * [ohannburkard.de UUID generator](http://johannburkard.de/software/uuid/)
 
-Note that although some packages claim to be faster than others, it is not clear whether:
+Note that although some packages claim to be faster than others, it is not clear:
 
-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
+1. whether laims have been properly verified (or, if they have, can be independently verified), OR
+2. whether performance differences truly matter: JUG, for example, can generate 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 any actual use case
 
 so it is often best to choose based on stability of packages and API.
diff --git a/src/main/java/com/fasterxml/uuid/impl/TimeBasedEpochGenerator.java b/src/main/java/com/fasterxml/uuid/impl/TimeBasedEpochGenerator.java
@@ -10,7 +10,8 @@
 /**
  * Implementation of UUID generator that uses time/location based generation
  * method field from the Unix Epoch timestamp source - the number of 
- * milliseconds seconds since midnight 1 Jan 1970 UTC, leap seconds excluded
+ * milliseconds seconds since midnight 1 Jan 1970 UTC, leap seconds excluded.
+ * This is usually referred to as "Variant 7".
  * <p>
  * As all JUG provided implementations, this generator is fully thread-safe.
  * Additionally it can also be made externally synchronized with other instances
diff --git a/src/main/java/com/fasterxml/uuid/impl/TimeBasedReorderedGenerator.java b/src/main/java/com/fasterxml/uuid/impl/TimeBasedReorderedGenerator.java
@@ -6,8 +6,8 @@
 
 /**
  * Implementation of UUID generator that uses time/location based generation
- * method field compatible with UUIDv1, reorderd for improved DB locality
- * (variant 6).
+ * method field compatible with UUIDv1, reorderd for improved DB locality.
+ * This is usually referred to as "Variant 6".
  * <p>
  * As all JUG provided implementations, this generator is fully thread-safe.
  * Additionally it can also be made externally synchronized with other instances
