Community
Participate
Working Groups
The user experience when the launcher fails to find a JRE is pretty bad. I've answered many forum posts from confused users who encounter the launch failed dialog. The other aspect of this is poor behavior when wrong version of Java is found. The JVM detection logic in the launcher should be augmented with UI to prompt the user to find a compatible JVM install.
I can't remember how the dialog looks like. Can you add (or link to) a screenshot? https://www.google.de/search?q=eclipse+launcher+dialog+failed+jvm&espv=2&biw=995&bih=780&source=lnms&tbm=isch&sa=X&ved=0CAgQ_AUoA2oVChMI0MrDsayUyQIVBVYaCh14zAP1
Created attachment 257963 [details] When the JRE cannot be found
Concretely, what do you want to see happening? Provide the user with a way to specify the path to a VM?
Yes, a dialog to find JVM on disk coupled with version validation of user choice.
The other case to consider is failure to launch JVM recovery. Often it's a related issue as Eclipse detects some random JRE that's incapable of running it.
For instance, x32 and x64 mismatch results in failure to launch dialog. This is very common in user problem reports.
(In reply to Konstantin Komissarchik from comment #6) > For instance, x32 and x64 mismatch results in failure to launch dialog. This > is very common in user problem reports. This item does not cover that though, right?
(In reply to Pascal Rapicault from comment #7) > (In reply to Konstantin Komissarchik from comment #6) > > For instance, x32 and x64 mismatch results in failure to launch dialog. This > > is very common in user problem reports. > This item does not cover that though, right? The selection dialog should only list JREs that match the launcher's bitness.
ok
I think the easiest solution would have the launcher open a browser to a page on eclipse.org, passing the OS, bitness, and launch code, and have a dynamic page turn that into a diagnosis.
(In reply to Brian de Alwis from comment #10) > I think the easiest solution would have the launcher open a browser to a > page on eclipse.org, passing the OS, bitness, and launch code, and have a > dynamic page turn that into a diagnosis. Do you know other software doing this? I'm not sure we need a dynamic page. What I have in mind is to keep with a dialog, but improve error messages and simply let user select an alternate VM location. |------------------------------------------------------------------------ | Unable to find a compatible Java Runtime |------------------------------------------------------------------------ | Eclipse could not guess the location of a compatible Java Runtime. Make sure _Java is correctly installed and accessible_, or select a directory containing a compabible Java Runtime. | | OK | |Cancel| |------------------------------------------------------------------------ _Java is correctly installed and accessible_ would be a link to a static documentation page under help.eclipse.org for example, with some suggestion about how to install Java property, set JAVA_HOME, PATH... When clicking OK, user would get a dialog to select a directory, the specified directory would be check for things such as Java version, Java bitness compatibility... and could just warn user about "The selected folder is not a proper JRE", "The selected JRE doesn't match minimum required Java version (Java 8)", "The selected JRE doesn't match your maching bitness (JRE is 32-bits whereas machine is 64-bits)"... Then once user pressed OK on this Error dialog, they get re-routed to the initial "Unable to find a compatible Java Runtime" one. Once they selected a good JRE, it's used to startup Eclipse, and Eclipse would run checks at runtime comparing currently used JRE vs the one specified in eclipse.ini and JAVA_HOME. If they are different, the IDE would prompt |------------------------------------------------- | Java Runtime |------------------------------------------------- |You're using a non-default Java Runtime (/path/to/jre) to run Eclipse. Do you want to make it default for all Eclipse startups? | |Yes| |No| |------------------------------------------------- Clicking yes would edit the eclipse.ini,
(In reply to Mickael Istria from comment #11) > (In reply to Brian de Alwis from comment #10) > > I think the easiest solution would have the launcher open a browser to a > > page on eclipse.org, passing the OS, bitness, and launch code, and have a > > dynamic page turn that into a diagnosis. > > Do you know other software doing this? I'm not sure we need a dynamic page. > What I have in mind is to keep with a dialog, but improve error messages and > simply let user select an alternate VM location. I believe Windows often redirects to microsoft.com pages on certain types of errors. The advantage of punting to a dyanmic web page is that we can tune the content based on feedback or changing conditions long after the original deployment. We still see users using Eclipse 3.7 or 3.8, years after they were packaged. Broadening the scope here, it could be useful to have a 'Report a bug' item in Help that would receive the platform, java version, etc. That page could tell Mars users on Ubuntu 16.04 that their GTK3 is broken and to please update to Neon.
(In reply to Brian de Alwis from comment #12) > The advantage of punting to a dyanmic web page is that we can tune the > content based on feedback or changing conditions long after the original > deployment. The drawback is that it requires some Internet connection and redirecting users to other applications can be confusing when you don't already know the software you're using. > We still see users using Eclipse 3.7 or 3.8, years after they > were packaged. Too bad for them ;) I won't be kind: such users who don't want to update to newer version, is there anything we can do for them anyway? We already spend years improving things and they stick to older version and still want us to work for them, Apart from telling them to update, I don't think they're worth being considered as 1st class citizen and guiding our UX decisions for new versions. > Broadening the scope here, it could be useful to have a 'Report a bug' item > in Help that would receive the platform, java version, etc. That page could > tell Mars users on Ubuntu 16.04 that their GTK3 is broken and to please > update to Neon. It seems a bit far away of the scope of this issue and of the user-story of "Eclipse doesn't start".
(In reply to Brian de Alwis from comment #10) > I think the easiest solution would have the launcher open a browser to a > page on eclipse.org, passing the OS, bitness, and launch code, and have a > dynamic page turn that into a diagnosis. Please note that the Oomph team alreay created such a page for the Eclipse Installer, e.g., http://download.eclipse.org/oomph/jre/?vm=1_1_7_0_64_0&pi=http://www.eclipse.org/downloads/images/java.png&pn=Eclipse%20IDE%20for%20Java%20Developers . It's also accessible via IDE->Preferences->Oomph->Java Virtual Machines->Download... For the user it would, of course, be better to visit only one such page, if at all. Before someone starts spending effort to create another such page we'd appreciate to discuss ways to consolidate them into one. BTW. we also have some nice infrastructure to automatically detect JREs on Windows, MacOS and Linux (see preference page above)...
Cool! That's very much what I imagined. I ran the page above by a PHP developer here who doesn't use Eclipse and asked him what his next steps would be. He was confused by the JRE vs JDK text, and also a bit confused by why the page shows requiring 1.7 but started off with 1.8. For his next steps, he said he'd just download and install the first link (the JDK). Three things that I could see being changed about that page: - The title text on the page initially puzzled me ("Java for Windows Missing") as I wondered if "Missing" was placeholder. Maybe "Not Found"? Or if we can, differentiate between outdated vs not found. - Lumping JDK and JREs together is confusing for non-Java developers. Separating them, with a comment that Java developers will want the JDK, might help. And we should just highlight just the latest recommended JREs, with a button to show all available. - I wonder if it's worth putting some text there to explain why we don't ship a JRE/JDK, perhaps as an info popup.
A web page like this is only a part of the solution. The launcher still needs a dialog to prompt the user to select a JVM among those that are installed for when auto-detection fails to match with Eclipse requirements. This dialog does need a download link and it makes sense to link to some place on eclipse.org that we can keep updating over time.
How will the launcher know what Java version to validate for? Is there a flag in eclipse.ini? I'd like to make sure that we have the following scenario covered: User downloads a package that requires Java 7. They start it and Java 7 is found. Next, they install something from marketplace that requires 8. Upon restart, we need to catch that they are running on Java 7, but Java 8 is required.
That scenario also necessitates Eclipse restart post p2 install to be an actual restart (from the launcher).
(In reply to Konstantin Komissarchik from comment #17) > I'd like to make sure that we have the following scenario covered: User > downloads a package that requires Java 7. They start it and Java 7 is found. > Next, they install something from marketplace that requires 8. Upon restart, > we need to catch that they are running on Java 7, but Java 8 is required. I agree that this would be nice, but I *think* the status quo is the following: User successfully runs Eclipse with Java 7, then installs a plugin that requires Java 8. IIRC., p2 wouldn't complain but the next start will fail. What I mean is, p2 does not change any JRE configuration and it does even not prevent such "invalid" installs. (Sorry, I don't have the time right now to validate my assumption) Maybe Pascal can add some hints about what's possible and what's easier to implement, i.e., prevention vs. adjustment...
(In reply to Eike Stepper from comment #19) > (In reply to Konstantin Komissarchik from comment #17) > > I'd like to make sure that we have the following scenario covered: User > > downloads a package that requires Java 7. They start it and Java 7 is found. > > Next, they install something from marketplace that requires 8. Upon restart, > > we need to catch that they are running on Java 7, but Java 8 is required. > > I agree that this would be nice, but I *think* the status quo is the > following: User successfully runs Eclipse with Java 7, then installs a > plugin that requires Java 8. IIRC., p2 wouldn't complain but the next start > will fail. What I mean is, p2 does not change any JRE configuration and it > does even not prevent such "invalid" installs. (Sorry, I don't have the time > right now to validate my assumption) > > Maybe Pascal can add some hints about what's possible and what's easier to > implement, i.e., prevention vs. adjustment... Here are the solutions that can be done from a p2 standpoint: - The ideal solution is for p2 to prevent the installation of the plugin - A different solution but still OK, is to let the installation proceed but give a warning at the end to tell the user that the level of JRE being used for the installation is not suitable to run the installed plugin. This let the user run Eclipse w/o having to worry about JRE level. - A completely undesirable solution is to change the JRE setting in the eclipse.ini because it prevent the user to restart Eclipse (really bad IMO).
> Here are the solutions that can be done from a p2 standpoint: > - The ideal solution is for p2 to prevent the installation of the plugin I don't like this option one bit. :) Creating dead-ends and retract in flows is not good UX. > - A different solution but still OK, is to let the installation proceed but > give a warning at the end to tell the user that the level of JRE being used > for the installation is not suitable to run the installed plugin. This let > the user run Eclipse w/o having to worry about JRE level. > > - A completely undesirable solution is to change the JRE setting in the > eclipse.ini because it prevent the user to restart Eclipse (really bad IMO). I think we need a combination of these two. During install, p2 informs the user that the plugin they are about to install requires a higher JVM version. The user then has a choice whether to proceed or not. If proceeding, p2 installs and updates eclipse.ini (or whatever) to indicate that higher level JVM version is now required. The launcher takes over upon restart and guides the user in downloading/selecting the appropriate JVM.
(In reply to Konstantin Komissarchik from comment #21) > > Here are the solutions that can be done from a p2 standpoint: > > - The ideal solution is for p2 to prevent the installation of the plugin > > I don't like this option one bit. :) Creating dead-ends and retract in flows > is not good UX. If there is a clear explanation of the issue and some good guidance to troubleshoot it, it wouldn't be a dead-end. By the way, would it be possible to just embed a compatible JRE with the IDE? I know it's doable but don't know the reason why not doing it for EPP packages.
I've got a dummy question here: since we want this check to happen before the JVM starts most likely (since it's about finding the right JVM), does that mean that the dialog must be implement in the native widget technology (and then repeated 3 times)?
(In reply to Mickael Istria from comment #22) > By the way, would it be possible to just embed a compatible JRE with the IDE? AFAIK because we are not allowed to. There are legal reasons that prevent us from embedding one of the available JVMs. This was always the #1 reason, and I doubt that it has changed.
(In reply to Markus Knauer from comment #24) > (In reply to Mickael Istria from comment #22) > > By the way, would it be possible to just embed a compatible JRE with the IDE? > > AFAIK because we are not allowed to. There are legal reasons that prevent us > from embedding one of the available JVMs. This was always the #1 reason, and > I doubt that it has changed. Do you know if the legal issues were for Oracle JRE or for Java in general? Was it investigated whether it would be allowed with OpenJDK ?
(In reply to Mickael Istria from comment #23) > I've got a dummy question here: since we want this check to happen before > the JVM starts most likely (since it's about finding the right JVM), does > that mean that the dialog must be implement in the native widget technology > (and then repeated 3 times)? I guess this could be done in more or less shared code 1. Launcher determines that the JVM requirements are not met. 2. Starts Java 1.5 (or something) procedure that can detect available JVMs 3. Launcher is restarted using new setting pointing to correct JVM. The detection mechanism would be platform specific. On OS X there is a registry that can be queried to produce XML that can be parsed. See https://github.com/turesheim/eclipse-launcher/blob/master/net.resheim.eclipse.launcher.macosx/src/net/resheim/eclipse/launcher/macosx/OSXJavaLocator.java
(In reply to Mickael Istria from comment #22) > By the way, would it be possible to just embed a compatible JRE with the IDE? > I know it's doable but don't know the reason why not doing it for EPP > packages. Another concern is having a group track and maintaining up-to-date versions.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/226.
