Guidance in Porting Apache project TinkerPop from Java to Kotlin MultiPlatform.

Making a note to dive in later and comment, but feel free to ping if I haven't by tomorrow....

At this point I am making an assessment. I expect everything I have done thus far will be redone.

I think you are touching an interesting question but according to my experience so far trying to automatically convert such a large, external project is hopeless. You’d also have to partially repeat this for every new version of the library. Here are a few questions: • Does the code you have produced so far actually compile? • Does the code compile in a multi platform setting (obviously not)? • What other Java constructs besides the ones you already mentioned could not be automatically converted to pure Kotlin?

I don't expect fully automatic I want to know how much automation exists. I have been communicating with the project managers and they are open to converting the project from java to kotlin (ongoing repeated conversion is unnecessary).

Ahh, thats a different story then. You didn’t say that you have the option to do this conversion permanently. Using the translator in IntelliJ is then a good starting point but after the initial conversion you will still need a lot of hand tweaking. One issue you haven’t mentioned yet is whether you want to stay backward compatible with Java.

I’ve ported some fairly manageable Java code, but my big attempt was porting Java 8's datetime support, before kotlinx.datetime was announced. I did get it to “work”, but large Java libraries can get quite complex depending on what they’re doing. Thoughts in no real order. Confirming comments already mentioned: • For sure there’s a lot of manual editing after the Java->Kotlin converter, but it seems like you’re aware of that 🙂 • After the conversion is “complete”, you’ll still have a very “Java” smell, but I wouldn’t focus on that till later. If this needs to be compatible with the original, then you have constraints here anyway. • Replacing the existing Java core with Kotlin adds a level of complexity here. If it was just Kotlin/JVM it would be simpler, multiplatform will add issues. The difficult part for common code is generally libraries that aren’t available from common. If they are system libraries, you may need to restrict targets and make sure there are equivalents on the other target platforms (datetime uses a whole lot of localization and time zone data. It got complex). If they’re not system libraries, but open source, you may need to either port them, find equivalents, or drop functionality available in common code. I’ve never use this library so I have no idea on the feasibility of that. It looks like the test library is robust which is good, but tests generally have more libraries that aren’t available in common Kotlin. Taking a quick look, it seems like

core

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!