First, note that I also pointed to Java spending years developing a reputation as one of the only things you couldn't install through the package manager for legal reasons.
People who don't care about Stallman's zealotry do still care about that and it presented a similar lasting problem to Java's Linux uptake as the problem D had more broadly with two competing and mutually incompatible standard libraries (Phobos and Tango) in the early years.
As for the GUIs, I listed three different ways unique to Java that Java GUIs were subpar on Linux:
1. Needing weird workarounds for applications to not display blank grey windows on non-reparenting window managers. (Basically, if the WM was something like a tiling WM that didn't reparent it from the root window to a WM-provided "titlebar and borders" parent window, the app would refuse to render anything without enabling the relevant hack.)
2. Caring so little about solving known bugs that slipped through QA that, for a shamefully long window of time, users with more than one monitor literally had to hex-edit their JVM to intentionally no-op the XINERAMA detection to make applications work. (i.e. XINERAMA being the X11 extension that allows Windows/Mac-style "one desktop stretched across multiple monitors" multi-head instead of the older "Behaves like a software KVM and applications are trapped on the monitors they opened on" Zaphod mode.)
3. Having some kind of input-response latency that I've never seen in another language or toolkit, which is apparently caused by something so fundamentally Java that it's present in every Java toolkit I've checked.
As far as greybeards go, I think we'd need more data points. Eric S. Raymond is quite an old-guard guy and even had some "jumps to conclusions"-y, "it's not enough like C"-ish reasons for choosing Go over Rust (eg. No `select` as part of the standard library, ignoring how Rust intentionally keeps the standard library minimal), but had no problem with using Python where it was suitable, while he didn't like Java because it was was more of the ChromeOS or Android school of doing stuff on top of a POSIX base.
People who don't care about Stallman's zealotry do still care about that and it presented a similar lasting problem to Java's Linux uptake as the problem D had more broadly with two competing and mutually incompatible standard libraries (Phobos and Tango) in the early years.
As for the GUIs, I listed three different ways unique to Java that Java GUIs were subpar on Linux:
1. Needing weird workarounds for applications to not display blank grey windows on non-reparenting window managers. (Basically, if the WM was something like a tiling WM that didn't reparent it from the root window to a WM-provided "titlebar and borders" parent window, the app would refuse to render anything without enabling the relevant hack.)
2. Caring so little about solving known bugs that slipped through QA that, for a shamefully long window of time, users with more than one monitor literally had to hex-edit their JVM to intentionally no-op the XINERAMA detection to make applications work. (i.e. XINERAMA being the X11 extension that allows Windows/Mac-style "one desktop stretched across multiple monitors" multi-head instead of the older "Behaves like a software KVM and applications are trapped on the monitors they opened on" Zaphod mode.)
3. Having some kind of input-response latency that I've never seen in another language or toolkit, which is apparently caused by something so fundamentally Java that it's present in every Java toolkit I've checked.
As far as greybeards go, I think we'd need more data points. Eric S. Raymond is quite an old-guard guy and even had some "jumps to conclusions"-y, "it's not enough like C"-ish reasons for choosing Go over Rust (eg. No `select` as part of the standard library, ignoring how Rust intentionally keeps the standard library minimal), but had no problem with using Python where it was suitable, while he didn't like Java because it was was more of the ChromeOS or Android school of doing stuff on top of a POSIX base.