Migrate exposed-core to multiplatform project structure

[JGuck]

This pull request updates the exposed-core module to use Kotlin Multiplatform, reorganizing dependencies and build configuration to support multiple targets. The most significant changes are the switch from JVM-only to multiplatform, and the restructuring of source sets and dependencies.

Summary of the change: Provide a concise summary of this PR. Describe the changes made in a single sentence or short paragraph.

Detailed description:

To start expose as a Kotlin multiplatform project, we have to do a basic configuration. However, the whole task of migrating the core might be to big for a single PR. That's why I placed the main part of the code in jvmMain. This should be an equivalent of the previous setup. Now we can start to gradually move more and more code into the common section. This would also reduce the risk of a big bang migration.

Changed the Gradle plugin from kotlin("jvm") to kotlin("multiplatform") in exposed-core/build.gradle.kts, enabling multiplatform support.

Added the kotlin block with jvm target configuration, applied the default hierarchy template, and set up commonMain and jvmMain source sets with appropriate dependencies. This moves kotlin("reflect"), libs.kotlinx.jvm.datetime, and libs.slf4j to the jvmMain source set, while kotlin("stdlib") and libs.kotlinx.coroutines are in commonMain. Refactored exposed-core to use Kotlin Multiplatform, introducing commonMain and jvmMain source sets. Updated build scripts to apply the multiplatform plugin and moved source files accordingly to support multiplatform development. The global application of the kotlin-jvm plugin was removed to avoid conflicts.

---

Type of Change

Please mark the relevant options with an "X":

• Bug fix
• New feature
• Documentation update

Updates/remove existing public API methods:

• Is breaking change

Affected databases:

• MariaDB
• Mysql5
• Mysql8
• Oracle
• Postgres
• SqlServer
• H2
• SQLite

Checklist

• Unit tests are in place
• The build is green (including the Detekt check)
• All public methods affected by my PR has up to date API docs
• Documentation for my change is up to date

---

Related Issues

#635

[BierDav]

I'm excited for this to get merged. I want to build a cross platform sync library on top of exposed, but the lack of KMM support is currently my biggest hurdle.

[nikolamin]

Can we have some attention on this PR? @bog-walk @e5l

[nikolamin]

I'm excited for this to get merged. I want to build a cross platform sync library on top of exposed, but the lack of KMM support is currently my biggest hurdle.

@BierDav I am in the same situation, maybe we are doing the same thing, should we join the forces? :)

[BierDav]

@nikolamin yeah, definitely! Feel free to contact me on discord. It's on my profile ;)

[nathanfallet]

This would be the first part of having kmp support. When this will get merged we'll be able to work on the other modules! (really exited to be able to use it on mobile as well as with kotlin native on linux on server side)

One thing to add: seeing you have merge conflicts, maybe try to reach the team on slack so you ensure it's good, and then apply again the changes (gradle files + folder rename) from the current main directly; will be easier than solving merge conflicts.

[BierDav]

I don't think he was really working on multiplatform support though. All sources just moved to jvmMain. I already did a real multiplatform conversation. Checkout my fork https://github.com/BierDav/Exposed (it indeed works, because i even published it once to ghcr)

The core challenge was that some java Types like decimal and UUID are buried very deep in the code as well as the usage of the Java reflection Class in the API between driver and core. This makes it sometimes impossible to keep binary compatibility. But i tried my best 🥹

@maintainers if you want a PR tell me, currently there is a lot of bloat changes in my fork too, but if it won't get merged anyway it's not worth the hussle for me.

[bog-walk]

Hi all and thank you @JGuck for taking the time to put together this PR & prompt this discussion.
Apologies in advance for the long read, but our post-v1 roadmap won't be published until after the release, so hopefully I can clarify the current state of this feature request, at least in the interim.

KMP support is naturally on our radar but it has not been a central goal of 1.0.0. The KMP feature is going to be a massive multi-step endeavour and we welcome the assistance of contributors, so it will very much need to be a concerted effort. The first step of that is to actually decide on the ultimate expectations of the feature and put together a plan.

That's where we're at right now, the requirements gathering phase. I've updated the details on the parent issue EXPOSED-767 so you can see everything we would need to know and decide on before commencing properly.

I can say right now that there are 3 major evaluations we would need to make before any promises or outlines are set:

1. With Exposed on the JVM, our relationship with JDBC drivers is very clear. There is a standardisation that we can conform to and anticipate, as well as multiple open source options we can use for testing. For multiplatform, we would need to decide on what that driver relationship would be exactly.
   Hypothetically speaking, let's assume phase 1 involves adding Android + Native targets using SQLite only:

   • Should Exposed provide a similar scenario to SQLDelight, by providing its own platform-specific SQLite driver implementations?
   • Should Exposed also offer the ability to use an unknown driver with a native target for example and, if so, is successful integration feasible without a unified API?
   • Does point 2 mean Exposed should provide its own driver-level API to facilitate integration with any future additions to the native ecosystem?
     We could assume that the answer to those 2 last questions could be more of a phase 2/3 concern, but we would still prefer to have a vague idea sooner than later.

