It's not needed to parse the whole ULID timestamp. All is needed is to
check the first two bits. They are extra bits added by the base-32
encoding. Both bits must be ZERO.
Moved v4 generators to UlidStruct
List of Changes:
Create UlidStruct.toUuid4()
Create UlidStruct.toString4()
Create UlidCreatorUuidTest // test cases
Create UlidCreatorStringTest // test cases
Add UlidUtil.extractUnixMilliseconds(UUID ulid)
Add UlidUtil.extractUnixMilliseconds(String ulid)
Now it can generate UUIDs and ULIDs compatible with RFC-4122 UUID v4.
List of Changes:
Created UlidCreator.getUlid4();
Created UlidCreator.getUlidString4();
Updated README.md
Coverage 94.1%
Now the generation of ULID in string format is 2.5x faster than before.
List of changes:
Optimize UlidSpecCreator
Optimize UlidConverter
Optimize UlidValidator
Create UlidStruct // class for internal use and test cases
Add test cases
Update README.md
Update javadoc
Coverage 94.3%
Remove UlidCreatorException // extremely unlikely to occur overrun
Add UlidCreator.toString() // from UUID to crockford base 32
Change DefaultRandomStrategy // no need for thread local SecureRandom
Update test cases
Update README.md
Update javadoc
Test coverage: 94.2%
Rename UlidBasedGuidCreator to UlidSpecCreator
Add method UlidCreator.fromString()
Add RandomStrategy for UlidSpecCreator
Add DefaultRandomStrategy using thread local SecureRandom
Add OtherRandomStrategy for any instance of Random
Add tests cases
Optimize UlidConverter.fromString()
Optimize UlidConverter.toString()
Optimize UlidValidator.isValid()
Optimize UlidSpecCreator
Update README.md
Update tests cases
In the previous implementation an exception was thrown when the random
part reached 2^80. It meant that if the first random generated within a
millisecond was (2^80 - 1000), the generator could thrown the exception
when only 1000 requests was made. It was very difficult, but possible.
Now it only occurs in the extremely unlikely event that you manage to
generate more than 2^80 ULIDs within the same millisecond.
Fabio Lima