asdf-java incompatibilities about mise

[jdx]

oh, reading the code, it actually is importing some asdf source code. That obviously isn't there since asdf isn't installed. If you installed asdf (just didn't add it to your shell rc) that should fix it. It has to be in that directory though, so run:

git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.11.1

We may need a longer term solution here though, especially if this is something happening in other plugins.

[blopker]

Cool, yeah, not a blocker at all, just thought I'd surface it in case another plugin does break. I think the Java plugin (and to an extent Java) is just weird. I'd say it should default to openjdk, but I'm sure people would argue otherwise.

I'm never installing asdf again! 😛

[blopker]

As far as I know, JAVA_HOME is not for the executable, but largely used by other tooling to find the Java SDK. For example, IDEs will use it to find the right source files to import. Although since IDEs usually configure that themselves I've never had an issue with asdf not setting it properly.

[jdx]

I can dig into this more tomorrow. It's likely just that I'm missing some environment variable that asdf sets.

Also, rtx install java does not work

This is actually an issue with the plugin (arguably). It doesn't output any "normal" versions that start with a number. It's an issue in asdf as well:

❯ asdf latest java
No compatible versions available (java [0-9])

I'm not sure what should happen here but it likely needs to be fixed in the java plugin. One thought I had is maybe it should use the bin/latest-stable script. Currently rtx doesn't use that since I couldn't find a plugin that used it as a reference. Java doesn't have it either so we'd need to first put one in the plugin for that to be a solution.

[jdx]

I explain this in the readme but the java plugin is actually probably the best suited to rtx over asdf (barring this hiccup). You don't need to setup the special asdf-java shell extension to get JAVA_HOME to work, it'll just set JAVA_HOME automatically the way you expect.

[jdx]

though, that's a theory, I'm not a java dev so maybe you can tell me how well it actually works :)

[jdx]

I did test java somewhat and it seems to work reasonably well. It does throw this error but it isn't important. There is also the matter of there not being a default version.

I think barring some rough solutions these both rely on changes within the plugin, or perhaps forking the java plugin into an RTX variant so that's the one that gets picked up when you run rtx install java

That said, there are a ton of other issues people have raised that I feel are more important so this one has dropped near the bottom of my queue. I'd be happy to consider any solutions here, or if the problems are bigger than I see let me know.

I'll keep this open of course, I just figured I'd let you know I don't think it's super likely I'll get around to this in the near term.

[blopker]

Thanks for the follow up! I'm not blocked or really effected by this. Thanks for making sure it's not a big issue.

I'm good with this outcome, I have know problem if you want to close it.

[roele]

I'm not sure what should happen here but it likely needs to be fixed in the java plugin. One thought I had is maybe it should use the bin/latest-stable script. Currently rtx doesn't use that since I couldn't find a plugin that used it as a reference. Java doesn't have it either so we'd need to first put one in the plugin for that to be a solution.

The problem with asdf is that it only has a notion of version for a particular plugin. Several plugins are meanwhile provided in various distributions/variants (e.g. Java: Azul, OpenJDK, ... or Python: Anaconda, PyPy, ...) So it rather should support something like plugin@distribution:version. This leads to countless issues with commands like latests etc.

[jdx]

I'm going to close as it seems this is resolved. The problem we talked about is really in asdf-java if it's anywhere.