2. It would be preferable to get a preliminary breakdown of all the required platform-specific expect/actual implementations. I've already logged the results of a first pass in EXPOSED-767, with all the usages of java.* objects to cover. Some are straightforward, some require a bit more research, some we were already considering replacing entirely. We need to have plans in place for all those subtasks to ensure that they can be enacted without breaking changes and, if not, figure out if a redesign/refactor of the blocking usages is even feasible.

3. And that brings us to DAO. There are a number of design aspects in exposed-dao that have the potential to be troublesome. To name one, there is an extremely heavy reliance on reflection throughout the entire module. We would need to determine how many of the reflection features used are not supported by native's more limited set.
   Part of the post-v1 roadmap will include a much needed redesign of the DAO approach (EXPOSED-778), and it's for that reason, alongside many others (EXPOSED-819), that R2DBC support was rolled out without DAO integration.
   For KMP as well, these much-needed changes to the DAO design would need to be aligned with any potential multiplatform requirements. So, it makes more sense for these 3 tasks (DAO redesign, DAO + R2DBC, DAO + KMP) to be worked on in parallel.

👋 If you have any thoughts, suggestions, or answers to our questions, please feel free to add them to the parent ticket EXPOSED-767, or here if you wish. We welcome any insight into what you would like the finalized feature to look like or how you would preferably want to use it for your specific use cases.

Regarding this PR specifically, I hope you can understand why it won't foreseeably be merged directly to main at this exact time. It can be left open, to keep the discussion going, but it will most likely become obsolete very quickly unless it is continuously rebased & maintained while planning is undergoing (until Q1 2026 at least).
Once we have more information and put a plan together with a clear direction, the parent ticket will be updated with new tasks that will be up for grabs. I can leave an update here as well for any interested contributors. We can then consider how best to approach this efficiently as a joint effort and proceed with the feature branch.

[JGuck]

Hi @bog-walk, thank you for the detailed explanation and for outlining the current state of the roadmap.

I fully understand that proper KMP support is a large, multi-stage effort and that the project first needs clear requirements and a long-term plan before major structural changes can be merged. My intention with this PR was not to bypass that process but to take the smallest possible first step to make the transition more approachable for contributors.

The motivation behind this PR is simply that exposed-core is currently JVM-only on a structural level, which makes it difficult for the community to progressively move shared logic into commonMain. Even if full multiplatform support is still far down the roadmap, preparing the module structure early enables contributors to gradually migrate code — for example utilities, the UUID implementation, or other JVM-agnostic pieces — without requiring a massive refactor all at once.

So the goal of this PR is intentionally minimal:

• Introduce a multiplatform module structure for exposed-core.
• Only the JVM target contains actual code for now.
• No functional changes or new dependencies.
• Existing behaviour remains completely unchanged.
• Risk is minimal and validated by the test suite.

This approach ensures stability while opening the door to incremental community contributions.

Regarding some of the points you raised:

1. Driver relationship
   For my own use cases, I would love to have an exposed-sqlite-driver package that abstracts away the need to include different SQLite driver dependencies per platform. A unified Exposed-maintained SQLite driver would simplify multiplatform development significantly.

2. Sequencing concerns
   I’ve noticed many of the same challenges, which is why I strongly believe the small-step approach is beneficial. It doesn’t solve the larger architectural questions, but it lays the groundwork so the community can begin contributing to pieces that are already platform-agnostic.

3. Reflection / DAO
   I’ve successfully replaced some limited reflection features with kotlinx.serialization in other projects, but I’m not sure how far that would go for Exposed’s DAO use case. DAO relies heavily on reflection, so this area will likely still require significant redesign, as you mentioned.

I absolutely understand that merging this PR right now may not align with the timing of your post-v1 planning. If helpful, I can keep the PR rebased and maintained while discussions continue.

Thank you again for the openness, clarity, and for sharing the roadmap insights. I’m happy to contribute more once the KMP direction becomes clearer!

[nathanfallet]

I agree on the idea of preparing the module by switching to kmp gradle module instead of jvm gradle module, even if only the jvm target is enabled now. It prepares the project and will simplify upcoming contributions.

Note about DAO: some projects use SQL DSL approach and would already benefit of the Multiplatform support even before DAO is supported.

[JGuck]

Hi @bog-walk,
are there any other plans for doing multiplatform support right now? I can redo the migration to multiplatform for the core module if it has a chance to be merged.