It's just historical, before we are generating thread id manually using an
atomic int. Then we removed that code and replaced by native thread id (by
casting to int). It's not a problem for the jvms we know at the moment but
that can change one day...

~Sent from mobile
On Dec 15, 2013 6:16 PM, "Jaromir Hamala" <notifications@github.com> wrote:

> In hazelcast/src/main/java/com/hazelcast/core/ILock.java:
>
> > @@ -126,4 +126,11 @@
> >       */
> >      long getRemainingLeaseTime();
> >
> > +    /**
> > +     * Returns textual description of lock owner.
> > +     *
> > +     * @return textual description of lock owner, {@code} null if the lock is not being held by any thread
> > +     */
> > +    String getLockOwner();
>
> BTW, what is the reason to cast the threadId to int?
> https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/util/ThreadUtil.java#L22
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/hazelcast/hazelcast/pull/1388/files#r8355355>
> .
>