The functions math.floor() and math.ceil() round down and up and always produce an integer.
For java.awt.Color, you may be better off using the single-integer constructor, since there is not a float equivalent. That way the same constructor will be chosen every time.
Here's a working example:
-- return Java Color with r, g, b as floats in range [0,1]
function color(r, g, b)
local ir = math.floor(r * 255)
local ig = math.floor(g * 255)
local ib = math.floor(b * 255)
local packed_rgb = ir*(256*256) + ig*256 + ib
return luajava.newInstance("java.awt.Color", packed_rgb)
end
The failure case you provided will then have the expected result:
-- test the example
print( color(1, .2, .2) )
> java.awt.Color[r=255,g=51,b=51]
The issue is with runtime selection of overloaded functions based on numeric types. For the java Color class, there are so many overloads that it triggers a bug in the selection logic within luaj for numbers whose float and double values differ slightly (i.e. .2).
Long-term it may be better if luaj exposes a mechanism to get at specific methods based on their full call signatures, but as of luaj-3.0-beta3, this looks to be the most reliable way to invoke the overload you want.