Fredrick Eisele
01/21/2022, 9:14 PMkpgalligan
01/21/2022, 9:36 PMFredrick Eisele
01/21/2022, 9:37 PMMichael Paus
01/22/2022, 11:04 AMFredrick Eisele
01/22/2022, 5:59 PMMichael Paus
01/22/2022, 6:35 PMkpgalligan
01/22/2022, 7:02 PMcore
has a fair bit of mockito happening. The only mocking libraries for native are restricted to interfaces. You could maybe use Mockk for JVM and JS, but I haven’t really tried that myself. I saw some other test libraries included but I’d guess mocking will be the tricky one. Figuring out how to get the tests running is obviously useful to verify the port didn’t break things too much, but you may be stuck running on just the JVM to start. That’s OK-ish if the code is mostly common, but not ideal.
A quick browse through the code suggests reflection is being used for some things. Reflection on native is quite limited. You really can’t do anything at runtime. No dynamic instance creation, no method query or invoking, etc. Before going too deep I’d say you should review where reflection is being used and figure out if it can be cut (from common and native) or changed in some way that would work in common and native. If reflection is core to how the library works, you’ll have real difficultly porting.
Concurrency is a long topic, but in Jan 2022 I’d just write this for the new concurrency model and forget the strict one. I’m assuming you want a native target here. If not, you can skip that concern. JS obviously needs some concurrency thinking.
That’s it for now. Will follow up with more thoughts if I think of them. Good luck!