I'm running java 8 on OSX (2.7 GHz Intel Core i5) and I get the following:

require 'benchmark'
require 'thread'
require 'securerandom'

def java_uuid
  java.util.UUID.randomUUID
end

def secure_random_uuid
  SecureRandom.uuid
end

def perform
  threads = Array.new
  10.times do
    threads << Thread.new do
      #secure_random_uuid # comment me
      java_uuid         # uncomment me
    end
  end

  threads.each do |t|
    t.join
  end
end

puts "Warming..."
Benchmark.measure { 1000.times { perform } }
puts "Testing..."
puts Benchmark.measure { 1000.times { perform } }.inspect

Note: I removed the to_s to see if I could cause jruby to lock, but failed to, so I left it off for the benchmarking.

Jruby 1.7 (1.7.20.1)(secure_random_uuid):

#<Bench... @stime=0.6099999999999994, @cstime=0.0, @real=1.1649999618530273, @total=1.9499999999999957, @cutime=0.0, @utime=1.3399999999999963>

Jruby 1.7 (1.7.20.1)(java_uuid):

#<Bench... @stime=0.6999999999999993, @cstime=0.0, @real=1.2120001316070557, @total=2.110000000000003, @cutime=0.0, @utime=1.4100000000000037>

Jruby 9k (9.0.0.0)(secure_random_uuid):

#<Bench... @stime=0.5099999999999998, @cstime=0.0, @real=1.0836994650017004, @total=1.8099999999999987, @cutime=0.0, @utime=1.299999999999999>

Jruby 9k (9.0.0.0)(java_uuid):

#<Bench... @stime=0.5700000000000003, @cstime=0.0, @real=1.1010754290036857, @total=1.9299999999999997, @cutime=0.0, @utime=1.3599999999999994>

I would love for some people to run this on a few other platforms and see what kind of results they get. For OSX, though, I don't see this as a problem since SecureRandom.uuid is actually performing faster than UUID.randomUUID.

Here are the benchmarks in my environment. It did not hang in this test.

env

OS:CentOS 6.4
Kernel: 2.6.32-358.el6.x86_64

jruby 9.0.0.0 (2.2.2) 2015-07-21 e10ec96 OpenJDK 64-Bit Server VM 24.79-b02 on 1.7.0_79-mockbuild_2015_05_14_07_23-b00 [linux-amd64]

jruby 1.7.20 (1.9.3p551) 2015-05-04 3086e6a on OpenJDK 64-Bit Server VM 1.7.0_79-mockbuild_2015_05_14_07_23-b00 [linux-amd64]

java_uuid jruby-9.0.0.0

#<Benchmark::Tms:0x552080ff @stime=1.9600000000000004, @total=4.85, @real=2.8292283043265343, @cutime=0.0, @utime=2.889999999999999, @label="", @cstime=0.0>

java_uuid jruby-1.7.20

#<Benchmark::Tms:0x5f52b430 @stime=1.9, @total=4.780000000000001, @real=2.9140000343322754, @cutime=0.0, @utime=2.880000000000001, @label="", @cstime=0.0>

secure_random_uuid jruby-9.0.0.0

#<Benchmark::Tms:0x5157e4c1 @stime=1.9399999999999995, @total=4.819999999999999, @real=2.706935055553913, @cutime=0.0, @utime=2.88, @label="", @cstime=0.0>

secure_random_uuid jruby-1.7.20

#<Benchmark::Tms:0x244d9d89 @stime=1.9099999999999997, @total=4.41, @real=2.571000099182129, @cutime=0.0, @utime=2.5, @label="", @cstime=0.0>

jruby was hanging for me on bundle install until i have asked last one to being single-threaded (--jobs=1).

anyone tried running -J-Djava.security.egd=file:/dev/./urandom so that seeding happens faster?

I got bitten hard by this on an OS reinstall. Installing an entropy daemon fixed it for me, but I spent several hours going through my SELinux policies with a fine-toothed comb trying to figure out if it was blocking me somewhere. :)

+1 for revisiting #1405

haveged fixed this for me: #1896 (comment)

should be better out of the box on JRuby 9.1 (>= 9.1.7.0 atm) my java uuid vs ruby uuid numbers are on par.