[JExtract/JNI] Unable to map `UInt8` to Java
Closed this issue · 6 comments
Source code at PureSwift/Bluetooth#197
coleman@Alseys-MacBook-Pro Bluetooth % SWIFT_JAVA=1 swift build --target Bluetooth
[1/1] Planning build
Building for debugging...
Generated /Users/coleman/Developer/Bluetooth/.build/plugins/outputs/bluetooth/Bluetooth/destination/GenerateBluetoothDefinitions/DeclarationUUID.swift
Generated /Users/coleman/Developer/Bluetooth/.build/plugins/outputs/bluetooth/Bluetooth/destination/GenerateBluetoothDefinitions/UnitIdentifiers.swift
Generated /Users/coleman/Developer/Bluetooth/.build/plugins/outputs/bluetooth/Bluetooth/destination/GenerateBluetoothDefinitions/ServiceUUID.swift
Generated /Users/coleman/Developer/Bluetooth/.build/plugins/outputs/bluetooth/Bluetooth/destination/GenerateBluetoothDefinitions/DescriptorUUID.swift
Generated /Users/coleman/Developer/Bluetooth/.build/plugins/outputs/bluetooth/Bluetooth/destination/GenerateBluetoothDefinitions/CharacteristicUUID.swift
Generated /Users/coleman/Developer/Bluetooth/.build/plugins/outputs/bluetooth/Bluetooth/destination/GenerateBluetoothDefinitions/MemberUUID.swift
Generated /Users/coleman/Developer/Bluetooth/.build/plugins/outputs/bluetooth/Bluetooth/destination/GenerateBluetoothDefinitions/CompanyIdentifiers.swift
JExtractSwiftLib/JNISwift2JavaGenerator+JavaTranslation.swift:71: Fatal error: unsupported known type: uint8
[163/165] Generate Java wrappers for Swift types
@madsodgaard Can types that don't have a native Java counterpart just be omitted from the generated code? I'm more than happy to use jextract just as a way to pass around Opaque Swift types, I can write additional Java / JNI later if I really need that value.
@colemancda Yes, I'll make sure that we just omit any unsupported types for now, instead of crashing.
That's a good first step, to exclude them.
About UInt8 though we probably need to think some more, it's a very common thing and perhaps we could do some re-mapping values... I'm not sure what would be a good way to do this though, a class wrapper that is UnsignedInteger is possible of course, but not without overhead... maybe that would be good though?
There is prior art like that in Guava tbh https://guava.dev/releases/23.0/api/docs/com/google/common/primitives/UnsignedInteger.html , so we could do the same and import UInt8 as UnsignedByte -- and all other U versions of types, by making corresponging record types on the java side.
@ktoso yup, this is on my todo list to look into supporting the unsigned types as well.