Interoperability with Java Module System

[scordio]

I am developing a Java 17 application based on the Java Module System and I would like to use some of your libraries, specifically:

• notion-sdk-jvm-core
• notion-sdk-jvm-httpclient
• notion-sdk-jvm-slf4j2

However, I've noticed such libraries have split packages, e.g.:

• The core module declares the notion.api.v1.http and notion.api.v1.logging packages
• The http module declares the notion.api.v1.http package
• The slf4j2 module declares the notion.api.v1.logging package

Unfortunately, this is forbidden by the module system and won't work at runtime.

Would you consider changing packages for the non-core modules? I understand this would be a breaking change for the users.

In addition, it would be nice to include a module descriptor in the libraries so that they are detected as named modules. I don't have direct experience with Kotlin in doing so but am happy to help figure out the way to go.

Also, it would be useful to include a module descriptor in your libraries so they are detected as named modules. I don't have direct experience with Kotlin doing this, but I'm happy to help figure out the way to go. As far as I can see, Kotlin introduced module system support in version 1.4-M3 (KT-21266), so the ecosystem is probably already mature.

[seratch]

Hi @scordio, thanks for taking the time to report this!

I've never built any apps with Java Module system yet, so I'd like to have your inputs more:

• This library does support Android runtime too. Doesn't supporting the Java Module system affect Android dev experience at all?
• Is notion.api.v1.http.okhttp4 (meaning sub package) in a different library disallowed too?
• If the answer to the above is yes, does naming like notion.api.v1.ext.okhttp4 (javahttp, okhttp5, etc.) make sense to you?

If everything is fine on all of the above, I am fine to make some changes in the next major version. As you said, while it's a breaking change, I think the transition is relatively simple. Therefore, I believe that the existing users can accept that.

In addition, it would be nice to include a module descriptor in the libraries so that they are detected as named modules. I don't have direct experience with Kotlin in doing so but am happy to help figure out the way to go.

Thanks a lot for saying this! Not only from the knowledge aspect but also the time I can use for this project recently, your help would be greatly appreciated 👍

[scordio]

• This library does support Android runtime too. Doesn't supporting the Java Module system affect Android dev experience at all?

I don't have much experience with Android but I believe the module descriptor wouldn't interfere as I consider the module system an opt-in feature. If the consuming application does not declare a module descriptor but the library does, the library will be anyway placed into the classpath of the consuming application without additional restrictions, so there shouldn't be any behavioral change.

• Is notion.api.v1.http.okhttp4 (meaning sub package) in a different library disallowed too?

No, I believe this should work properly because technically there is no sub-package concept, the hierarchical view is just for convenience but they are separate entities.

Let me have a deeper look at all these points. I believe the best would be to have integration tests in the project, in the form of additional Maven modules. I'll prepare a draft PR in the upcoming days with the case I'd like to cover and we can also brainstorm how to properly cover the Android use case to make sure nothing is broken.

[scordio]

I got carried away by other priorities and haven't had a chance to focus on this yet, but I'm still interested in this 🙂 My offer still stands and I'll try to spend some time on it as soon as I can!