Add lazy holders for ulid into uuid-creator

[nimo23]

Actually, the codebase from ulid-creator and uuid-creator differs a little bit when it comes to creating the instances. For example, in ulid-creator, there is the lazy holder:

public static String getFastUlid() {
    return FastGuidCreatorLazyHolder.INSTANCE.createUlid();
}

But such lazy holders defined in UlidCreator are missing in uuid-creator project. Maybe you can include or better unify the codebase, so that ulid-creator is a 1:1 extraction from uuid-creator project.

[fabiolimace]

I'll be working on it soon. It's not a good a idea to copy and paste code.

[fabiolimace]

I created a separate project to separate ULIDs from UUIDs. https://github.com/f4b6a3/ulid-creator

Another project was created to generate ALL: UUIDs, ULIDs and TSIDs. https://github.com/f4b6a3/id-creator

If some one needs ULIDs, he can use the ulid-creator project.

If he wants to be able to create ALL types of IDs, the can use id-creator.

I still need to make some changes in the ulid-creator before releasing a minor version.

Thanks again!

[nimo23]

Thanks!

Do you think that seperating those highly related things which are all about "id-creation" into different projects is really needed? I think to keep it simple, you can only have two repositories:

• id-creator
• id-creator-benchmark

The benefits are:

• only one lib the user needs to handle
• less maintenance for you and for the user (for example, actually, the issue reportings and PR could affect and must be done on different libs/repos, which become more complex)
• only one download
• simplification for you and the user
• lib-folder with only "id-creator" instead of multiple splits..

It's a kind of the same as if apache-commons would split all its related sub-packages into different libs..not really needed. The size of this lib is really negligible and not worth to add this kind of complexity with different libs..

[fabiolimace]

All the benefits you listed are true. But a prefer keeping the UUID generator apart from the others.

Although they are "ID generators", they deal with different data types and "standards". One project tries to be compliant with an IETF document, another tries to implement an open specification, and another reinvents Twitter Ids.

The UUID generator is my priority. I'll continue it's development, but dedicating less time on it. That's the reason I removed many features from version 1.4.5, for example, the state file. I'm not sure if I'll have free time to solve the future issues as soon as needed.

Now I doubt if implementing ULID spec and imitating Snowflake was a good idea. Their respective repositories will continue public and open for PR anyway.

As for the "commons" project, it was the first name that came to my mind. It could be called "shared" or "reuse". Or maybe it would be better if didn't exist.

I'm really grateful for your advises, but unfortunately I can't unify the codebase.

[nimo23]

Now I doubt if implementing ULID spec and imitating Snowflake was a good idea.

Don't doubt:) It was a really good idea, because there is a need for different kinds of ID generators (speed, size and time based IDs does matter). The id-generator-benchmark shows the differences, which is also needed.

Although they are "ID generators", they deal with different data types and "standards".

Yes, but for the end user the only question is: which kind of ID do I want to use for this and for that. Having one id-generator where the user can select between different kinds of IDs and compare them each other is really nice.

I'm not sure if I'll have free time to solve the future issues as soon as needed.

One more reason to keep it simple for the future and take care only of two libs id-generator and id-generator-benchmark. No need to add complexity with different repos and libs. I think the different standards are not a compelling reason why to seperate them into different libraries. They all have similar use cases and end results: generating IDs. Separating them only by packages are the right approach.

id-generator with packages
->uuid
->ulid
->unid
->core (or shared or commons)

And having the packages close together, the overall usability, coding and exploring of possible simplifications and improvements are easy to spot.

But a prefer keeping the UUID generator apart from the others.

Ok no problem. It's your decision:) Maybe you can think about one more time and change your decision in the future.

I will close this issue. Thanks again!

[nimo23]

As for the "commons" project, it was the first name that came to my mind. It could be called "shared" or "reuse". Or maybe it would be better if didn't exist.

@fabiolimace Yes, it would be indeed better if this "commons" library did not exist and be integrated as a package within id-generator. I really like simplifications and having one lib dealing with ID's in general is a very good idea. The package-approach (instead of the library approach) would be ideal. With the package-approach you can also easily add new types of ID's or remove not supported ID's in the future: It's by far more maintainable and user-friendly, for you as developer and for the end user.