Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jakarta EE support in Slack Java SDK #919

Open
kuzuha opened this issue Jan 26, 2022 · 5 comments
Open

Jakarta EE support in Slack Java SDK #919

kuzuha opened this issue Jan 26, 2022 · 5 comments
Labels
enhancement M-T: A feature request for new functionality project:bolt
Milestone

Comments

@kuzuha
Copy link

kuzuha commented Jan 26, 2022

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 seratch added enhancement M-T: A feature request for new functionality project:bolt and removed untriaged labels Jan 27, 2022
@seratch seratch added this to the 1.18.0 milestone Jan 27, 2022
@seratch
Copy link
Member

seratch commented Jan 27, 2022

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
Copy link
Author

kuzuha commented Jan 27, 2022

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 seratch changed the title Proposal: Separate example codes from project. Jakarta EE support in Slack Java SDK Jan 27, 2022
@seratch
Copy link
Member

seratch commented Jan 27, 2022

@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
Copy link
Author

kuzuha commented Jan 27, 2022

@seratch Thanks for more details.

This plan seems reasonable 💯

@filmaj
Copy link
Contributor

filmaj commented Jan 27, 2022

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 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement M-T: A feature request for new functionality project:bolt
Projects
None yet
Development

No branches or pull requests

3 participants