openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <>
Subject Re: [QUESTION] Usability of Non-Optional Java Dependencies
Date Sun, 01 Nov 2015 17:21:37 GMT
On Fri, Oct 30, 2015 at 4:14 PM, C&A Säger <> wrote:

> Hi,
> Please load the following screen shot:
> >
> The screenshot shows the Java options for a Win64 system with a 64-bit
> Java highlighted (C:\Program Files\...) while the selected one is "bad"
> the currently active JRE.
> 1. This is what the majority of AOO/Windows users struggle with:
> 1.1. They install some JRE which becomes visible in the AOO Java options
> but AOO complains about no functional JRE being installed. This is
> because most Windows systems run on 64 bit, the Oracle installer always
> installs the latest 64 bit Java, the AOO options list these inadequate
> JREs just like the adequate 32-bit JREs.
> LO5 comes as a 64-bit Windows application evading this problem.
> 1.2. Knowing this, the only way to distinguish right from wrong JREs is
> the "Location" indicated at the bottom of the list of JREs. It indicates
> the installation path of the JRE that is currently selected on that
> list. If it starts with C:\Program Files (x86)\... then it is a good
> JRE. Without (x86) it is a bad one, thought the standard one for that
> system.
> 1.3 Yes, the overall reputation of Java among end users is a problem.
> This is due to the weekly security updates of Java7 together with the
> malware installer.
> 2. Platform independent problems:
> 2.1. Another problem that comes up every now and then is also related to
> that list of detected JREs in the AOO options. The list is a list box
> with additional radio buttons. When you select another JRE than the
> previously selected by clicking on the name or navigating with
> up/down-keys and then confirm the dialog, you end up with the same JRE
> as before because only the hit on the space bar or a mouse-click on the
> radio button within the list actually selects the radio button for the JRE.
> 2.2. After successfully choosing another JRE, you are prompted to
> restart the office suite which fails when the user is unaware of the
> quick-starter (OT: "quick-starter" is the worst anti-feature which I
> disable for all my installations).
> 2.3. I used to run 1.x, 2.x and 3.x for many years
> without any JRE. I used the Base component with dBase, csv, spreadsheets
> and MySQL via ODBC. I designed input forms, wrote macros in Basic and
> Python, assigned macros to form controls, document events, menues,
> shortcuts and toolbar buttons without ever activating any JRE. In those
> days I was aware that the search function of the F1-help did not work
> (the index did work) and that I could not call macros via
> Tools>Macros>Run... (Tools>Macros>Organize>... let me run macros). And
> now this:
> >
> We get a whole cascade of wrong error messages about Java dependency.
> The errors are wrong because in the end the action will be performed
> successfully.
> Exact steps to reproduce bug #86541 with AOO 4.x on any platform:
> 1) Tools>Options>Java, disable Java
> 2) Shut down the office suite. Mind the nasty quick-starter!
> 3) Restart the office and if you do not have any macros, call
> Tools>Macros>Organize>Basic... [Organizer...] [New...] and confirm the
> defaults. You end up with an empty Main routine on Module1 of the
> Standard library.
> 4) menu:Tools>Macros run... [Cancel] the error message about missing
> dependencies and then run your macro anyway.
> When assigning a macro to some form control event (push button, list box
> etc.) you get more than 10 of these error messages, one for each
> evaillable event, before you can assign your macro to a chosen event.
> Hope this helps,
> Andreas Säger
> --
> Claudia & Andreas Säger

Thank you Andreas for that excellent and highly detailed explanation.

To summarise, users are beaten through a gauntlet of serious usability
problems when Java isn't successfully configured:
1. We don't have a Win64 version of AOO available for download.
2. The Win32 version that Windows users thus download, can't use 64 bit
Java, something that is tricky to see.
3. The list of detected JREs in AOO Options is awkward to use, with its
radio buttons.
4. The Quickstarter then stops AOO from being restarted.
5. Missing JRE error messages come up even for places where Java is
6. There are multiple (10+) missing JRE error messages when assigning
macros to form control events.

The solutions seem straightforward:
1. We should have a Win64 AOO download available. Why don't we?
2. The UI should be clearer that Java has the wrong bitness.
3. That's also what the Eclipse IDE does in its list of JREs. I am not sure
how that UI could be improved. What do you propose?
4. If we are keeping the Quickstarter, it needs to be more intelligent, and
restart itself when AOO is intentionally restarted by the user.
5-6. Missing JRE error messages should only come up (1) when Java is
actually needed, and (2) once for each dialog.

I've also noticed that the version of Java used to build AOO becomes the
minimum version of Java that it will accept in the list of detected JREs,
older versions just get this generic non-descriptive error: "The folder you
have selected does not contain a Java runtime environment. Please select a
different folder."


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message