"adrian(a)jboss.org" wrote : Why are you using float for thread priority? | A thread can only take an integer priority between | 1 (Thread.MIN_PRIORiTY) and 10 (Thread.MAX_PRIORITY) I got the notion in my head that MAX_PRIORITY might not be 10, so my thought was to take a float between 1.0 and 10.0 inclusive and scale it between MIN and MAX. Though I guess I overthought it, since if someone decided to arbitrarily change the priority scale, there would probably be compatibility issues, so that would seem to be a rather unlikely scenario. "adrian(a)jboss.org" wrote : Even if it was a decimal, BigDecimal would be better than float because of the rounding errors. I doubt that someone would care if their thread at priority 10.1 was really running at 10.099999999999999644728632119950, since it would very likely end up being the same priority value anyway :-) In any case, making this a float was probably a dumb idea - I think I'll just make it an int. "adrian(a)jboss.org" wrote : But there are also some different policies such as MinThreadPoolExecutor so you can avoid the known race condition if you implement a WAIT policy when the thread pool is full (something that is not part of java.util.concurrent because of the race condition) I saw the code and the comment to that effect, but at first glance it wasn't clear what the race condition was, or how the fix worked. I'll have to look at that one more time... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187342#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...