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

Bring back Jakarta WebSocket 1.x support #536

Closed
mitasov-ra opened this issue Apr 1, 2021 · 6 comments
Closed

Bring back Jakarta WebSocket 1.x support #536

mitasov-ra opened this issue Apr 1, 2021 · 6 comments
Milestone

Comments

@mitasov-ra
Copy link

mitasov-ra commented Apr 1, 2021

The Problem

After the 0.11.0 update, due to the removal of the org.eclipse.lsp4j.websocket module, lsp4j lost backwards
compatibility with previous versions. My Spring Boot project can use javax.websocket only, so now I can’t use lsp4j.

I’ve tried to figure out why this backwards-incompatible update occurs, but I didn’t find any reasons.

Are there any issues with the javax.websocket, which I overlooked?

My proposal

Return module org.eclipse.lsp4j.websocket, so the current version becomes compatible with the previous again.

Due to Semantic Versioning, you can remove javax.websocket support in 1.x version of lsp4j, but till that moment, it’s better to have backwards-compatibility.

@nixel2007
Copy link
Contributor

Due to Semantic Versioning javax.websocket support can be removed in 1.x version of lsp4j, but till that moment it's better to have backward compatibility.

Due to SemVer maintainers can remove anything they want in 0.x version, cause it is... 0.x :)

What is the problem with migration to javax.websocket in your spring boot project?

@mitasov-ra
Copy link
Author

The problem is that Spring Boot currently does not support Jakarta WebSocket 2.0.

Spring has built-in configuration of WebSockets and migrating to lsp4j 0.11.0 requires writing lots of code for Spring, or just rolling back org.eclipse.lsp4j.websocket.

@jonahgraham
Copy link
Contributor

just rolling back org.eclipse.lsp4j.websocket.

To clarify, this means you can you just stay on 0.10.0 until you upgrade to Jakarta?

@nixel2007
Copy link
Contributor

or just rolling back org.eclipse.lsp4j.websocket.

or requires writing lots of code for lsp4j to support dual-websocket implementation :)

@mitasov-ra
Copy link
Author

@jonahgraham @nixel2007

you can you just stay on 0.10.0

Sure I can. To run a Spring Boot 2.4 + lsp4j 0.11.0 + websocket I need following dependencies:

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-websocket</artifactId>
        </dependency>
        <dependency>
            <groupId>org.eclipse.lsp4j</groupId>
            <artifactId>org.eclipse.lsp4j</artifactId>
            <version>0.11.0</version>
        </dependency>
        <dependency>
            <groupId>org.eclipse.lsp4j</groupId>
            <artifactId>org.eclipse.lsp4j.jsonrpc</artifactId>
            <version>0.11.0</version>
        </dependency>
        <dependency>
            <groupId>org.eclipse.lsp4j</groupId>
            <artifactId>org.eclipse.lsp4j.websocket</artifactId>
            <version>0.10.0</version>
        </dependency>

That's because right now org.eclipse.lsp4j:org.eclipse.lsp4j.websocket:0.10.0 is fully compatible with 0.11.0 version of lsp4j's API. But can you guarantee that kind of compatibility in the future? As I can see, org.eclipse.lsp4j.websocket was completely removed from the project, so I think there's no any guaranties of future compatibilities and I should not rely on using dependencies with different versions.

This means right now I'm stuck on 0.10.0 version of lsp4j, so I won't get any further updates or bugfixes.

you upgrade to Jakarta

This conversation is not about me and my project but about Spring Boot, as that framework does not support Jakarta WebSocket 2 API. And I cannot even google anything about that problem.

In fact, by ending JSR-356 websocket API support you prevent the whole Spring Boot community from using lsp4j.

or requires writing lots of code for lsp4j

Oh come on, there's only 4 classes. What kind of difficulty can be in maintaining 4 more classes that exact same as new ones.

What solution I ended up using

So now, as a temporary solution, I'll just use 0.10.0 lsp4j.websocket module. To prevent that workaround from collapsing in the future builds I'm afraid I should just copy these 4 classes to my project and maintain them myself.

Sure I can make a PR which returns that module in your project, that's not so difficult, but I need your approval, because this is your project, not mine.

@jonahgraham
Copy link
Contributor

The whole point of the websocket bundle was to help prevent having multiple projects having the same copies of those classes. When the jakarta one was contributed we tried to reach out to find out if anyone needed the pre-jakarta. I wish we could have reached you (@mitasov-ra) earlier so that we would have just had both versions for 0.11.0. Thank you for coming to the project to explain the impact.

I see it as a huge positive on the adoption of the project that there is so much demand :-)

Therefore I will restore the pre-jarkata version for 0.12.0 and we will maintain it at least for a while. (A while being until we run into some problem with having it that no one invests time in fixing).

@jonahgraham jonahgraham added this to the v0.12.0 milestone Apr 2, 2021
jonahgraham added a commit that referenced this issue Apr 2, 2021
Partially reverts "Migrate and Rename Websocket bundle to Jakarta #471 (#487)"

This partially reverts commit f44ee42.
jonahgraham added a commit that referenced this issue Apr 2, 2021
jonahgraham added a commit that referenced this issue Apr 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants