feat: Add Scala Native support infrastructure

[rishi-jat]

Progress: 40% Complete (Foundation)

This PR adds the infrastructure for Scala Native support:

• Platform abstraction layer (HttpBackend)
• JVM backend refactored (JvmHttpBackend)
• Build system configured for cross-compilation
• Placeholder Native backend

Remaining Work (60%):

• ⏳ Implement NativeHttpBackend (waiting on HttpClient or using libcurl)
• ⏳ Add tests for Scala Native
• ⏳ Verify all features work on both platforms

Related:

Fixes #156

• Depends on: Support for java.net.http.HttpClient scala-native/scala-native#4104 (HttpClient)

[rishi-jat]

Hi @lihaoyi @LeeTibbert @lqhuang,

Quick update on the Scala Native work:

I've finished the foundation (~40%) - all the infrastructure is in place:
https://github.com/rishi-jat/requests-scala/tree/feat/scala-native-foundation

The remaining 60% (actual Native backend) is waiting on @lqhuang's HttpClient work.

Rather than sit idle, I'm jumping over to help fix the HttpCookie PR in scala-native (#3927) since it's been stalled since May and we'll need it anyway.

Plan:

1. Fix HttpCookie → get it merged ✅
2. Wait for HttpClient from @lqhuang ⏳
3. Finish NativeHttpBackend → complete the bounty 🎯

Following your HttpClient approach. Will keep you posted!

Thanks!

[LeeTibbert]

Sounds like a good plan. As always, I am on hand to help with the Scala Native parts.

1. Small typo above: s/Fixses/Fixes/

2. SN #3927 is a PR. I suggest that either you or I add a reply which states
   that you would like to work on this issue and have permission from it author
   to use the code.

   1. It is your call if you want to download the files and start your own PR, probably
      Draft at first to get you feet wet and teach me about the problem domain. I'd
      suggest putting a one or two line header at the top of each file you copy stating
      something like "/* Based on earlier work by D??? in PR #3927 and used by permission */"
      If you have contact with D???, it would be good for the Intellectual Property audit trail
      for them to put a brief reply in the Issue. This is a 'nice to have' and courtesy to the
      original author. I am not a lawyer but I believe the SN Contributor's Agreement signed
      electronically before that PR would cover the suggested usage here.

      A Draft PR would get you through the "Contributor's Agreement" before you invest
      too much time. You should read it and see if you agree or not. It is legalese and
      dense but consistent with the Apache license .

   When I signed it awhile back, I saw no mention of "first born children".
   os-lib probably has a similar concept of a "Contributor's Agreement".

   2. An alternative is that, I think, GitHub has a concept of "assume" a PR.
      I have never used it. You could check the GitHub documentation to
      see what is involved. Then you could at-Wojciech (probably in the 3927)
      asking that with the permission of D???, you would like to "assume" the
      PR. Wojciech may or may not think that an economic move.

Good hunting.

[rishi-jat]

Hi @LeeTibbert,

I’ve decided to implement the HttpCookie support from scratch with a completely new codebase instead of using PR #3927.
This will ensure full ownership, clean design, and alignment with the Scala Native backend.
I’ll start a draft PR soon and keep you updated on the progress.

Thanks,
@rishi-jat

[LeeTibbert]

| I’ve decided to implement the HttpCookie support from scratch

Sounds as a wise move.

In my "waiting for CI runs to finish" time, I'll refresh my memory of 'HttpCookie' and if
there are existing implementations in other languages, with compatible licenses,
which might be economically ported. I have weak memory of that class & related as
"bigger than a breadbox".

Nice to have you working on it. I do not mean to slow you down by my being
highly time-shared.

[lqhuang]

Hi @rishi-jat,

Thank you for your contributions and for your interest in the project! I appreciate you taking the time to submit a pull request.

I'm reviewing the current PR, and I'm trying to understand the purpose of the changes. Given that we're focused on shimming required modules/classes in Java for Scala Native, the expectation was that changes to requests-scala would be minimal. Could you elaborate on the necessity for these changes?

Additionally, current codes and the description give the impression of being AI-generated. If I'm mistaken, I apologize in advance, and I'd appreciate clarification.

While I'm open to code created with the assistance of LLMs, it's important that the submitter takes full ownership of the code and is responsible for ensuring its quality and integration.

