huxi / sulky Goto Github PK

According to the spec, when multiple ULIDs are generated within the same millisecond, the least significant bits should be incremented, however it looks like random.nextLong() is always used, which causes ULIDs to be out of order.

Would you accept a PR to update the implementation to fix this, or have any input on implementation? I was going to do something simple like using an AtomicInt that would be incremented / reset on a millisecond boundary.

dear huxi:
Recently, we have been studying ulid project and intend to use it for Java distributed microservice project. Also known as https://medium.com/zendesk-engineering/how-probable-are-collisions-with-ulids-monotonic-option-d604d3ed2de But there are many problems in the core computing logic. Can you give us some guidance on the following questions, thank you!

List of questions:
1、“ulidString must not exceed '7ZZZZZZZZZZZZZZZZZZZZZZZZZ'”，Why not "YZZZZZZZZZZZZZZZZZZZZZZZZZ"?
2、Is the maximum time stamp support like this:  (32^10 -1) / (365 * 86400000)   Or  (2^48 -1) / (365* 86400000)
3、Why “TIMESTAMP_OVERFLOW_MASK”、“TIMESTAMP_MSB_MASK” is chosen as the critical value reference?
4、What is the derivation formula of X, y value?
5、"Won't run out of space till the year 10889 AD"，What is the derivation formula of 10889 value?
                                                                                                                                                                            Chinese friends，
                                                                                                                                                                            lin tan

When using the "./gradlew" script on Ubuntu 15.10 server, the build fails with an error complaining about the Java version number:

de.huxhorn.sulky.version.JavaVersionSpec > JVM 1.8.0_66-internal is at least YeOldeJavaVersion{huge=1, major=8, minor=0, patch=66, preReleaseIdentifier="internal-ea"}

The installed Java version is 1.8.0_66-internal:

$ javac -version
javac 1.8.0_66-internal

$ java -version
openjdk version "1.8.0_66-internal"
OpenJDK Runtime Environment (build 1.8.0_66-internal-b17)
OpenJDK 64-Bit Server VM (build 25.66-b17, mixed mode)

If I try to decode the invalid ULID 'UUUUUUUUUUUUUUUUUUUUUUUUUU' it will complain with exception IllegalArgumentException("Illegal character: 'U'") while if you try to decode the invalid ULID 'IIIIIIIIIIIIIIIIIIIIIIIIII' or 'LLLLLLLLLLLLLLLLLLLLLLLLLL' you will get a valid ULID with bytes representation in hexadecimal '0021084210842108421084210842108421'