java - BigInteger/SecureRandom in jar very slow when called from Coldfusion -

i have class creates random string based on biginteger. works fine , efficient when run standalone (windows, 22ms).

private securerandom random = new securerandom();  public string testme() {      return new biginteger(130, random).tostring(30) } 

when code put library (jar) , called coldfusion (9.0.2), code hangs 1 1.5 minutes (on server, linux). code called cfc:

<cfset mytest = createobject("java", "com.acme.mytest")>  <cffunction name="runtest" access="public">     <cfset var value = mytest.testme()/> </cffunction> 

what missing?

i astonished difference not noticable on windows box.

there different securerandom strategies. on window using random seed based on host name, windows can wander off dns reverse lookup first time. can time out request after minute or so.

i ensure have recent update of java because believe problem fixed in update of java 6. (not securerandom, first network operation being incredibly slow)

btw tested on windows 7 box , first time, hung few seconds, not after that.

---

if code hanging 60 90 seconds, not due method, far more performing gc, , method stopping because allocated memory.

---

while biginteger slow, securerandom much, slower. if want faster, use plain random.

it faster if used less bits.

btw use base 36 (the maximum), rather base 30.

static volatile string dontoptimiseaway = null; public static void testrandombiginteger(random random) {     long start = system.nanotime();     int runs = 10000;     for(int i=0;i< runs;i++) {         dontoptimiseaway = new biginteger(130, random).tostring(36);     }     long time = system.nanotime() - start;     system.out.printf("%s took %.1f micro-seconds on average%n", random.getclass().getsimplename(), time/runs/1e3); } public static void main(string... ignored) {     (int = 0; < 10; i++) {         testrandombiginteger(new random());         testrandombiginteger(new securerandom());     } } 

prints

random took 1.7 micro-seconds on average securerandom took 2.1 micro-seconds on average 

the time generate string significant, still no near enough cause multi-second delay.