<enebo[m]>
jimtng: yeah earlier versions of Java and earlier versions of JRuby both. It seems odd to see this error as the parameters are not all that unusual. The nil -> null can at times confuse deciding on overloads but it shouldn't in this case.
<enebo[m]>
but since you said the string param does make it work it must be related to that
<enebo[m]>
my element icon is a bunch of vertical stripes now
<headius>
on 11 seems to be a bit slower starting but ultimately the same relative result
<enebo[m]>
from a wall clock perspective I am sure a larger run will not change but I am wondering if overall CPU is reduced if you do something bigger
<headius>
it's a bit slower on gem list so there's still some overhead getting going I'd need to sort out
<headius>
interesting... --dev with invokedynamic.handles is fastest starting on gem list and -e 1
<headius>
few classes to load I suppose
<headius>
fewer
<headius>
it is amazing how much we speed up running in the same JVM repeatedly
<headius>
running gem list in a loop within the same JVM gets down to 0.73s from 3.88s
<headius>
looping in same JVM indy eventually wins at 0.59s
<headius>
even though we are throwing away jitted stuff every loop
<jimtng[m]>
enebo: if this is caused by jruby, should I create an issue? Unfortunately I don't know how to create a simple reproducible project. In the mean time I've simply worked around it by calling a different overload with two arguments (instead of three) provided by the java class when the first one is nil.