Yep. Both Thread and Fiber are abstracted into a Strand. So Strand.currentStrand returns the current fiber/thread, Strand.sleep sleeps etc.. Locks and channels work with strands, too, so that both fibers and threads can synchronize on the same data, and even actors are assigned to a strand, so that an actor can run in either a fiber or a thread.
Then, you pick the strand implementation (lightweight or heavyweight) -- heavyweight for computation-heavy code like video encoding, lightweight for anything that blocks often -- and if you pick a fiber you can further select a particular scheduler, with the default being work-stealing (like in Erlang or Go), but you can plug your own (and control such stuff as CPU pinning for certain schedulers).
By using java.lang.Thread?