BOY: jython PVUtil.getLong return BigInteger

[berryma4]

I'm not sure if this is new, but

longVal = PVUtil.getLong(pv[0])
pv[1].setValue(longVal)

this above code does not log an error, and it also doesn't set the value.
Changing to a double works:

doubleVal = PVUtil.getDouble(pv[0])
pv[1].setValue(doubleVal)

It seems getLong returns a BigInteger, while setValue doesn't accept BigInteger (and doesn't give an error).
I suppose this might work:

longVal = PVUtil.getLong(pv[0])
pv[1].setValue(longVal.longValue())

Is this a new jython return type mapping, or was it always broken?

[kasemir]

I've seen that before with jython, I believe within scan scripts.

Trouble is that
pv[1].setValue(PVUtil.getLong(pv[0]))
looks good in Java, it's really a quirk of jython to turn the Long into a BigInteger.

Would be wrong for the PV layer to accept a BigInteger since it can't really handle arbitrary long numbers.

Working around the jython quirk in jython by using double or longVal.longValue() seems better.

[berryma4]

As long as we know it's not new. I would hate for @shroffk to go crazy on deploying 4.3 with scripts acting "different".

[berryma4]

Wait! longVal.longValue() will just return a BigInteger again, no? Won't the long map right back to a BigInteger?

I guess the real question is, how will this be handled in the Display Builder?

[kasemir]

It's currently the same in the display builder:

val = PVUtil.getLong(pvs[0])

# Prints "long"
print val.__class__.__name__

# Fails because val is passed back into Java code as BigInteger
pvs[1].setValue(val)

# Works because passing a double into the Java code
pvs[1].setValue(float(val))

For what it's worth, the JCA/CAJ channel only has put() calls for byte, short, int, float, double, String. Not for a Java long. So the PVUtil.getLong() may have been a bad idea, could only apply to V4 data. For Channel Access, the longest integer you get is a Java int, not long.