This will be a “thinking out loud” thread, in which I’d like to collect some input from folks, coming from the Swift side to the swift/java interoperability.
As you may know, the swift-java command line tool offers a number of sub-commands, which implement the various steps in using Java or Swift code from the other language.
Historically, we started out calling one of those tools jextract because serves the exact same purpose (and shares general approach), with OpenJDK’s jextract tool. Originally we called it jextract-swift, then we rolled all commands under the swift-java <subcommand> command (as presented on WWDC), with:
swift-java wrap-java - wrapping java code with Swift “wrappers” (Java is the input, Swift types are the output)
swift-java jextract - wrapping Swift code, “extracting Java wrappers” from the input Swift (Swift is the input, Java is the output).
and the other commands, like configure (configure wrap-java mappings) and resolve (resolve dependencies).
Recently we’ve been wondering if the jextract name which is very clear to the java audience because they may have already heard about “jextract for C”, and this is just “jextract, but for Swift”, may be creating difficulty in understanding which tool does what.
One of the names is “wrap java” and the other one is “extract java (wrappers)”.
I am wondering if we should flip the name and offer swift-java wrap-swift, and perhaps just prominently document “oh, if you know jextract, this is exactly the same”.
I am also wondering if it would be beneficial or more confusing to keep aliasingswift-java jextract to wrap-java.
Curious on people’s opinions here, although the audience here probably will be a bit “Swift biased”, I find myself sympathetic to the wrap-java / wrap-swift names anyway, since they’re more symmetrical. Open to ideas, e.g. what would people think about the alias?
I like the symmetric wrap-java / wrap-swift options. The verb-object structure makes it very clear what is happening.
I don't see much benefit to the alias, and you would need to keep supporting it forever once it becomes widely used in build scripts and other tooling.
I also prefer the symmetric relationship between `wrap-java` and `wrap-swift`, which would also solve the confusion for “new” people that are not Java-first, who have no idea what `jextract` means. As you mention, I think we can document our way out of saying “oh yeah, wrap-swift is like JExtract for Swift”
Yeah, seems that’s a clear win. I’ll be applying this change once branches are unlocked after the break.
I was also wondering if people like the “wrap-” but honestly it seems so descriptive and kind of selfexplanatory that I think that’ll be a win, even though it is two words. I don’t think doing wrap java / wrap swift with a space would be much better than the - but would be open to opinions on this as well. Required “mode flags” I’m less excited about, this is a required thing after all, not an optional mode flag.
We did release a WWDC video and some talks explaining “jextract” but that’s not really a show stopper… I will however keep a “deprecated command” that at least prints some “was renamed to …” which should be helpful for anyone coming from the WWDC talk.
It sounds a bit like Dr. Seuss with the swift-java command, but I prefer that to clarify the wrapping direction and to reinforce the meaning of wrap in this context.
As for other concepts to replace “wrap {code}” (or “extract {interface}”), “adapt” seems to be the concept (adapt-swift-for-java), if you don’t want people thinking in terms of (wrap/extract) implementation.
While clearly not being part of the “Java audience”, I would vote for wrap-swift for the clarity and symmetry it provides along with wrap-java.
I agree with @madsodgaard that we can document that swift-tool wrap-swift provides similar functionality with JExtract, but the jextract naming itself doesn’t seem so meaningful unless it provides identical interface with the original JExtract (if better, provides a drop-in replacement of it), which might be too early to be discussed on.