Use JNI implementation of ipcsocket APIs on Arm Macs #6165
Conversation
|
See sbt/ipcsocket#11. I think that it may not be necessary to bump ipcsocket to make sbt work on apple silicon because there is a translation layer in osx: https://www.theverge.com/21304182/apple-arm-mac-rosetta-2-emulation-app-converter-explainer. Nevertheless, it would be nice to run code written for the apple silicon. |
|
@eatkins maybe switch JNA off for not supported platform by default? |
I did the opposite and only turn JNI on if it is known to be supported. That's easier to implement because we know there is a small set of supported JNI platforms. |
There isn't yet a version of the jna available that works with the new apple silicon using arm64. To workaround this, we can use the jni implementation by default on arm64 macs. If the user wants to force the jni implementation for any supported platform, they can opt in with the `sbt.ipcsocket.jni` system property and/or by setting the serverUseJni setting.
| @@ -337,18 +336,24 @@ public void close() { | |||
| static ServerSocket newSocket(final String sock) throws ServerAlreadyBootingException { | |||
| ServerSocket socket = null; | |||
| String name = socketName(sock); | |||
| boolean jni = requiresJNI() || System.getProperty("sbt.ipcsocket.jni", "false").equals("true"); | |||
There was a problem hiding this comment.
I feel that this requiresJNI should be implemented inside ipcsocket.
sbt is client for ipcsocket and ipcsocket may include or may not include some library.
There was a problem hiding this comment.
Maybe, but I don't think it's necessary. The ipcsocket library is agnostic on the implementation and provides constructors that take a useJNI flag so downstream consumers can freely choose their implementation and copy this logic if they feel they need it.
There was a problem hiding this comment.
@eatkins right now it looks a bit strange. Library A doesn't support feature because it has limitation and all this limitation is implementing on client of this library.
From my point of view this check should be implemented inside, and API should have "force JNI" that end user can control.
There was a problem hiding this comment.
I don't know. You may be right but I'm not sure what the best approach is and having requiresJNI in sbt was easier to implement and has no downstream effect. All downstream consumers are likely using the jna implementation because it was a very recent change to support jni at all. You're welcome to open a pr in sbt ipcsocket but I'm not motivated to change this code or add it there.
eed3si9n
changed the title
|
@catap since this was merged, there should be a new nightly published tonight. It would be great if you could try it and report back. The nightlies are found here: https://dl.bintray.com/sbt/maven-snapshots/org/scala-sbt/sbt/ |
|
@eatkins can I just run |
|
You should be able to do |
I think I misread this. Building sbt requires sbt so I think waiting for the nightly is the only option. You could run |
|
@eatkins thanks, I'll test it as soon as it builded a new version. Am I right that it is 1.5? |
|
Yeah, it should be the last version in the list at this url: https://dl.bintray.com/sbt/maven-snapshots/org/scala-sbt/sbt/ |
|
@eatkins let me build it as local snapshot and test it |
|
@eatkins this one is workig fine, but I enjoy the next one here: #6162 (comment) |
There isn't yet a version of the jna available that works with the new
apple silicon using arm64. To workaround this, we can use the jni
implementation by default. If the user wants to force the jna, which
seems unlikely unless there is an unknown bug in the jni implementation,
they can opt in with the
sbt.ipcsocket.jnasystem property and/or bysetting the serverUseJna setting.