I want to share a statement here I see elsewhere,

"This PR was primarily authored with GPT-5-Codex and hand-reviewed by me. I'm responsible for every change that lands here."

Could you explain the rationale behind why we need to split to different backend in this context? Understanding the motivation behind this approach will help me better assess the PR.

Still appreciate and welcome for your contribution!

Regards

[rishi-jat]

Hi @lihaoyi,

Thanks for reviewing the PR and the thoughtful feedback!

Why the backend split is necessary:

The current Requester.scala directly imports java.net.http.HttpClient - these classes don't exist in Scala Native. Without this abstraction, the code simply won't compile for Native targets. It's not just about runtime behavior, it fails at compile time.

Rationale for this approach:

I considered conditional compilation, but that would scatter #if JVM blocks throughout the codebase. The backend abstraction keeps platform-specific code isolated while maintaining a clean public API.

What this achieves:

Zero breaking changes for existing JVM users
Enables cross-compilation to Scala Native
Clean separation of concerns
Future-proof for other HTTP implementations
The JVM backend is just the existing HttpClient code extracted into its own class. The Native backend is a placeholder until the upstream dependencies (HttpClient/HttpCookie) become available in Scala Native.

Alternative approaches:

If you prefer a different strategy, I'm open to discussion. The core constraint is that java.net.http.* imports need to be isolated from shared code to enable Native compilation.

Looking forward to your thoughts on the best path forward!

Best,
Rishi

[lqhuang]

As you said

until the upstream dependencies (HttpClient/HttpCookie) become available in Scala Native.

then, it will be a “free lunch” benefit. We can just declare these upstream projects as deps and compile under Scala Native condition.

Yeah, that's all.

How do you think about it?

[rishi-jat]

Exactly! That's precisely why I structured it this way.

The backend abstraction enables that "free lunch" - once your HttpClient work and HttpCookie are available, we just:

Update NativeHttpBackend to use the new dependencies
Remove the NotImplementedError
Add the deps to the Native module
Without this abstraction layer, we'd still need to untangle the current java.net.http imports from the core logic.

Looking forward to your HttpClient progress! The foundation is ready to plug it in.

[lqhuang]

It's fine to just keep these codes in your forked repo for dev purpose. When everything ready, these codes will be clean up in the future. They may not be suitable for being merged into the main line now.

Of course, it's just my personal thought, you could ask Haoyi for more.

[lihaoyi]

I think the ideal here would be to implement the upstream classes in the java standard library. Requests-Scala is just a thin wrapper over java.net.http, so if we implement the relevant parts of java.net.http in Scala-Native then Requests-Scala would not need to be modified at all.

Some minimal modifications are fine, in the interests of getting something working, but the goal should be to minimize how much Requests-Scala code needs to be modified

[LeeTibbert]

@lqhuang Is the working plan still to implement java.net.http.HttpClient & kin as a standalone
project, similar to the Cquiroz scala-java-time package at least for the first Evolution?
That probably makes turn around time easier.

You could probably delay WebSocket and associated Tests.

JDK 26 is only a few months out. I believe that it introduces some changes. It makes some
what read like pretty complicated change about falling back from a new protocol (Http3?).
You may want to think of having those changes throw "UnsupportedOperationException"
to buy you/us some time to get the basics working.

Of course, you have been working on this for awhile and may already have a plan or the
sketch of one in your mind or Repository.

I say all of this not to jump into the middle (or end) of people's existing work throw but
because I am trying to triage my time allocations over the next six or so months and
would like to help this effort, at lest in the SN critical parts.

[lqhuang]

@LeeTibbert

Is the working plan still to implement java.net.http.HttpClient & kin as a standalone
project, similar to the Cquiroz scala-java-time package, at least for the first Evolution?
That probably makes turn around time easier.

Yeah. Exactly the same with what you describe. That's why I think this PR is probably not necessary.

You could probably delay WebSocket and associated Tests.

LOL, yes, I also think so, you could check my project index lqhuang/scala-native-http, my roadmap matches your thoughts.

HTTP3 will be a good idea, it's also true that it's not first priority now.

Good news is I'm working on SSLContext (scala-native-crypto #25) with lolgab, we have added JDK 25 into CI matrix.

Let's try to release something to ensure basic features. I know we're looking forward to that goal. 😋

It's glad to hear your feedback. Thanks!