Jakarta EE support in Slack Java SDK

[kuzuha]

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?

[seratch]

Hi @kuzuha, thanks for writing in!

This is a great suggestion.

As stated at #724, we were planning to completely migrate to Jakarta EE in the next major version (v2.x).

However, while reading this issue, I came to think that this SDK should support both javax.servlet and jakarta.servlet as long as both are widely used in the communities.

Taking these into account, I'm leaning towards the following idea. We can add these new one in v1.x series as adding these are not a breaking change.

• Add com.slack.api:bolt-jakarta-servlet (jakarta.servlet 5.0), which is equivalent to com.slack.api:bolt-servlet (javax.servlet 3.1+)
• Add com.slack.api:bolt-jakarta-jetty (jetty 11), which is equivalent to com.slack.api:bolt-jetty (javax.servlet + jetty 9.x)

I'm not sure what Jakarta EE based solutions you use (or you're going to use) but the newly added com.slack.api:bolt-jakarta-servlet package should be useful for your use cases. Am I correct? Also, let me know if you have a different view/idea on this.

[kuzuha]

Thanks for your response.

Supporting both EE is no pain for community.
I agree. But this project depends 2 javax namespace not only servlet.

expressly depending javax.servlet-api

• slack-app-backend
  • com.slack.api.app_backend.events.servlet
• bolt-servlet
  • com.slack.api.bolt.servlet

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

IMO, supporting both EE in one version is hard work.
Better way is keep mantainancing 1.x for a while.

[seratch]

@kuzuha Thanks for your prompt reply!

I just submitted a pull request resolving the Servlet side issue: #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 #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: #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.

[kuzuha]

@seratch Thanks for more details.

This plan seems reasonable 💯

[filmaj]

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

Thanks for clarifying this! Sounds good to me 👍