To use the official one you should follow the instructions from here. There is one AUR package available called sdkman but its seems to be an unofficial sdkman client. That is my SDKMAN setup on arch linux to deal with it. And if the new version of the library is not foreseen to be deployed in production at this time you're shit out of luck.- java, sdkman, archlinux, vscode-java - 2 min readįor java development it is sometimes necessary to switch between different jdk versions.
Arch linux java update#
The comments stating "things don't randomly break" are a little bit unfair, your system will not break, but your developments relying on a specific version of a specific library might break until you update them (like the other arch packages which were bundled together in your update). So, yes arch for your dev environment (IDE, debugging, etc.) is a godsend, but unless you are using pacman to deploy on prod you should be very explicit about the versions of whatever will be used "in prod" and "on the path to prod" and my personal opinion is that this is more easily done manually (or through another mean, like docker and all) than through pacman.
Containers solve this (to some extent, I can imagine docker updates having the ability to break things if you are working at the edge), but then the question is 'should I use arch as a base system in my containers'. You need to track very specific versions of those, discrepancies will break your code first on your dev env as the library gets updated by arch and then in production as your 'updated' code gets deployed there but the library lifecycle on the production server is not the same as the one on your machine. I wouldn't use pacman to manage any of the dependency that would then be replicated on another system: your JVM version should be the one you will use in production, your maven version should be the one your CICD pipeline will use. So, your experience in having only had one issue with a broken system is nice, but it's not the complete picture. The difference here is that we have experience in fixing these unknown, unidentified problems whereas the OP seemingly does not. At first I wasn't aware that wxgtk was the problem when I first encountered it, so to me at that time, the problem seemed random. A simple package name change, like in the case of wxgtk, can cause breakages in other areas of the system. This is a problem no matter which distro you're using. It is a known fact that updates can cause problems in other applications, which will break the system. The OP wants to know if the operating system will be stable.
If the OP had simply said "I don't want something that will break" then we wouldn't be a rather useless debate over irrelevant semantics.
Arch linux java manual#
There are situations that are plug and play pretty much everywhere these days that still require manual setup and config with Arch. Same for running a USB-C to HDMI second monitor.
Arch linux java install#
Want to hook up a printer? K, remember the old days when you had to manually install and configure CUPS and all that? Well that's still a reality with Arch. The only caveat is that it will take you longer to do basic things.
Arch linux java software#
Between official packages Snap, and Aur you have access to almost every bit of software available.
I don't think there's a better documented distro out there. Occasionally another package will contain breaking changes which bleeds into Arch, like the GRUB issue awhile ago, As soon as the problem was identified the Arch wiki was updated to reflect the issue and solution. So far Arch and Pop are the only two distros I haven't completely broken unintentionally.
0 kommentar(er)
