You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Dennis E. Hamilton" <or...@apache.org> on 2015/10/29 18:44:52 UTC
[QUESTION] Usability of Non-Optional Java Dependencies
The Java dependency problem keeps coming up buried in other threads. I am redirecting the most recent case so we can put light on this situation.
Before the dependencies on Java are increased/improved, I think there is a crucial usability matter.
1. Currently users are trap-doored by exercising a feature or dialog that suddenly raises a Java dependency, sometimes for which there is no escape other than finding a way to shut down AOO that is not a normally-required skill.
2. The fact that full functioning of AOO is buried in the system requirements in a way that users can easily overlook (or never examine) is a problem. We can fix that page, even providing (or linking to) specific details of what the dependencies are. That would be useful so developers and power-users have the details. However, the system requirements are probably not read by most who download the software (based on over 40 million downloads of 4.1.1, overwhelmingly on systems designed for casual users).
3. If the installer required presence of Java, that would be a clear indication that it is required for operation. It would also be helpful if the installer provided an usable link for installing a workable Java if one is not present.
4. If the presence of Java is indeed optional, and the user does not have it or elects not to use it, AOO should not even offer functions for which Java is required. That is another way to improve the usability and at least avoid users falling through trap-doors.
5. Shouldn't we do this better? Or are we to decree that AOO is only intended for power-users who have strong skills with regard to managing their configurations, managing the install of dependencies, trouble-shooting and being able to work around the not-dependable way things work now?
Three paths come to mind.
A. Remove the Java dependencies.
B. Adjust the Java dependencies,
1. So that the dependencies are clear and the situation around failures to find a suitable JRE is made workable for casual users. This could involve the above (2-4) remedies.
2. Only then consider increasing the dependencies on Java for full-function operation in some controllable way.
C. Make AOO a Java application that has C++ components, rather than the reverse.
These are all serious. Probably on the way to either A or C, one must address B.
We also need to consider what the project's capacity for any of these cases happens to be.
Thoughts?
- Dennis
PS: There is a bigger question about platform presence in here. There are distributions for which Java dependency is not particularly attractive and we may be cutting ourselves off from those. That might not matter if we are talking about the small percentage of the downloads that are for neither Windows nor Macintosh desktop PCs.
> -----Original Message-----
> From: Pedro Giffuni [mailto:pfg@apache.org]
> Sent: Thursday, October 29, 2015 08:07
> To: Apache OO <de...@openoffice.apache.org>
> Subject: Re: Thinking of joining OpenOffice as a developer
>
> Hello;
>
> First of all, a warm welcome to Patricia. Java developers are
> particularly welcome at this stage!
>
> Just IMHO, the C++ side of AOO is either under-control or
> too-ugly-to care-about, so we would do good focus more on the
> Java parts, which are also somewhat ugly but still promising.
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Patricia Shanahan <pa...@acm.org>.
In that case, the basic program should definitely be in Java, to avoid
buffer overflows, undefined operations, and pointer arithmetic.
The Java security issues are associated with attempts to run untrusted
code in various controlled environments. That includes applets, as well
as well as dynamically loaded code in applications. My current attitude
is that I don't want any code I don't trust running on a system I care
about.
On 10/29/2015 11:13 AM, Rory O'Farrell wrote:
...
> I am aware that there is an undercurrent among computer users against
> Java because of various security holes - whether real or generated by
> media paranoia. My reaction would be that the basic (i.e.,
> unextended program) should be written in as secure a language as
> possible and extensions (which are an optional install) written as
> suits their author.
...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Andreas Säger <sa...@t-online.de>.
Am 03.11.2015 um 01:23 schrieb Patricia Shanahan:
> I have no idea of the frequency of that situation.
>
Hi,
On the user forum it occurs several times per month.
The list box of availlable JREs should not include 64-bit JREs.
It should have a label such as "Suitable 32-bit Java Runtimes on this
system:" plus an additional [Help] button, tool-tip and everything that
helps to resolve the situation without asking someone else for help. As
far as I know, help contents are partially platform specific anyway.
I don't know if possible, but there should be a one-click hyperlink to a
32-bit JRE. The official Oracle link to a manual download goes as far as
> http://www.java.com/de/download/manual.jsp
Oh, and I suppose it should (and could) be an ordinary list box without
any radio buttons.
This is a localized version (/de/ German) of the manual download page
where the user needs to know that the second link [Windows Offline]
http://javadl.sun.com/webapps/download/AutoDL?BundleId=111687 is the one
to download but NOT [Windows Online] and NOT [Windows Offline 64-bit].
Of course, the BundleID changes with every Java update.
And yes, this is Java8 and it works well although AOO specifies Java7.
IMHO, a hyperlink on a help page leading to the English
http://www.java.com/en/download/manual.jsp together with a localized
hint to download and install the 32-bit JRE labeled "Windows Offline"
could improve the situtation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Patricia Shanahan <pa...@acm.org>.
The argument for Win64 is that there may be many people who know and
care little about Java, but have it already installed for reasons other
than AOO. Those installations are much more likely to be Win64 than x86.
Because AOO is x86 only it has to ask for an x86 JRE, even if there is a
perfectly good Win64 JRE already installed.
I have no idea of the frequency of that situation.
On 11/2/2015 2:14 PM, Andrea Pescetti wrote:
> On 01/11/2015 Damjan Jovanovic wrote:
>> 1. We don't have a Win64 version of AOO available for download.
>
> This has never been a major request from our users, and also technically
> speaking the benefits a user would gain by running a 64-bit version are
> not so big. Sure, it look modern and it is good for marketing, and it is
> nice to have, but better OOXML compatibility (for example) would make
> many more users happy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Andrea Pescetti <pe...@apache.org>.
On 01/11/2015 Damjan Jovanovic wrote:
> 1. We don't have a Win64 version of AOO available for download.
This has never been a major request from our users, and also technically
speaking the benefits a user would gain by running a 64-bit version are
not so big. Sure, it look modern and it is good for marketing, and it is
nice to have, but better OOXML compatibility (for example) would make
many more users happy.
> 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.
These two are probably actionable.
> 4. The Quickstarter then stops AOO from being restarted.
> 5. Missing JRE error messages come up even for places where Java is
> optional.
> 6. There are multiple (10+) missing JRE error messages when assigning
> macros to form control events.
These three are bigger in scope, but good for usability.
> 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."
I'm not sure about this. Do you mean the version as major version? Like
Java 6, 7 or 8? We do build binaries with Java 6 anyway, so this is
probably correct.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Damjan Jovanovic <da...@apache.org>.
On Sun, Nov 1, 2015 at 7:47 PM, Dennis E. Hamilton <or...@apache.org>
wrote:
>
> Damjan,
>
> Thanks for the great summary of the situation, below. I have a few
> supporting comments there.
> > -----Original Message-----
> > From: Damjan Jovanovic [mailto:damjan@apache.org]
> > Sent: Sunday, November 1, 2015 09:22
> > To: Apache OO <de...@openoffice.apache.org>
> > Subject: Re: [QUESTION] Usability of Non-Optional Java Dependencies
> [ ... ]
> >
> > 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
> > optional.
> > 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."
> >
> > Damjan
> [orcmid]
>
> A while ago I started digging into how to improve the messages that do
> come up, although that doesn't remove users being trap-doored.
>
> I discovered that the way exceptions are chained together and used to
> build the resulting message dialog to users is difficult to untangle. My
> concern was that the user would receive multiple messages that all
> specified the same remedy (pointing to a single web page where details and
> the cure can be found). It may be appropriate to do that anyhow until a
> better solution is found. A quick fix for that part should not be too
> troublesome, other than needing new localizations for the few dialogs
> involved.
>
> By the way, the way Base chains exception messages and presents them looks
> like the technique that should be used in all of the code, since it
> provides invaluable diagnostic information.
>
>
+1 to exception chaining, something Java has been doing for 13 years since
version 1.4, but I do hate that UI used by Base to display the error
messages, where you have to click on each "Error list" item on the left
pane (which are all labeled "Error") to see its "Description" on the right
pane, because it hides the cause of the problem and also makes it difficult
to copy everything out of there and paste it into a bug report.
> I think releasing an x64 version for Windows would be great, although an
> x86 version would still be required so long as we support XP (or continue
> to provide simple/security updates to the last XP-compatible
> distribution). This should be a separate topic, because it also involves
> code signing, building "dual" installers, and going to a modern
> installation process. The ultimate goal should be to have the authentic
> Windows and Macintosh binaries be acceptable in the respective store
> systems. There are multiple moving parts to orchestrate in getting there.
> It's my impression that getting code signing in place is an essential first
> step.
>
> - Dennis
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
RE: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by "Dennis E. Hamilton" <or...@apache.org>.
Damjan,
Thanks for the great summary of the situation, below. I have a few supporting comments there.
> -----Original Message-----
> From: Damjan Jovanovic [mailto:damjan@apache.org]
> Sent: Sunday, November 1, 2015 09:22
> To: Apache OO <de...@openoffice.apache.org>
> Subject: Re: [QUESTION] Usability of Non-Optional Java Dependencies
[ ... ]
>
> 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
> optional.
> 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."
>
> Damjan
[orcmid]
A while ago I started digging into how to improve the messages that do come up, although that doesn't remove users being trap-doored.
I discovered that the way exceptions are chained together and used to build the resulting message dialog to users is difficult to untangle. My concern was that the user would receive multiple messages that all specified the same remedy (pointing to a single web page where details and the cure can be found). It may be appropriate to do that anyhow until a better solution is found. A quick fix for that part should not be too troublesome, other than needing new localizations for the few dialogs involved.
By the way, the way Base chains exception messages and presents them looks like the technique that should be used in all of the code, since it provides invaluable diagnostic information.
I think releasing an x64 version for Windows would be great, although an x86 version would still be required so long as we support XP (or continue to provide simple/security updates to the last XP-compatible distribution). This should be a separate topic, because it also involves code signing, building "dual" installers, and going to a modern installation process. The ultimate goal should be to have the authentic Windows and Macintosh binaries be acceptable in the respective store systems. There are multiple moving parts to orchestrate in getting there. It's my impression that getting code signing in place is an essential first step.
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Damjan Jovanovic <da...@apache.org>.
On Fri, Oct 30, 2015 at 4:14 PM, C&A Säger <sa...@t-online.de> wrote:
> Hi,
>
> Please load the following screen shot:
> > http://www.mediafire.com/view/sqwigulqh8yfziu/JavaOptionsWin64.png
>
> 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 OpenOffice.org 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:
> > https://bz.apache.org/ooo/show_bug.cgi?id=86541
> 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
> saegerei@t-online.de
>
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
optional.
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."
Damjan
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by C&A Säger <sa...@t-online.de>.
Hi,
Please load the following screen shot:
> http://www.mediafire.com/view/sqwigulqh8yfziu/JavaOptionsWin64.png
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 OpenOffice.org 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:
> https://bz.apache.org/ooo/show_bug.cgi?id=86541
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
saegerei@t-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Rory O'Farrell <of...@iol.ie>.
On Thu, 29 Oct 2015 10:44:52 -0700
"Dennis E. Hamilton" <or...@apache.org> wrote:
> The Java dependency problem keeps coming up buried in other threads. I am redirecting the most recent case so we can put light on this situation.
>
> Before the dependencies on Java are increased/improved, I think there is a crucial usability matter.
>
> 1. Currently users are trap-doored by exercising a feature or dialog that suddenly raises a Java dependency, sometimes for which there is no escape other than finding a way to shut down AOO that is not a normally-required skill.
>
> 2. The fact that full functioning of AOO is buried in the system requirements in a way that users can easily overlook (or never examine) is a problem. We can fix that page, even providing (or linking to) specific details of what the dependencies are. That would be useful so developers and power-users have the details. However, the system requirements are probably not read by most who download the software (based on over 40 million downloads of 4.1.1, overwhelmingly on systems designed for casual users).
>
> 3. If the installer required presence of Java, that would be a clear indication that it is required for operation. It would also be helpful if the installer provided an usable link for installing a workable Java if one is not present.
>
> 4. If the presence of Java is indeed optional, and the user does not have it or elects not to use it, AOO should not even offer functions for which Java is required. That is another way to improve the usability and at least avoid users falling through trap-doors.
>
> 5. Shouldn't we do this better? Or are we to decree that AOO is only intended for power-users who have strong skills with regard to managing their configurations, managing the install of dependencies, trouble-shooting and being able to work around the not-dependable way things work now?
>
> Three paths come to mind.
>
> A. Remove the Java dependencies.
>
> B. Adjust the Java dependencies,
> 1. So that the dependencies are clear and the situation around failures to find a suitable JRE is made workable for casual users. This could involve the above (2-4) remedies.
> 2. Only then consider increasing the dependencies on Java for full-function operation in some controllable way.
>
> C. Make AOO a Java application that has C++ components, rather than the reverse.
>
> These are all serious. Probably on the way to either A or C, one must address B.
>
> We also need to consider what the project's capacity for any of these cases happens to be.
>
> Thoughts?
>
> - Dennis
>
> PS: There is a bigger question about platform presence in here. There are distributions for which Java dependency is not particularly attractive and we may be cutting ourselves off from those. That might not matter if we are talking about the small percentage of the downloads that are for neither Windows nor Macintosh desktop PCs.
I am aware that there is an undercurrent among computer users against Java because of various security holes - whether real or generated by media paranoia. My reaction would be that the basic (i.e., unextended program) should be written in as secure a language as possible and extensions (which are an optional install) written as suits their author.
>
>
>
> > -----Original Message-----
> > From: Pedro Giffuni [mailto:pfg@apache.org]
> > Sent: Thursday, October 29, 2015 08:07
> > To: Apache OO <de...@openoffice.apache.org>
> > Subject: Re: Thinking of joining OpenOffice as a developer
> >
> > Hello;
> >
> > First of all, a warm welcome to Patricia. Java developers are
> > particularly welcome at this stage!
> >
> > Just IMHO, the C++ side of AOO is either under-control or
> > too-ugly-to care-about, so we would do good focus more on the
> > Java parts, which are also somewhat ugly but still promising.
> [ ... ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
Rory O'Farrell <of...@iol.ie>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Greg Bullock <gr...@nwra.com>.
Thank you, to both of you, for the confirmation and the linked references.
Greg
On 10/29/2015 1:07 PM, Simon Phipps wrote:
> It's not just third-party reports like the one both you and I have cited.
> Oracle also documents its installation of adware/spyware with Java:
> http://www.java.com/en/download/faq/ask_toolbar.xml
>
> tells expert users how to bypass it:
> http://www.java.com/en/download/faq/disable_offers.xml
>
> and disingenuously pretends it's all good:
> http://www.java.com/en/download/faq/adware_spyware.xml
>
> S.
>
> On Thu, Oct 29, 2015 at 7:10 PM, Patricia Shanahan <pa...@acm.org> wrote:
>
>> See, for example,
>> http://superuser.com/questions/549028/how-can-i-prevent-ask-com-toolbar-from-being-installed-every-time-java-is-update
>>
>> I just did a simple default install of the current JRE, and it did not
>> offer Ask.com, so maybe Oracle has seen the error of their ways.
>>
>>
>> On 10/29/2015 11:57 AM, Greg Bullock wrote:
>>
>>> Would you confirm that, about the adware/spyware tricks? If confirmed,
>>> that would definitely interest me.
>>>
>>> Perhaps it's just my obliviousness or rapidly fading memory, but I don't
>>> recall ever seeing a trap on Oracle's Java download trying to install
>>> adware/spyware.
>>>
>>>
>>> http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
>>>
>>>
>>> I've used Java (JRE, JDK and Netbeans) on Windows actively for 5+ years,
>>> and occasionally for longer than that, and I just don't recall seeing a
>>> malware trick there. I see them on other sites for other software, but
>>> not there for Java.
>>>
>>> Greg
>>>
>>>
>>>
>>> On 10/29/2015 11:44 AM, Simon Phipps wrote:
>>>
>>>> One more factor to consider is that the official Java installer
>>>> promoted by
>>>> Oracle tries really hard to trick the end-user into installing
>>>> adware/spyware at the same time. We used to avoid this in the Sun
>>>> installer
>>>> by bundling Java, but having it as an external dependency for new AOO
>>>> users
>>>> means they face the challenge not only of finding and installing Java but
>>>> avoiding the malware as they do so.
>>>>
>>>> I'd say this was a really big negative for a dependency on official Java.
>>>> It's not a problem on Linux where there is usually an OpenJDK bundle
>>>> available, but it's a huge negative on Windows.
>>>>
>>>> S.
>>>>
>>>>
>>>> On Thu, Oct 29, 2015 at 5:44 PM, Dennis E. Hamilton <or...@apache.org>
>>>> wrote:
>>>>
>>>> The Java dependency problem keeps coming up buried in other threads.
>>>>> I am
>>>>> redirecting the most recent case so we can put light on this situation.
>>>>>
>>>>> Before the dependencies on Java are increased/improved, I think there
>>>>> is a
>>>>> crucial usability matter.
>>>>>
>>>>> 1. Currently users are trap-doored by exercising a feature or
>>>>> dialog that
>>>>> suddenly raises a Java dependency, sometimes for which there is no
>>>>> escape
>>>>> other than finding a way to shut down AOO that is not a
>>>>> normally-required
>>>>> skill.
>>>>>
>>>>> 2. The fact that full functioning of AOO is buried in the system
>>>>> requirements in a way that users can easily overlook (or never
>>>>> examine) is
>>>>> a problem. We can fix that page, even providing (or linking to)
>>>>> specific
>>>>> details of what the dependencies are. That would be useful so developers
>>>>> and power-users have the details. However, the system requirements are
>>>>> probably not read by most who download the software (based on over 40
>>>>> million downloads of 4.1.1, overwhelmingly on systems designed for
>>>>> casual
>>>>> users).
>>>>>
>>>>> 3. If the installer required presence of Java, that would be a clear
>>>>> indication that it is required for operation. It would also be
>>>>> helpful if
>>>>> the installer provided an usable link for installing a workable Java
>>>>> if one
>>>>> is not present.
>>>>>
>>>>> 4. If the presence of Java is indeed optional, and the user does
>>>>> not have
>>>>> it or elects not to use it, AOO should not even offer functions for
>>>>> which
>>>>> Java is required. That is another way to improve the usability and at
>>>>> least avoid users falling through trap-doors.
>>>>>
>>>>> 5. Shouldn't we do this better? Or are we to decree that AOO is only
>>>>> intended for power-users who have strong skills with regard to managing
>>>>> their configurations, managing the install of dependencies,
>>>>> trouble-shooting and being able to work around the not-dependable way
>>>>> things work now?
>>>>>
>>>>> Three paths come to mind.
>>>>>
>>>>> A. Remove the Java dependencies.
>>>>>
>>>>> B. Adjust the Java dependencies,
>>>>> 1. So that the dependencies are clear and the situation around
>>>>> failures to find a suitable JRE is made workable for casual users. This
>>>>> could involve the above (2-4) remedies.
>>>>> 2. Only then consider increasing the dependencies on Java for
>>>>> full-function operation in some controllable way.
>>>>>
>>>>> C. Make AOO a Java application that has C++ components, rather than
>>>>> the
>>>>> reverse.
>>>>>
>>>>> These are all serious. Probably on the way to either A or C, one must
>>>>> address B.
>>>>>
>>>>> We also need to consider what the project's capacity for any of these
>>>>> cases happens to be.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> - Dennis
>>>>>
>>>>> PS: There is a bigger question about platform presence in here.
>>>>> There are
>>>>> distributions for which Java dependency is not particularly
>>>>> attractive and
>>>>> we may be cutting ourselves off from those. That might not matter if we
>>>>> are talking about the small percentage of the downloads that are for
>>>>> neither Windows nor Macintosh desktop PCs.
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>>> From: Pedro Giffuni [mailto:pfg@apache.org]
>>>>>> Sent: Thursday, October 29, 2015 08:07
>>>>>> To: Apache OO <de...@openoffice.apache.org>
>>>>>> Subject: Re: Thinking of joining OpenOffice as a developer
>>>>>>
>>>>>> Hello;
>>>>>>
>>>>>> First of all, a warm welcome to Patricia. Java developers are
>>>>>> particularly welcome at this stage!
>>>>>>
>>>>>> Just IMHO, the C++ side of AOO is either under-control or
>>>>>> too-ugly-to care-about, so we would do good focus more on the
>>>>>> Java parts, which are also somewhat ugly but still promising.
>>>>>>
>>>>> [ ... ]
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
--
Greg Bullock
NorthWest Research Associates
301 Webster St.
Monterey, CA 93940
(831) 582-4907
greg@nwra.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Simon Phipps <si...@webmink.com>.
It's not just third-party reports like the one both you and I have cited.
Oracle also documents its installation of adware/spyware with Java:
http://www.java.com/en/download/faq/ask_toolbar.xml
tells expert users how to bypass it:
http://www.java.com/en/download/faq/disable_offers.xml
and disingenuously pretends it's all good:
http://www.java.com/en/download/faq/adware_spyware.xml
S.
On Thu, Oct 29, 2015 at 7:10 PM, Patricia Shanahan <pa...@acm.org> wrote:
> See, for example,
> http://superuser.com/questions/549028/how-can-i-prevent-ask-com-toolbar-from-being-installed-every-time-java-is-update
>
> I just did a simple default install of the current JRE, and it did not
> offer Ask.com, so maybe Oracle has seen the error of their ways.
>
>
> On 10/29/2015 11:57 AM, Greg Bullock wrote:
>
>> Would you confirm that, about the adware/spyware tricks? If confirmed,
>> that would definitely interest me.
>>
>> Perhaps it's just my obliviousness or rapidly fading memory, but I don't
>> recall ever seeing a trap on Oracle's Java download trying to install
>> adware/spyware.
>>
>>
>> http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
>>
>>
>> I've used Java (JRE, JDK and Netbeans) on Windows actively for 5+ years,
>> and occasionally for longer than that, and I just don't recall seeing a
>> malware trick there. I see them on other sites for other software, but
>> not there for Java.
>>
>> Greg
>>
>>
>>
>> On 10/29/2015 11:44 AM, Simon Phipps wrote:
>>
>>> One more factor to consider is that the official Java installer
>>> promoted by
>>> Oracle tries really hard to trick the end-user into installing
>>> adware/spyware at the same time. We used to avoid this in the Sun
>>> installer
>>> by bundling Java, but having it as an external dependency for new AOO
>>> users
>>> means they face the challenge not only of finding and installing Java but
>>> avoiding the malware as they do so.
>>>
>>> I'd say this was a really big negative for a dependency on official Java.
>>> It's not a problem on Linux where there is usually an OpenJDK bundle
>>> available, but it's a huge negative on Windows.
>>>
>>> S.
>>>
>>>
>>> On Thu, Oct 29, 2015 at 5:44 PM, Dennis E. Hamilton <or...@apache.org>
>>> wrote:
>>>
>>> The Java dependency problem keeps coming up buried in other threads.
>>>> I am
>>>> redirecting the most recent case so we can put light on this situation.
>>>>
>>>> Before the dependencies on Java are increased/improved, I think there
>>>> is a
>>>> crucial usability matter.
>>>>
>>>> 1. Currently users are trap-doored by exercising a feature or
>>>> dialog that
>>>> suddenly raises a Java dependency, sometimes for which there is no
>>>> escape
>>>> other than finding a way to shut down AOO that is not a
>>>> normally-required
>>>> skill.
>>>>
>>>> 2. The fact that full functioning of AOO is buried in the system
>>>> requirements in a way that users can easily overlook (or never
>>>> examine) is
>>>> a problem. We can fix that page, even providing (or linking to)
>>>> specific
>>>> details of what the dependencies are. That would be useful so developers
>>>> and power-users have the details. However, the system requirements are
>>>> probably not read by most who download the software (based on over 40
>>>> million downloads of 4.1.1, overwhelmingly on systems designed for
>>>> casual
>>>> users).
>>>>
>>>> 3. If the installer required presence of Java, that would be a clear
>>>> indication that it is required for operation. It would also be
>>>> helpful if
>>>> the installer provided an usable link for installing a workable Java
>>>> if one
>>>> is not present.
>>>>
>>>> 4. If the presence of Java is indeed optional, and the user does
>>>> not have
>>>> it or elects not to use it, AOO should not even offer functions for
>>>> which
>>>> Java is required. That is another way to improve the usability and at
>>>> least avoid users falling through trap-doors.
>>>>
>>>> 5. Shouldn't we do this better? Or are we to decree that AOO is only
>>>> intended for power-users who have strong skills with regard to managing
>>>> their configurations, managing the install of dependencies,
>>>> trouble-shooting and being able to work around the not-dependable way
>>>> things work now?
>>>>
>>>> Three paths come to mind.
>>>>
>>>> A. Remove the Java dependencies.
>>>>
>>>> B. Adjust the Java dependencies,
>>>> 1. So that the dependencies are clear and the situation around
>>>> failures to find a suitable JRE is made workable for casual users. This
>>>> could involve the above (2-4) remedies.
>>>> 2. Only then consider increasing the dependencies on Java for
>>>> full-function operation in some controllable way.
>>>>
>>>> C. Make AOO a Java application that has C++ components, rather than
>>>> the
>>>> reverse.
>>>>
>>>> These are all serious. Probably on the way to either A or C, one must
>>>> address B.
>>>>
>>>> We also need to consider what the project's capacity for any of these
>>>> cases happens to be.
>>>>
>>>> Thoughts?
>>>>
>>>> - Dennis
>>>>
>>>> PS: There is a bigger question about platform presence in here.
>>>> There are
>>>> distributions for which Java dependency is not particularly
>>>> attractive and
>>>> we may be cutting ourselves off from those. That might not matter if we
>>>> are talking about the small percentage of the downloads that are for
>>>> neither Windows nor Macintosh desktop PCs.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>>> From: Pedro Giffuni [mailto:pfg@apache.org]
>>>>> Sent: Thursday, October 29, 2015 08:07
>>>>> To: Apache OO <de...@openoffice.apache.org>
>>>>> Subject: Re: Thinking of joining OpenOffice as a developer
>>>>>
>>>>> Hello;
>>>>>
>>>>> First of all, a warm welcome to Patricia. Java developers are
>>>>> particularly welcome at this stage!
>>>>>
>>>>> Just IMHO, the C++ side of AOO is either under-control or
>>>>> too-ugly-to care-about, so we would do good focus more on the
>>>>> Java parts, which are also somewhat ugly but still promising.
>>>>>
>>>> [ ... ]
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>>
>>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
*Simon Phipps* http://webmink.com
*Office:* +1 (415) 683-7660 *or* +44 (238) 098 7027
*Mobile*: +44 774 776 2816 *or Telegram <https://telegram.me/webmink>*
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Patricia Shanahan <pa...@acm.org>.
I checked my Java Control Panel and I have "Suppress sponsor offers when
installing or updating Java" checked, so my install experience is not
useful information.
I don't remember checking it, but it would be a no-brainer first time I
saw it in the control panel, considering how I feel about the Ask.com mess.
On 10/29/2015 12:10 PM, Patricia Shanahan wrote:
> See, for example,
> http://superuser.com/questions/549028/how-can-i-prevent-ask-com-toolbar-from-being-installed-every-time-java-is-update
>
>
> I just did a simple default install of the current JRE, and it did not
> offer Ask.com, so maybe Oracle has seen the error of their ways.
>
> On 10/29/2015 11:57 AM, Greg Bullock wrote:
>> Would you confirm that, about the adware/spyware tricks? If confirmed,
>> that would definitely interest me.
>>
>> Perhaps it's just my obliviousness or rapidly fading memory, but I don't
>> recall ever seeing a trap on Oracle's Java download trying to install
>> adware/spyware.
>>
>> http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
>>
>>
>>
>> I've used Java (JRE, JDK and Netbeans) on Windows actively for 5+ years,
>> and occasionally for longer than that, and I just don't recall seeing a
>> malware trick there. I see them on other sites for other software, but
>> not there for Java.
>>
>> Greg
>>
>>
>>
>> On 10/29/2015 11:44 AM, Simon Phipps wrote:
>>> One more factor to consider is that the official Java installer
>>> promoted by
>>> Oracle tries really hard to trick the end-user into installing
>>> adware/spyware at the same time. We used to avoid this in the Sun
>>> installer
>>> by bundling Java, but having it as an external dependency for new AOO
>>> users
>>> means they face the challenge not only of finding and installing Java
>>> but
>>> avoiding the malware as they do so.
>>>
>>> I'd say this was a really big negative for a dependency on official
>>> Java.
>>> It's not a problem on Linux where there is usually an OpenJDK bundle
>>> available, but it's a huge negative on Windows.
>>>
>>> S.
>>>
>>>
>>> On Thu, Oct 29, 2015 at 5:44 PM, Dennis E. Hamilton <or...@apache.org>
>>> wrote:
>>>
>>>> The Java dependency problem keeps coming up buried in other threads.
>>>> I am
>>>> redirecting the most recent case so we can put light on this situation.
>>>>
>>>> Before the dependencies on Java are increased/improved, I think there
>>>> is a
>>>> crucial usability matter.
>>>>
>>>> 1. Currently users are trap-doored by exercising a feature or
>>>> dialog that
>>>> suddenly raises a Java dependency, sometimes for which there is no
>>>> escape
>>>> other than finding a way to shut down AOO that is not a
>>>> normally-required
>>>> skill.
>>>>
>>>> 2. The fact that full functioning of AOO is buried in the system
>>>> requirements in a way that users can easily overlook (or never
>>>> examine) is
>>>> a problem. We can fix that page, even providing (or linking to)
>>>> specific
>>>> details of what the dependencies are. That would be useful so
>>>> developers
>>>> and power-users have the details. However, the system requirements are
>>>> probably not read by most who download the software (based on over 40
>>>> million downloads of 4.1.1, overwhelmingly on systems designed for
>>>> casual
>>>> users).
>>>>
>>>> 3. If the installer required presence of Java, that would be a clear
>>>> indication that it is required for operation. It would also be
>>>> helpful if
>>>> the installer provided an usable link for installing a workable Java
>>>> if one
>>>> is not present.
>>>>
>>>> 4. If the presence of Java is indeed optional, and the user does
>>>> not have
>>>> it or elects not to use it, AOO should not even offer functions for
>>>> which
>>>> Java is required. That is another way to improve the usability and at
>>>> least avoid users falling through trap-doors.
>>>>
>>>> 5. Shouldn't we do this better? Or are we to decree that AOO is only
>>>> intended for power-users who have strong skills with regard to managing
>>>> their configurations, managing the install of dependencies,
>>>> trouble-shooting and being able to work around the not-dependable way
>>>> things work now?
>>>>
>>>> Three paths come to mind.
>>>>
>>>> A. Remove the Java dependencies.
>>>>
>>>> B. Adjust the Java dependencies,
>>>> 1. So that the dependencies are clear and the situation around
>>>> failures to find a suitable JRE is made workable for casual users.
>>>> This
>>>> could involve the above (2-4) remedies.
>>>> 2. Only then consider increasing the dependencies on Java for
>>>> full-function operation in some controllable way.
>>>>
>>>> C. Make AOO a Java application that has C++ components, rather than
>>>> the
>>>> reverse.
>>>>
>>>> These are all serious. Probably on the way to either A or C, one must
>>>> address B.
>>>>
>>>> We also need to consider what the project's capacity for any of these
>>>> cases happens to be.
>>>>
>>>> Thoughts?
>>>>
>>>> - Dennis
>>>>
>>>> PS: There is a bigger question about platform presence in here.
>>>> There are
>>>> distributions for which Java dependency is not particularly
>>>> attractive and
>>>> we may be cutting ourselves off from those. That might not matter
>>>> if we
>>>> are talking about the small percentage of the downloads that are for
>>>> neither Windows nor Macintosh desktop PCs.
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Pedro Giffuni [mailto:pfg@apache.org]
>>>>> Sent: Thursday, October 29, 2015 08:07
>>>>> To: Apache OO <de...@openoffice.apache.org>
>>>>> Subject: Re: Thinking of joining OpenOffice as a developer
>>>>>
>>>>> Hello;
>>>>>
>>>>> First of all, a warm welcome to Patricia. Java developers are
>>>>> particularly welcome at this stage!
>>>>>
>>>>> Just IMHO, the C++ side of AOO is either under-control or
>>>>> too-ugly-to care-about, so we would do good focus more on the
>>>>> Java parts, which are also somewhat ugly but still promising.
>>>> [ ... ]
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Patricia Shanahan <pa...@acm.org>.
See, for example,
http://superuser.com/questions/549028/how-can-i-prevent-ask-com-toolbar-from-being-installed-every-time-java-is-update
I just did a simple default install of the current JRE, and it did not
offer Ask.com, so maybe Oracle has seen the error of their ways.
On 10/29/2015 11:57 AM, Greg Bullock wrote:
> Would you confirm that, about the adware/spyware tricks? If confirmed,
> that would definitely interest me.
>
> Perhaps it's just my obliviousness or rapidly fading memory, but I don't
> recall ever seeing a trap on Oracle's Java download trying to install
> adware/spyware.
>
> http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
>
>
> I've used Java (JRE, JDK and Netbeans) on Windows actively for 5+ years,
> and occasionally for longer than that, and I just don't recall seeing a
> malware trick there. I see them on other sites for other software, but
> not there for Java.
>
> Greg
>
>
>
> On 10/29/2015 11:44 AM, Simon Phipps wrote:
>> One more factor to consider is that the official Java installer
>> promoted by
>> Oracle tries really hard to trick the end-user into installing
>> adware/spyware at the same time. We used to avoid this in the Sun
>> installer
>> by bundling Java, but having it as an external dependency for new AOO
>> users
>> means they face the challenge not only of finding and installing Java but
>> avoiding the malware as they do so.
>>
>> I'd say this was a really big negative for a dependency on official Java.
>> It's not a problem on Linux where there is usually an OpenJDK bundle
>> available, but it's a huge negative on Windows.
>>
>> S.
>>
>>
>> On Thu, Oct 29, 2015 at 5:44 PM, Dennis E. Hamilton <or...@apache.org>
>> wrote:
>>
>>> The Java dependency problem keeps coming up buried in other threads.
>>> I am
>>> redirecting the most recent case so we can put light on this situation.
>>>
>>> Before the dependencies on Java are increased/improved, I think there
>>> is a
>>> crucial usability matter.
>>>
>>> 1. Currently users are trap-doored by exercising a feature or
>>> dialog that
>>> suddenly raises a Java dependency, sometimes for which there is no
>>> escape
>>> other than finding a way to shut down AOO that is not a
>>> normally-required
>>> skill.
>>>
>>> 2. The fact that full functioning of AOO is buried in the system
>>> requirements in a way that users can easily overlook (or never
>>> examine) is
>>> a problem. We can fix that page, even providing (or linking to)
>>> specific
>>> details of what the dependencies are. That would be useful so developers
>>> and power-users have the details. However, the system requirements are
>>> probably not read by most who download the software (based on over 40
>>> million downloads of 4.1.1, overwhelmingly on systems designed for
>>> casual
>>> users).
>>>
>>> 3. If the installer required presence of Java, that would be a clear
>>> indication that it is required for operation. It would also be
>>> helpful if
>>> the installer provided an usable link for installing a workable Java
>>> if one
>>> is not present.
>>>
>>> 4. If the presence of Java is indeed optional, and the user does
>>> not have
>>> it or elects not to use it, AOO should not even offer functions for
>>> which
>>> Java is required. That is another way to improve the usability and at
>>> least avoid users falling through trap-doors.
>>>
>>> 5. Shouldn't we do this better? Or are we to decree that AOO is only
>>> intended for power-users who have strong skills with regard to managing
>>> their configurations, managing the install of dependencies,
>>> trouble-shooting and being able to work around the not-dependable way
>>> things work now?
>>>
>>> Three paths come to mind.
>>>
>>> A. Remove the Java dependencies.
>>>
>>> B. Adjust the Java dependencies,
>>> 1. So that the dependencies are clear and the situation around
>>> failures to find a suitable JRE is made workable for casual users. This
>>> could involve the above (2-4) remedies.
>>> 2. Only then consider increasing the dependencies on Java for
>>> full-function operation in some controllable way.
>>>
>>> C. Make AOO a Java application that has C++ components, rather than
>>> the
>>> reverse.
>>>
>>> These are all serious. Probably on the way to either A or C, one must
>>> address B.
>>>
>>> We also need to consider what the project's capacity for any of these
>>> cases happens to be.
>>>
>>> Thoughts?
>>>
>>> - Dennis
>>>
>>> PS: There is a bigger question about platform presence in here.
>>> There are
>>> distributions for which Java dependency is not particularly
>>> attractive and
>>> we may be cutting ourselves off from those. That might not matter if we
>>> are talking about the small percentage of the downloads that are for
>>> neither Windows nor Macintosh desktop PCs.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Pedro Giffuni [mailto:pfg@apache.org]
>>>> Sent: Thursday, October 29, 2015 08:07
>>>> To: Apache OO <de...@openoffice.apache.org>
>>>> Subject: Re: Thinking of joining OpenOffice as a developer
>>>>
>>>> Hello;
>>>>
>>>> First of all, a warm welcome to Patricia. Java developers are
>>>> particularly welcome at this stage!
>>>>
>>>> Just IMHO, the C++ side of AOO is either under-control or
>>>> too-ugly-to care-about, so we would do good focus more on the
>>>> Java parts, which are also somewhat ugly but still promising.
>>> [ ... ]
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Simon Phipps <si...@webmink.com>.
See for example
http://www.zdnet.com/article/a-close-look-at-how-oracle-installs-deceptive-software-with-java-updates/
S.
On Thu, Oct 29, 2015 at 6:57 PM, Greg Bullock <gr...@nwra.com> wrote:
> Would you confirm that, about the adware/spyware tricks? If confirmed,
> that would definitely interest me.
>
> Perhaps it's just my obliviousness or rapidly fading memory, but I don't
> recall ever seeing a trap on Oracle's Java download trying to install
> adware/spyware.
>
>
> http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
>
> I've used Java (JRE, JDK and Netbeans) on Windows actively for 5+ years,
> and occasionally for longer than that, and I just don't recall seeing a
> malware trick there. I see them on other sites for other software, but not
> there for Java.
>
> Greg
>
>
>
>
> On 10/29/2015 11:44 AM, Simon Phipps wrote:
>
>> One more factor to consider is that the official Java installer promoted
>> by
>> Oracle tries really hard to trick the end-user into installing
>> adware/spyware at the same time. We used to avoid this in the Sun
>> installer
>> by bundling Java, but having it as an external dependency for new AOO
>> users
>> means they face the challenge not only of finding and installing Java but
>> avoiding the malware as they do so.
>>
>> I'd say this was a really big negative for a dependency on official Java.
>> It's not a problem on Linux where there is usually an OpenJDK bundle
>> available, but it's a huge negative on Windows.
>>
>> S.
>>
>>
>> On Thu, Oct 29, 2015 at 5:44 PM, Dennis E. Hamilton <or...@apache.org>
>> wrote:
>>
>> The Java dependency problem keeps coming up buried in other threads. I am
>>> redirecting the most recent case so we can put light on this situation.
>>>
>>> Before the dependencies on Java are increased/improved, I think there is
>>> a
>>> crucial usability matter.
>>>
>>> 1. Currently users are trap-doored by exercising a feature or dialog
>>> that
>>> suddenly raises a Java dependency, sometimes for which there is no escape
>>> other than finding a way to shut down AOO that is not a normally-required
>>> skill.
>>>
>>> 2. The fact that full functioning of AOO is buried in the system
>>> requirements in a way that users can easily overlook (or never examine)
>>> is
>>> a problem. We can fix that page, even providing (or linking to) specific
>>> details of what the dependencies are. That would be useful so developers
>>> and power-users have the details. However, the system requirements are
>>> probably not read by most who download the software (based on over 40
>>> million downloads of 4.1.1, overwhelmingly on systems designed for casual
>>> users).
>>>
>>> 3. If the installer required presence of Java, that would be a clear
>>> indication that it is required for operation. It would also be helpful
>>> if
>>> the installer provided an usable link for installing a workable Java if
>>> one
>>> is not present.
>>>
>>> 4. If the presence of Java is indeed optional, and the user does not
>>> have
>>> it or elects not to use it, AOO should not even offer functions for which
>>> Java is required. That is another way to improve the usability and at
>>> least avoid users falling through trap-doors.
>>>
>>> 5. Shouldn't we do this better? Or are we to decree that AOO is only
>>> intended for power-users who have strong skills with regard to managing
>>> their configurations, managing the install of dependencies,
>>> trouble-shooting and being able to work around the not-dependable way
>>> things work now?
>>>
>>> Three paths come to mind.
>>>
>>> A. Remove the Java dependencies.
>>>
>>> B. Adjust the Java dependencies,
>>> 1. So that the dependencies are clear and the situation around
>>> failures to find a suitable JRE is made workable for casual users. This
>>> could involve the above (2-4) remedies.
>>> 2. Only then consider increasing the dependencies on Java for
>>> full-function operation in some controllable way.
>>>
>>> C. Make AOO a Java application that has C++ components, rather than the
>>> reverse.
>>>
>>> These are all serious. Probably on the way to either A or C, one must
>>> address B.
>>>
>>> We also need to consider what the project's capacity for any of these
>>> cases happens to be.
>>>
>>> Thoughts?
>>>
>>> - Dennis
>>>
>>> PS: There is a bigger question about platform presence in here. There
>>> are
>>> distributions for which Java dependency is not particularly attractive
>>> and
>>> we may be cutting ourselves off from those. That might not matter if we
>>> are talking about the small percentage of the downloads that are for
>>> neither Windows nor Macintosh desktop PCs.
>>>
>>>
>>>
>>> -----Original Message-----
>>>> From: Pedro Giffuni [mailto:pfg@apache.org]
>>>> Sent: Thursday, October 29, 2015 08:07
>>>> To: Apache OO <de...@openoffice.apache.org>
>>>> Subject: Re: Thinking of joining OpenOffice as a developer
>>>>
>>>> Hello;
>>>>
>>>> First of all, a warm welcome to Patricia. Java developers are
>>>> particularly welcome at this stage!
>>>>
>>>> Just IMHO, the C++ side of AOO is either under-control or
>>>> too-ugly-to care-about, so we would do good focus more on the
>>>> Java parts, which are also somewhat ugly but still promising.
>>>>
>>> [ ... ]
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>>
>>
> --
> Greg Bullock
> NorthWest Research Associates
> 301 Webster St.
> Monterey, CA 93940
> (831) 582-4907
> greg@nwra.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
*Simon Phipps* http://webmink.com
*Office:* +1 (415) 683-7660 *or* +44 (238) 098 7027
*Mobile*: +44 774 776 2816 *or Telegram <https://telegram.me/webmink>*
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Greg Bullock <gr...@nwra.com>.
Would you confirm that, about the adware/spyware tricks? If confirmed,
that would definitely interest me.
Perhaps it's just my obliviousness or rapidly fading memory, but I don't
recall ever seeing a trap on Oracle's Java download trying to install
adware/spyware.
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
I've used Java (JRE, JDK and Netbeans) on Windows actively for 5+ years,
and occasionally for longer than that, and I just don't recall seeing a
malware trick there. I see them on other sites for other software, but
not there for Java.
Greg
On 10/29/2015 11:44 AM, Simon Phipps wrote:
> One more factor to consider is that the official Java installer promoted by
> Oracle tries really hard to trick the end-user into installing
> adware/spyware at the same time. We used to avoid this in the Sun installer
> by bundling Java, but having it as an external dependency for new AOO users
> means they face the challenge not only of finding and installing Java but
> avoiding the malware as they do so.
>
> I'd say this was a really big negative for a dependency on official Java.
> It's not a problem on Linux where there is usually an OpenJDK bundle
> available, but it's a huge negative on Windows.
>
> S.
>
>
> On Thu, Oct 29, 2015 at 5:44 PM, Dennis E. Hamilton <or...@apache.org>
> wrote:
>
>> The Java dependency problem keeps coming up buried in other threads. I am
>> redirecting the most recent case so we can put light on this situation.
>>
>> Before the dependencies on Java are increased/improved, I think there is a
>> crucial usability matter.
>>
>> 1. Currently users are trap-doored by exercising a feature or dialog that
>> suddenly raises a Java dependency, sometimes for which there is no escape
>> other than finding a way to shut down AOO that is not a normally-required
>> skill.
>>
>> 2. The fact that full functioning of AOO is buried in the system
>> requirements in a way that users can easily overlook (or never examine) is
>> a problem. We can fix that page, even providing (or linking to) specific
>> details of what the dependencies are. That would be useful so developers
>> and power-users have the details. However, the system requirements are
>> probably not read by most who download the software (based on over 40
>> million downloads of 4.1.1, overwhelmingly on systems designed for casual
>> users).
>>
>> 3. If the installer required presence of Java, that would be a clear
>> indication that it is required for operation. It would also be helpful if
>> the installer provided an usable link for installing a workable Java if one
>> is not present.
>>
>> 4. If the presence of Java is indeed optional, and the user does not have
>> it or elects not to use it, AOO should not even offer functions for which
>> Java is required. That is another way to improve the usability and at
>> least avoid users falling through trap-doors.
>>
>> 5. Shouldn't we do this better? Or are we to decree that AOO is only
>> intended for power-users who have strong skills with regard to managing
>> their configurations, managing the install of dependencies,
>> trouble-shooting and being able to work around the not-dependable way
>> things work now?
>>
>> Three paths come to mind.
>>
>> A. Remove the Java dependencies.
>>
>> B. Adjust the Java dependencies,
>> 1. So that the dependencies are clear and the situation around
>> failures to find a suitable JRE is made workable for casual users. This
>> could involve the above (2-4) remedies.
>> 2. Only then consider increasing the dependencies on Java for
>> full-function operation in some controllable way.
>>
>> C. Make AOO a Java application that has C++ components, rather than the
>> reverse.
>>
>> These are all serious. Probably on the way to either A or C, one must
>> address B.
>>
>> We also need to consider what the project's capacity for any of these
>> cases happens to be.
>>
>> Thoughts?
>>
>> - Dennis
>>
>> PS: There is a bigger question about platform presence in here. There are
>> distributions for which Java dependency is not particularly attractive and
>> we may be cutting ourselves off from those. That might not matter if we
>> are talking about the small percentage of the downloads that are for
>> neither Windows nor Macintosh desktop PCs.
>>
>>
>>
>>> -----Original Message-----
>>> From: Pedro Giffuni [mailto:pfg@apache.org]
>>> Sent: Thursday, October 29, 2015 08:07
>>> To: Apache OO <de...@openoffice.apache.org>
>>> Subject: Re: Thinking of joining OpenOffice as a developer
>>>
>>> Hello;
>>>
>>> First of all, a warm welcome to Patricia. Java developers are
>>> particularly welcome at this stage!
>>>
>>> Just IMHO, the C++ side of AOO is either under-control or
>>> too-ugly-to care-about, so we would do good focus more on the
>>> Java parts, which are also somewhat ugly but still promising.
>> [ ... ]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
--
Greg Bullock
NorthWest Research Associates
301 Webster St.
Monterey, CA 93940
(831) 582-4907
greg@nwra.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Simon Phipps <si...@webmink.com>.
One more factor to consider is that the official Java installer promoted by
Oracle tries really hard to trick the end-user into installing
adware/spyware at the same time. We used to avoid this in the Sun installer
by bundling Java, but having it as an external dependency for new AOO users
means they face the challenge not only of finding and installing Java but
avoiding the malware as they do so.
I'd say this was a really big negative for a dependency on official Java.
It's not a problem on Linux where there is usually an OpenJDK bundle
available, but it's a huge negative on Windows.
S.
On Thu, Oct 29, 2015 at 5:44 PM, Dennis E. Hamilton <or...@apache.org>
wrote:
> The Java dependency problem keeps coming up buried in other threads. I am
> redirecting the most recent case so we can put light on this situation.
>
> Before the dependencies on Java are increased/improved, I think there is a
> crucial usability matter.
>
> 1. Currently users are trap-doored by exercising a feature or dialog that
> suddenly raises a Java dependency, sometimes for which there is no escape
> other than finding a way to shut down AOO that is not a normally-required
> skill.
>
> 2. The fact that full functioning of AOO is buried in the system
> requirements in a way that users can easily overlook (or never examine) is
> a problem. We can fix that page, even providing (or linking to) specific
> details of what the dependencies are. That would be useful so developers
> and power-users have the details. However, the system requirements are
> probably not read by most who download the software (based on over 40
> million downloads of 4.1.1, overwhelmingly on systems designed for casual
> users).
>
> 3. If the installer required presence of Java, that would be a clear
> indication that it is required for operation. It would also be helpful if
> the installer provided an usable link for installing a workable Java if one
> is not present.
>
> 4. If the presence of Java is indeed optional, and the user does not have
> it or elects not to use it, AOO should not even offer functions for which
> Java is required. That is another way to improve the usability and at
> least avoid users falling through trap-doors.
>
> 5. Shouldn't we do this better? Or are we to decree that AOO is only
> intended for power-users who have strong skills with regard to managing
> their configurations, managing the install of dependencies,
> trouble-shooting and being able to work around the not-dependable way
> things work now?
>
> Three paths come to mind.
>
> A. Remove the Java dependencies.
>
> B. Adjust the Java dependencies,
> 1. So that the dependencies are clear and the situation around
> failures to find a suitable JRE is made workable for casual users. This
> could involve the above (2-4) remedies.
> 2. Only then consider increasing the dependencies on Java for
> full-function operation in some controllable way.
>
> C. Make AOO a Java application that has C++ components, rather than the
> reverse.
>
> These are all serious. Probably on the way to either A or C, one must
> address B.
>
> We also need to consider what the project's capacity for any of these
> cases happens to be.
>
> Thoughts?
>
> - Dennis
>
> PS: There is a bigger question about platform presence in here. There are
> distributions for which Java dependency is not particularly attractive and
> we may be cutting ourselves off from those. That might not matter if we
> are talking about the small percentage of the downloads that are for
> neither Windows nor Macintosh desktop PCs.
>
>
>
> > -----Original Message-----
> > From: Pedro Giffuni [mailto:pfg@apache.org]
> > Sent: Thursday, October 29, 2015 08:07
> > To: Apache OO <de...@openoffice.apache.org>
> > Subject: Re: Thinking of joining OpenOffice as a developer
> >
> > Hello;
> >
> > First of all, a warm welcome to Patricia. Java developers are
> > particularly welcome at this stage!
> >
> > Just IMHO, the C++ side of AOO is either under-control or
> > too-ugly-to care-about, so we would do good focus more on the
> > Java parts, which are also somewhat ugly but still promising.
> [ ... ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
*Simon Phipps* http://webmink.com
*Office:* +1 (415) 683-7660 *or* +44 (238) 098 7027
*Mobile*: +44 774 776 2816 *or Telegram <https://telegram.me/webmink>*
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Damjan Jovanovic <da...@apache.org>.
On Thu, Oct 29, 2015 at 11:22 PM, Patricia Shanahan <pa...@acm.org> wrote:
> On 10/29/2015 12:20 PM, Damjan Jovanovic wrote:
>
>> On Thu, Oct 29, 2015 at 7:44 PM, Dennis E. Hamilton <or...@apache.org>
>> wrote:
>>
> ...
>
>> Three paths come to mind.
>>>
>>> A. Remove the Java dependencies.
>>>
>>>
>> Impossible. JDBC drivers for example, are the lifeblood of Base.
>>
>>
> It depends on what you mean by "Impossible". For example, the existence of
> the JDBC drivers proves that it is possible to implement interfaces with
> all the capabilities of JDBC without depending on it. On the other hand, it
> may be impossible to implement the JDBC features Base needs in a reasonable
> time with the available resources.
>
>
We don't develop JDBC drivers, third parties do. This means we don't even
always have source code for JDBC drivers available to port to something
else like SDBC or ODBC. Our default database type is HSQLDB, for which only
the JDBC driver supports all the features - the ODBC driver for it is only
alpha status, only for version 2.x (we use 1.8), and it doesn't support
database metadata (which I am pretty sure Base needs).
> My questions are:
>
> 1. What is the cleanest, lowest risk, way to get from here (Java
> dependent) to there (Java independent) in each area?
>
> 2. How much work would it be?
>
> 3. Does AOO have that much development effort available, and if so is it
> the best use of that effort?
>
> If we continue with optional Java, I hope making it more convenient and
> unobtrusive for users, it is not an all-or-nothing situation. Each
Absolutely.
> feature that is converted is another feature for non-Java users.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Kay Schenk <ka...@gmail.com>.
On 10/29/2015 02:22 PM, Patricia Shanahan wrote:
> On 10/29/2015 12:20 PM, Damjan Jovanovic wrote:
>> On Thu, Oct 29, 2015 at 7:44 PM, Dennis E. Hamilton
>> <or...@apache.org>
>> wrote:
> ...
>>> Three paths come to mind.
>>>
>>> A. Remove the Java dependencies.
>>>
>>
>> Impossible. JDBC drivers for example, are the lifeblood of Base.
>>
>
> It depends on what you mean by "Impossible". For example, the
> existence of the JDBC drivers proves that it is possible to
> implement interfaces with all the capabilities of JDBC without
> depending on it. On the other hand, it may be impossible to
> implement the JDBC features Base needs in a reasonable time with the
> available resources.
>
> My questions are:
>
> 1. What is the cleanest, lowest risk, way to get from here (Java
> dependent) to there (Java independent) in each area?
>
> 2. How much work would it be?
>
> 3. Does AOO have that much development effort available, and if so
> is it the best use of that effort?
All great questions! ...with no answers right at the moment.
It would be great if someone could research this...really! I imagine
all manners of interfaces have come a long way since the initial
decision to use Java in some parts of the OpenOffice code.
>
> If we continue with optional Java, I hope making it more convenient
> and unobtrusive for users, it is not an all-or-nothing situation.
> Each feature that is converted is another feature for non-Java users.
Absolutely! I've stayed out of the "which" or "why" Java discussion
so far. At this point, to me it *might* be a requirement we could do
without, or, as Damjan suggested, it might be great to use more of
it. Right now, without further research, I'm not convinced either way.
--
--------------------------------------------
MzK
“The journey of a thousand miles begins
with a single step.”
--Lao Tzu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Patricia Shanahan <pa...@acm.org>.
On 10/29/2015 12:20 PM, Damjan Jovanovic wrote:
> On Thu, Oct 29, 2015 at 7:44 PM, Dennis E. Hamilton <or...@apache.org>
> wrote:
...
>> Three paths come to mind.
>>
>> A. Remove the Java dependencies.
>>
>
> Impossible. JDBC drivers for example, are the lifeblood of Base.
>
It depends on what you mean by "Impossible". For example, the existence
of the JDBC drivers proves that it is possible to implement interfaces
with all the capabilities of JDBC without depending on it. On the other
hand, it may be impossible to implement the JDBC features Base needs in
a reasonable time with the available resources.
My questions are:
1. What is the cleanest, lowest risk, way to get from here (Java
dependent) to there (Java independent) in each area?
2. How much work would it be?
3. Does AOO have that much development effort available, and if so is it
the best use of that effort?
If we continue with optional Java, I hope making it more convenient and
unobtrusive for users, it is not an all-or-nothing situation. Each
feature that is converted is another feature for non-Java users.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by toki <to...@gmail.com>.
On 10/29/2015 07:20 PM, Damjan Jovanovic wrote:
>> Three paths come to mind.
>> A. Remove the Java dependencies.
> Impossible. JDBC drivers for example, are the lifeblood of Base.
FWIW, the hardest, to the point of being impossible to replace, is the
stuff that a11y tools rely on.
jonathon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Damjan Jovanovic <da...@apache.org>.
On Thu, Oct 29, 2015 at 7:44 PM, Dennis E. Hamilton <or...@apache.org>
wrote:
> The Java dependency problem keeps coming up buried in other threads. I am
> redirecting the most recent case so we can put light on this situation.
>
> Before the dependencies on Java are increased/improved, I think there is a
> crucial usability matter.
>
> 1. Currently users are trap-doored by exercising a feature or dialog that
> suddenly raises a Java dependency, sometimes for which there is no escape
> other than finding a way to shut down AOO that is not a normally-required
> skill.
>
Any dialogs that require AOO shutdown are a serious problem, and should be
fixed regardless of what we decide with Java.
> 2. The fact that full functioning of AOO is buried in the system
> requirements in a way that users can easily overlook (or never examine) is
> a problem. We can fix that page, even providing (or linking to) specific
> details of what the dependencies are. That would be useful so developers
> and power-users have the details. However, the system requirements are
> probably not read by most who download the software (based on over 40
> million downloads of 4.1.1, overwhelmingly on systems designed for casual
> users).
>
> 3. If the installer required presence of Java, that would be a clear
> indication that it is required for operation. It would also be helpful if
> the installer provided an usable link for installing a workable Java if one
> is not present.
>
> 4. If the presence of Java is indeed optional, and the user does not have
> it or elects not to use it, AOO should not even offer functions for which
> Java is required. That is another way to improve the usability and at
> least avoid users falling through trap-doors.
>
> 5. Shouldn't we do this better? Or are we to decree that AOO is only
> intended for power-users who have strong skills with regard to managing
> their configurations, managing the install of dependencies,
> trouble-shooting and being able to work around the not-dependable way
> things work now?
>
> Three paths come to mind.
>
> A. Remove the Java dependencies.
>
Impossible. JDBC drivers for example, are the lifeblood of Base.
> B. Adjust the Java dependencies,
> 1. So that the dependencies are clear and the situation around
> failures to find a suitable JRE is made workable for casual users. This
> could involve the above (2-4) remedies.
> 2. Only then consider increasing the dependencies on Java for
> full-function operation in some controllable way.
>
A good step in that direction would be Win64 builds (what's needed for
those?), and helping users download AOO of the correct bitness.
> C. Make AOO a Java application that has C++ components, rather than the
> reverse.
>
>
We could also:
D. Bundle an internal JRE with AOO that is known ahead of time to work.
This could be an OpenJDK JRE that we build, without spyware. I know we
can't distribute copyleft licensed software with AOO, but we could offer to
download and install it during installation or on first start.
> These are all serious. Probably on the way to either A or C, one must
> address B.
>
> We also need to consider what the project's capacity for any of these
> cases happens to be.
>
> Thoughts?
>
> - Dennis
>
> PS: There is a bigger question about platform presence in here. There are
> distributions for which Java dependency is not particularly attractive and
> we may be cutting ourselves off from those. That might not matter if we
> are talking about the small percentage of the downloads that are for
> neither Windows nor Macintosh desktop PCs.
>
>
LibreOffice uses Java on those distributions too.
>
>
> > -----Original Message-----
> > From: Pedro Giffuni [mailto:pfg@apache.org]
> > Sent: Thursday, October 29, 2015 08:07
> > To: Apache OO <de...@openoffice.apache.org>
> > Subject: Re: Thinking of joining OpenOffice as a developer
> >
> > Hello;
> >
> > First of all, a warm welcome to Patricia. Java developers are
> > particularly welcome at this stage!
> >
> > Just IMHO, the C++ side of AOO is either under-control or
> > too-ugly-to care-about, so we would do good focus more on the
> > Java parts, which are also somewhat ugly but still promising.
> [ ... ]
>
>
Damjan
Re: [QUESTION] Usability of Non-Optional Java Dependencies
Posted by Patricia Shanahan <pa...@acm.org>.
For AOO to achieve its full potential it must be possible to use it
while assuming "Java" refers to an island one of whose exports is coffee
beans.
However, in normal home and office environments, the people doing
installation are often more technically knowledgeable, and more likely
to RTFM if they hit a problem, than the end users. For example, many of
my friends know someone who is good at installing software who they ask
for help. Small offices may bring in a support service. Larger
businesses have a department that keeps office workstations up to date.
A reasonable first step would be to ensure that when the installation
finishes successfully AOO is ready for use by any end user with minimal
keyboard and office skills.
On 10/29/2015 10:44 AM, Dennis E. Hamilton wrote:
> The Java dependency problem keeps coming up buried in other threads.
> I am redirecting the most recent case so we can put light on this
> situation.
>
> Before the dependencies on Java are increased/improved, I think there
> is a crucial usability matter.
>
> 1. Currently users are trap-doored by exercising a feature or dialog
> that suddenly raises a Java dependency, sometimes for which there is
> no escape other than finding a way to shut down AOO that is not a
> normally-required skill.
>
> 2. The fact that full functioning of AOO is buried in the system
> requirements in a way that users can easily overlook (or never
> examine) is a problem. We can fix that page, even providing (or
> linking to) specific details of what the dependencies are. That would
> be useful so developers and power-users have the details. However,
> the system requirements are probably not read by most who download
> the software (based on over 40 million downloads of 4.1.1,
> overwhelmingly on systems designed for casual users).
>
> 3. If the installer required presence of Java, that would be a clear
> indication that it is required for operation. It would also be
> helpful if the installer provided an usable link for installing a
> workable Java if one is not present.
>
> 4. If the presence of Java is indeed optional, and the user does not
> have it or elects not to use it, AOO should not even offer functions
> for which Java is required. That is another way to improve the
> usability and at least avoid users falling through trap-doors.
>
> 5. Shouldn't we do this better? Or are we to decree that AOO is only
> intended for power-users who have strong skills with regard to
> managing their configurations, managing the install of dependencies,
> trouble-shooting and being able to work around the not-dependable way
> things work now?
>
> Three paths come to mind.
>
> A. Remove the Java dependencies.
>
> B. Adjust the Java dependencies, 1. So that the dependencies are
> clear and the situation around failures to find a suitable JRE is
> made workable for casual users. This could involve the above (2-4)
> remedies. 2. Only then consider increasing the dependencies on Java
> for full-function operation in some controllable way.
>
> C. Make AOO a Java application that has C++ components, rather than
> the reverse.
>
> These are all serious. Probably on the way to either A or C, one
> must address B.
>
> We also need to consider what the project's capacity for any of these
> cases happens to be.
>
> Thoughts?
>
> - Dennis
>
> PS: There is a bigger question about platform presence in here.
> There are distributions for which Java dependency is not particularly
> attractive and we may be cutting ourselves off from those. That
> might not matter if we are talking about the small percentage of the
> downloads that are for neither Windows nor Macintosh desktop PCs.
>
>
>
>> -----Original Message----- From: Pedro Giffuni
>> [mailto:pfg@apache.org] Sent: Thursday, October 29, 2015 08:07 To:
>> Apache OO <de...@openoffice.apache.org> Subject: Re: Thinking of
>> joining OpenOffice as a developer
>>
>> Hello;
>>
>> First of all, a warm welcome to Patricia. Java developers are
>> particularly welcome at this stage!
>>
>> Just IMHO, the C++ side of AOO is either under-control or
>> too-ugly-to care-about, so we would do good focus more on the Java
>> parts, which are also somewhat ugly but still promising.
> [ ... ]
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org