Jetbrains + Codespaces. Needs a bit of work…
And I am being generous.
Jetbrains and Github have just announced that you can use any of the Jetbrains IDEs to connect remotely to GitHub Codespaces.
I am a Pro Github subscriber and, as such, I get 90 hours/month of Codespaces for free. Not a bad deal at all. I have never really tried remote development so I thought I would give it a go.
I am a huge IntelliJ fan and I have been a paid subscriber for years. Best $20 I spend every month.
In order to use the Jetbrains-Github combination, you need to download the Jetbrains Gateway and install the GitHub Codespaces provider. This is easy enough. You also need to install the GitHub CLI, which I have never needed in the past. I used Brew and it was simple. Configuration took a few steps and a bit of confusion with authentication, but I got it done.
Then I created a new project with the regular IntelliJ and pushed it to a new GitHub repository. IntelliJ makes this very simple.
Once you have created the repo, I created a workspace in GitHub. The initial configuration is 2 Cores + 4GB RAM but I pushed it to 4 Cores + 8 GB RAM, which seems to be the minimum for IntelliJ.
Jetbrains Gateway detected the Codespace and makes it easy to connect. Just select it and click on Connect.
The first time you do, the Gateway will download the Jetbrains Client, which is the local tool that will be running on your computer. And once the installation completes, the Jetbrains client will open the project. Or, at least, that is the idea…
In my case, as soon as I opened it, I got prompted to download the JDK for the project (GraalVM 17 Community Edition). And then I got an IDE error message, something about a Channel being closed. I dutifully submitted the error message to Jetbrains.
Every time you get that error, you know you are screwed. There is no other option than manually killing Jetbrains Client
I have tried many times. Sometimes this error takes a while to show its ugly face, but it always does. But it is not the only error. Sometimes it is Gradle, sometimes the JDK wouldn’t install, sometimes issues with Threads…
Conclusion
I actually wanted to write an article about creating a native version of a Groovy application with GraalVM. I got it working locally, but then I thought it would be a good idea to run it remotely, as there are things that only work on Linux. Maybe in the future.
For now, while I realised that this integration is “in Beta”, I can only say that, at least for me, things are not looking up. The current implementation is unusable and my experience can only be described as embarrassing, something I didn’t expect from a Jetbrains product.
