Jakarta EE support in Slack Java SDK

I’m trying to migrate Java EE to Jakarta EE for some reason (e.g. native-image, spring 6).

This project has example code for many platform. It’s good for SDK users, but it includes some problems.

Now, some projects depends javax namespace, some other projects depends jakarta namespace. (e.g. Jetty already migrated. Quarkus desided to stay javax)

So, I propose to separate example code from this project before Jakarta EE migration. How do you think about this?

[kuzuha]

@seratch Thanks for more details.

This plan seems reasonable 💯

[seratch]

@kuzuha Thanks for your prompt reply!

I just submitted a pull request resolving the Servlet side issue: https://github.com/slackapi/java-slack-sdk/pull/920 If you have any comments or suggestions, please feel free to leave comments.

Also, I appreciate your time to check the points to be changed for fully supporting Jakarta EE.

I agree. But this project depends 2 javax namespace not only servlet.

Yes, this is a good point (again). Let me clarify my thoughts on the rest of javax.* dependencies.

slack-app-backend: com.slack.api.app_backend.events.servlet

In this package, javax.servlet dependency is optional (= provided scope). Thus, as long as you don’t use the classes in your app, the existence of these classes won’t be a blocker for your Jakarta EE migration. It can be a blocker for native package builds (I haven’t checked it at all) but this project is not planning to support the use case at least in the short term.

In the pull request https://github.com/slackapi/java-slack-sdk/pull/920, I’ve marked these classes deprecated. That being said, we won’t remove them for a while.

bolt-servlet: com.slack.api.bolt.servlet

This module will continue to work only with javax.servlet. This is the reason why I added new sub projects to this SDK in the linked PR. The approach brings duplicated code to this project but it’s much safer and cleaner way to support both.

expressly depending javax.websocket bolt-socket-mode: included but not appear in code slack-api-client: com.slack.api.rtm, com.slack.api.socket-mode.impl

The javax.websocket dependency is optional (provided scope). If you don’t want to have the pair of javax.websocket and its reference implementation tyrus-standalone-client at this moment, you can go with org.java-websocket:Java-WebSocket instead. Refer to https://slack.dev/java-slack-sdk/guides/socket-mode for more details.

Currently, this project supports only tyrus-standalone-client v1.x, which is compatible with javax.websocket. Their 2.x series are compatible only with jakarta.websocket API. In this case, it’s not feasible to support both in a single version. Thus, we are planning to migrate to jakarta.websocket in the next major version. Migrating slack-api-client project to jakarta.* APIs means that we have to drop Java 1.8 support. As we still think there are needs for 1.8 in reality, we are not planning to do this soon. It may take a bit long. See also: https://github.com/slackapi/java-slack-sdk/issues/720

All things considered, my understanding is:

• 1.x
  • add bolt-jakarta-servlet and bolt-jakarta-jetty
• 2.x
  • migrate tyrus-standalone-client to 2.x
  • drop Java 1.8 support for all packages
  • not try to completely remove javax.* references

What do you think about this plan? If you have any other suggestions, letting us know them would be greatly appreciated.