Support Scala Native

[lolgab]

Blocked by:

• FileInputStream#getChannel java.io.FileInputStream#getChannel is not implemented scala-native/scala-native#2303
• Claimant on Scala Native Support Scala Native claimant#132

[rossabaker]

Thanks for this.

I'm not sure whether any of the other Jawn maintainers use Scala Native, and I'm a little worried about adding build complexity in a key project. At the same time, without doing so, we can't begin to support downstream projects in Scala Native.

It doesn't complicate the code. I'm willing to give it a shot, as long as we get help if it breaks or can throw it overboard if it blocks the JVM use case.

[lolgab]

@rossabaker Thank you!
I added Scala Native because I was trying to port Circe which (uses it on the JVM) is central to any typelevel project and key to Scala Native usefulness/adoption.
I'm happy to help in case this addition creates problems in the future.

[rossabaker]

Sounds good to me. Let's try it.

Looks like we broke the Scala 3 build somehow. I'm confused, because it says it's the JVM project, but I see native things happening.

[lolgab]

Something was going on with making available the dummy Claim.scala implementation for dotty.
I moved the code to src/test/scala-3 which is automatically detected by Sbt, so it works with no special treatment.

[lolgab]

I made a silly mistake which made all the tests be skipped on Scala Native. The scalacheck dependency needs the %%% operator to be passed as a Scala Native dependency.
This reminded me that I need typelevel/claimant#132 and even after that there is some missing java.file api that needs to be added upstream on Scala Native.
I'm changing this PR to draft until I get all the requirements done.
I'll ask another review when I'm done, sorry for wasting your time.

[rossabaker]

No worries. I approved the CI run, to see if it uncovers any more surprises.

[larsrh]

Claimant 0.2.0 on its way to Maven Central.

[larsrh]

After giving it a bit of thought I'm going to deprecate Claimant (typelevel/claimant#110). We should remove the dependency here.

[rossabaker]

Would we then port this to expecty, or just drop the fancy assertions?

[larsrh]

I vote drop fancy assertions. Jawn is stable; for all I care the tests just say "yes" or "no" 😉

[larsrh]

#348 is merged so we don't need the claimant stuff anymore

[lolgab]

I rebased the branch on top of the current mainbranch.
About platform-specific files, I copy-pasted the Scala.js files. So I don't even depend on the missing Channel not implemented function in Scala Native 0.4.0.

I can, alternatively, put them in a js-native source folder if you don't like the copy.

Let me know.

[armanbilge]

How does this interact with the ++3.0.0 used in CI?

[lolgab]

It seems to me that runs only the tests in JVM and JS projects since the native project doesn't have that version.
If you run:

> ++3.0.0
> astNative/test

It runs the 2.12 tests instead.

[armanbilge]

Hmm. It's probably fine for tests, but what happens with +publish. Does it try to publish 2.12 artifacts for native twice?

[armanbilge]

I tried +publishLocal and it seems fine actually. Go figure?

[lolgab]

Yeah, I wasn't able to reproduce the problems that a platform with less scala versions create..

[lolgab]

@rossabaker Can you approve the CI run again?

[lolgab]

@rossabaker Thanks for the approval!
I forgot to disable MiMa for Scala Native as it is in Scala.js. Now I added the setting to jawnJSNativeSettings.
Hopefully, this will be the time when it passes 🤞

Sorry to disturb you again :/

[rossabaker]

No worries. Bummer we're on different time zones. 😄

[lolgab]

CI is green now 🥳

[lolgab]

@rossabaker Can this be merged now? :)

[armanbilge]

@lolgab your goal is to use this to cross circe for native, correct? Or do you see stand-alone uses?

[lolgab]

@armanbilge
It is for Circe, yes, why?

[armanbilge]

Do you know if Circe is open to a native cross rn? I guess it would depend on the build complexity, but lately seems to be trying to reduce the crosses: circe/circe#1818

It should be possible to cross Circe core without this, I think, to test the waters there maybe :)

[lolgab]

@armanbilge You're right, I need to ask there first.
About porting Circe without jawn I'm not sure. The JS version uses native javascript parsing capabilities while the JVM version uses jawn, from what I saw.

[armanbilge]

The circe-core module just defines Json, Encoder, Decoder, etc. but doesn't do any parsing, the circe-parser module is the one you are thinking of I think.

We all love Jawn but it's wholly possible that plugging circe-core with some non-Scala native lib for JSON parsing would be much more performant 😆

[armanbilge]

Btw, I'm generally for this, esp. since Jawn is needed for http4s-native (watch out Ross!) regardless of what circe uses for native parsing ... but we are still quite a ways off from that.

[rossabaker]

I don't know anything about scala-native, but it looks like this passes without unduly complicating the other builds. What is the compatibility story? When scala-native-0.5 is released, will another jawn release be required? Would it be okay to handle that in a minor jawn bump?

Like I said in the spring, I want to support this without putting the predominant platform at any extra risk, but it looks like you've accomplished it!

[armanbilge]

When scala-native-0.5 is released, will another jawn release be required? Would it be okay to handle that in a minor jawn bump?

The artifact suffix will change (see how cats-native is published: https://repo1.maven.org/maven2/org/typelevel/cats-core_native0.4_2.12/) so wouldn't need anything special with jawn versioning: introduce a new cross-build for it (and most likely drop the old one).

[rossabaker]

Okay, we have two people on this thread who know what they're doing. We'll keep it if you can keep it running or recruit more people who can. 😄