Use ulid library safe for graalvm native compilation

[mcruzdev]

Many thanks for submitting your Pull Request ❤️!

What this PR does / why we need it:

• Remove the com.github.f4b6a3:ulid-creator dependency.
• Add a new dependency de.huxhorn.sulky:de.huxhorn.sulky.ulid for ULID generation.
• Add a default WorkflowInstanceIdFactory implementation (UlidWorkflowInstanceIdFactory)
• Sort dependencies version

Closes #812

[fjtirado]

I think this should be more lazy.
Reason is that, with this implementaiton, if the user is replacing this factory, the secure ramdon and the ULID are still created, but never used.
There are two possibilities to achieve that:

• creare this class, as it is, (well, secureRamdon does not need to be a member in any case) in a lazy way in the WorkflowApplication (so create it only when the user has not set another WorkflowInsanceIdFactory)
• Leave WorkflowApplication as it is and create the ULID (and the SecureRamdon) when previousUlid is null.

[fjtirado]

I now explain why I prefer the first one (lazy initialization of the factory in WorkflowApplication)

The get method can be simplified by creating previousUlid in the constructor, so you write a not synchronized get.

@Override
// note that you do not need to syncronized this
  public String get() {
       String result=  currentUlid.toString();
      currentUlid = ulid.nextMonotonicValue(currentUlid);
      return result;
  }

The constructor will look like

private final ULID ulid;
private ULID.Value currentUlid;

public MonotonicUlidWorkflowInstanceIdFactory () {
   ulid = new ULID(new SecureRandom());
   currentUlid = ulid.nextValue();
}

And in workflowapplicationbuilder.build you set the factory to MonoloictUlidWorkflowInstanceFactory if the id factory it is null (the user has not set its own one) rather than in builder initialization

[fjtirado]

@mcruzdev Posible solution proposed, please take a look

[fjtirado]

I now explain why I prefer the first one (lazy initialization of the factory in WorkflowApplication)

The get method can be simplified by creating previousUlid in the constructor, so you write a not synchronized get.

@Override
// note that you do not need to syncronized this
  public String get() {
       String result=  currentUlid.toString();
      currentUlid = ulid.nextMonotonicValue(currentUlid);
      return result;
  }

The constructor will look like

private final ULID ulid;
private ULID.Value currentUlid;

public MonotonicUlidWorkflowInstanceIdFactory () {
   ulid = new ULID(new SecureRandom());
   currentUlid = ulid.nextValue();
}

And in workflowapplicationbuilder.build you set the factory to MonoloictUlidWorkflowInstanceFactory if the id factory it is null (the user has not set its own one) rather than in builder initialization

[mcruzdev]

Reason is that, with this implementaiton, if the user is replacing this factory, the secure ramdon and the ULID are still created, but never used.

Good catch!

The get method can be simplified by creating previousUlid in the constructor, so you write a not synchronized get.

@fjtirado, do we need to guarantee no duplicated keys in a thread-safe way? If not, I agree with you to remove the synchronized or similar locks.

[fjtirado]

@mcruzdev
To avoid synchronization (and the risk derived from not using it), we can write

private final AtomicReference<ULID.Value> currentUlid;

public MonotonicUlidWorkflowInstanceIdFactory () {
   ulid = new ULID(new SecureRandom());
   currentUlid = new AtomicReference<>(ulid.nextValue());
}
 public String get() {   
      return currentUlid.getAndSet(ulid.nextMonotonicValue(currentUlid));
  }

Note: Im asuming nextMonotoicValue is thread-safe (it wont crash when invoked simoultaneuously from different threads),

[mcruzdev]

I added the updateAndGet to avoid race window and the user gets a ulid closer to the startedAt.