FTBTeam / FTB-App

Electron, Vue2, and Tailwind based frontend system for the FTB App; a new Modpack launcher for FTB and Curse modpacks.
https://feed-the-beast.com/app
GNU Lesser General Public License v2.1
95 stars 25 forks source link

[Bug]: locked down to java 17 and fail to start downloaded runtime #566

Closed ghost closed 2 years ago

ghost commented 2 years ago

What Operating System

Linux (Arch)

App Version

202205171618-14abefffbf-release

UI Version

No response

Log Files

No response

Debug Code

-

Describe the bug

installer is locked down specific to java 17 and the script fails to run the downloaded runtime

Steps to reproduce

download current linux "SFX" script (for real - why not just use curl or wget to load the archive but construct some obscure "rar-sfx style" hybrid to not have to serve a binary? pointless) try to run note that it downloads a runtime of java 17 because arch has already advanced to java 18 note further an error message that the script can't find the java binary of the just downloaded and extract runtime

Expected behaviour

just a simple script to scan for ANY version of java by just executing "java" command instead of search in a couple dozen paths and use it

Screenshots

No response

Additional information

there's no need to fix down to java 17 for the installer - just by its default look and feel it's clearly a swing application without even bother looking into the source also: why to try to search thru couple of dozen of directories instead of rely on the user has java proper "installed" by the distributions package manager? you surely don't go as far to support gentoo or even LFS to even bother for manual scanning - so why not just rely on "java" be an available command thanks to package manager magic? if it's not installed just give a hint to install java runtime via package manager this also solves the requirement of need to download a specific runtime (which btw doesn't work cause for whatever reason I not even bothered to analyze the script fails to find the binary of the downloaded and extracted runtime anyway) - and anything version specific can also be done within java - eliminating the need for checking specific version by debug output but - as ftb being ftb I know for years again I had to tinker around to get it even working - as the legacy launcher somehow fails to find the authlib thanks to some NOT SUPPOSED TO USED classloader hacking of the systemclassloader ... man, why noone back then ever read recommendations about how NOT to use sun internals? as some genius had that bright idea to pack a script and a binary in an incompatible way I had to painly do a hexdump - edit the version detection on a hex level - and rebuild the mess to even get it running why is FTB so damn bad at these most basics of java programming over and over again? also: why to bother for this sophisticated manual search for a runtime but then rely on curl or wget to be available - heck, it's even the basic tools on even gentoo and LFS - and even on arch although not directly mentioned in the install guide one comes rather fast to a point where one of them is needed - so it can be taken as given same as gzip and tar oh - btw - why do gunzip and tar in two steps? you do know that tar also supports gzip decompression by either provide -z specific for gzip or just -a for auto detection based on filename and please - just for the sake - just provide a simple bashscript that just downloads the app pack and runs it with local java runtime - why even the need for "an installer"? linux != windows - there's no need for such crap - or just ship some form of archive that contains everything instead of rely to curl/wget anything afterwards ... oh, wait, right, you do have to cheap out on bandwidth ... then how about use git as mirror? there's so much wrong with this new "app" crap the same as back with the old .jar launcher - let alone the literally THOUSANDS of ERROR level messages when booting up any of the packs - it's not just infos or warnings - but ERRORS - which, again as the same as the past years, just noone bothers to pay attention why the F* I used ftb again - right, just to see that immersive petroleum is not up to 1.18 yet ... geez, was a mess to clean everything up again cause it had to be blasted in several different directories same as on windows - instead of just keep everything contained within that one directory I downloaded th script to - as it should be done on linux and with java applications in general

Information

ftb-helper[bot] commented 2 years ago

Hay, thanks for the issue! Unfortunately it looks like you've not provided a Debug code... We require this as it helps us find your issue as quickly as possible.

Please do the following

Please use the link below to download and run the FTB Debug tool. This is a tool built by our App Developers and will provide you a code that you need to attach to this issue. Please either edit your original issue or add a comment with this code.

Windows // MacOS // Linux

ghost commented 2 years ago

Try running the installer as INSTALL4J_JAVA_HOME="/usr/bin/java" ./FTBA_unix_202205171618-14abefffbf-release.sh, replacing my particular version of the shell script with the version you have on your PC.

Cloudhunter commented 2 years ago

Thanks for reporting this issue! However, in future if you could refrain from off-topic ranting that would be fantastic.

The current install system uses "Install4J" in order to install it - it wasn't anyone's "bright idea" inside FTB or CreeperHost to choose how it does the actual install process, but we are looking into making this better.

MichaelHillcox commented 2 years ago

duplicate of #536

See that issue for some ways to bypass the issues