Currently byte[] is mapped to List[int]. In general this is done because we couldn't map to numpy types and preserve the contained type. This limitation is beginning to be lifted with numpy 1.21 (where you can write things like npt.NDArray[np.int8]).
Perhaps we should move to the numpy standard form already, but if not, then we should map byte[] to bytearray rather than List[int]. I suggest bytearray rather than bytes because the former is mutable (like a Java array). The complexity in all of this is that byte is a signed integer, whereas bytes in Python are unsigned (https://stackoverflow.com/a/40951288/741316). For this reason, perhaps we should proceed with the npt.NDArray[np.int8] option (and require numpy 1.21 for array types).
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related or that one is blocking others.
Learn more.
Indeed, JPype implicitly converts both bytes and bytearray to byte[] when passed as method arguments. This is now reflected by offering Union[List[int], bytes, bytearray] for arguments.
The problem for return types is that we can not really decide how to map them - in reality they will be always jpype.JArray, we can just decide what we claim them to be. In principle, we should use jpype.JArray, but this is not generic, so we would lose the information about the element type. Since JArray (almost) behaves like a list, I advertise a generic List[...].
As a small note, the typing module explicitly states that the annotation bytes is equivalent to typing.ByteString, which also includes bytearray and memoryview. The following type-checks in MyPy:
Alright, I've run a small test on what types exactly are accepted by Java methods with annotation byte[]. It seems to accept pretty much any Sequence[int] as long as the integers are in range [−128; 127]. It also accepts bytes and its two siblings and handles their bytes correctly. Union[List[int], bytes] might still be the more informative annotation, mind you.
However, everything except jpype.JArray is passed by copy instead of reference and so any modifications to those arguments are lost. Passing a bytearray is possible but almost certainly be useless.
As for return types, I propose MutableSequence[int], since it does not have the necessary list methods. One small issue is that issubclass(JArray(JByte)(b""), Sequence) fails even though it satisfies all requirements.
I agree with the MutableSequence for return types, that's a bit closer to the truth than List. For arguments I would keep List as it is more informative. Also, we should probably add JArray to the union for arguments, it does not cost anything.
Therefore, I would propose this mapping:
deftranslateJavaArrayType(javaType:Any,typeVars:Optional[List[TypeVarStr]],isArgument:bool)->TypeStr:""" Translate a Java array type to python type. Java arrays returned by JPype are of type "JArray", but JArray is not generic. To conserve the type information of the elements, we map them to typing.MutableSequence for the time being. For arguments, JPype accepts JArray, and it does implicit conversions for Sequences/Lists for all arrays and bytes -> byte[] specifically (these conversions happen by copy)."""elementType=javaArrayComponentType(javaType)pythonElementType=pythonType(elementType,typeVars)ifisArgument:union=[TypeStr('typing.List',[pythonElementType]),TypeStr('jpype.JArray')]ifstr(elementType)=='byte':# hack: JPype supports converting bytes/bytearray to byte[] but this is not advertised in hints...union.append(TypeStr('bytes'))returnTypeStr('typing.Union',union)else:# actually JArray, but it is not genericreturnTypeStr('typing.MutableSequence',[pythonElementType])