Feature/java downloader #2069
Feature/java downloader #2069
Conversation
Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Delete LaunchContext Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Co-authored-by: DioEgizio <83089242+DioEgizio@users.noreply.github.com> Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: timoreo <contact@timoreo.fr>
Co-authored-by: flow <flowlnlnln@gmail.com> Signed-off-by: timoreo <contact@timoreo.fr>
Signed-off-by: TheKodeToad <TheKodeToad@proton.me>
Signed-off-by: TheKodeToad <TheKodeToad@proton.me>
Signed-off-by: TheKodeToad <TheKodeToad@proton.me>
Signed-off-by: TheKodeToad <TheKodeToad@proton.me>
…nloader Signed-off-by: TheKodeToad <TheKodeToad@proton.me>
Signed-off-by: TheKodeToad <TheKodeToad@proton.me>
Signed-off-by: Trial97 <alexandru.tripon97@gmail.com>
Signed-off-by: Trial97 <alexandru.tripon97@gmail.com>
Signed-off-by: Trial97 <alexandru.tripon97@gmail.com>
Signed-off-by: Trial97 <alexandru.tripon97@gmail.com>
There was a problem hiding this comment.
In context of the UI side of this PR; it is needed as it significantly simplifies the setup of instances.
Especially so when people have a pre-1.17 instance and a post-1.16.5 instance.
It will be painful to set up the defaults for one Java version, but then be forced to manually enter version path and arguments for each incompatible instance.
|
is it really necessary to have to download things like java-runtime-alpha and java-runtime-beta? I think just downloading java-runtime-gamma in 1.17 and 1.18 is fine. Also does the java autodownload work on archs where mojang doesn't provide everything (arm macs where there's only gamma and delta, linux arm64/arm32 where mojang provides no jres, and i guess arm windows)? Because if i understood correctly this only works for java runtimes from Mojang |
|
Mostly yes as mojang decided that the Minecraft is for that version. |
|
I don't think this solution is that great then. Providing a good experience to those on arm is important, and installing useless JREs isn't that great |
|
Ok I will look into it then :) |
|
@DioEgizio I mapped the alpha and beta to the gamma version on arm os(mac and windows). As mentioned I opted only to change the arm ones because they do not have an alternative and I want to keep it as close to what mojang uses. If the user doesn't want to use what we provide they can override the java path with one already installed on the system. If the mojang provides no jres for that mc version the auto download fails, but the auto select should still work. And as of now |
Iirc there's no adoptium java jre 8 for macOS arm, so we should link azul there. Also how shouldn't we also link everything on Linux arm64 and arm32? |
I will look into populating the java using azul for arm mac and window. |
|
I mean we should link arm linux to adoptium |
I will also look into that, but all the mentioned changes are meta related not related to the code on this PR. |
|
@DioEgizio I updated the meta PR to take into account the arm stuff but be aware that even so there are still cases where there is no java that matches the major and the os (e.g. windows_arm doesn't have java 8 in any vendor). |
|
the only thing i find kinda weird is still needing to have a global java. Why would I need it if i enable that feature, apart from that, LGTM |
|
The global java is used as a fallback in this case: if for what so reason the feature doesn't find a suitable java(there are a few rare cases the java doesn't exist for that arch) or if it fails to download it will fall back to global. |
Signed-off-by: Trial97 <alexandru.tripon97@gmail.com>
|
This is breaking the build when Built with: Fedora 39, |
|
Most of the version lists in PrismLauncher are sorted in descending order, but it seems these versions are not retaining any particular ordering. In this case, the correct version to select is the middle one, which should probably be elevated to the top based on date or semver sorting. |
|
Trying to figure out why instance overrides are not working. I have the following debugs: diff --git a/launcher/minecraft/launch/AutoInstallJava.cpp b/launcher/minecraft/launch/AutoInstallJava.cpp
index 1dc91003f..a12881a2e 100644
--- a/launcher/minecraft/launch/AutoInstallJava.cpp
+++ b/launcher/minecraft/launch/AutoInstallJava.cpp
@@ -60,12 +60,17 @@ AutoInstallJava::AutoInstallJava(LaunchTask* parent)
void AutoInstallJava::executeTask()
{
auto settings = m_instance->settings();
+ qDebug() << "OverrideJava: " << settings->get("OverrideJava");
+ qDebug() << "OverrideJavaLocation: " << settings->get("OverrideJavaLocation");
+ qDebug() << "JavaPath: " << settings->get("JavaPath");
if (!APPLICATION->settings()->get("AutomaticJavaSwitch").toBool() ||
(settings->get("OverrideJava").toBool() && settings->get("OverrideJavaLocation").toBool() &&
QFileInfo::exists(settings->get("JavaPath").toString()))) {
+ qDebug() << "Returning";
emitSucceeded();
return;
}
+ qDebug() << "Continuing";
auto packProfile = m_instance->getPackProfile();
if (!APPLICATION->settings()->get("AutomaticJavaDownload").toBool()) {
auto javas = APPLICATION->javalist();and an instance.cfg with: (in this example we are intentionally pulling in an incorrect Java version so we can distinguish the automatic swap that occurs at launch, but the same applies to anything) IgnoreJavaCompatibility=true
OverrideJavaArgs=true
OverrideJavaLocation=true
JavaPath=/usr/lib/jvm/java-11-openjdk-11.0.23.0.9-1.fc39.x86_64/bin/javabut it gives: Is it normal for these to show up as false? I think something is preventing instance-specific Java overrides from working when global auto-detect is enabled, which is making auto-detect act as a confusing master override over the user's Java settings. Edit: I think the problem is that sometimes |
Signed-off-by: Trial97 <alexandru.tripon97@gmail.com>
Signed-off-by: Trial97 <alexandru.tripon97@gmail.com>
Signed-off-by: Trial97 <alexandru.tripon97@gmail.com>
|
fixed all the comments mentioned by lordofpipes |
|
The sorting still has this pathological case, since Mojang has re-used the version number:
Other issues seem to be fixed. Works really well! |
|
That is fine as both share the same number it doesn't matter if you manually install the first over the second in this case. |
|
Just confirmed they are exactly the same. I thought maybe they changed what modules are included, but nope, same files. Wonder why Mojang published it twice — maybe one of them served as a release candidate. |
Signed-off-by: Trial97 <alexandru.tripon97@gmail.com>
|
@getchoo this is prio(and you already said you will review) |
blocked by this meta PR:PrismLauncher/meta#19
partially supersedes: #285 (I only focused on automatic java switch and download)
For testing the Metadata pointer should point towards:
https://raw.githubusercontent.com/Trial97/prism-meta-launcher/split_java_source/Have something working but still ignore this until is converted from draft, for a progress report check the ToDo list:This should work now. I'm now in the process of testing it with Asan.
To do:
add java extra paths: fixe s Allow users to add manually installed java path to Java version selector #563)