64-bit AOO for Windows (was RE: [QUESTION] Usability of Non-Optional Java Dependencies)

[Dennis E. Hamilton]

I think the benefits of an x64 version of OpenOffice are understated.  It has 
apparently been worth it for a cousin OO.o descendant to provide one.  

I think there are two factors that favor having an OpenOffice x64 release:

 1. The biggest benefits of x64 builds are (1) optimized compiling for a more 
modern, high-performance instruction set and any multi-threading advantages 
that arise, and (2) ability to gain the benefits of much more RAM beyond the 
3GB limit that applied under x86, reducing swapping and providing far greater 
input-output buffering.  I suspect (2) is the most noticeable, especially with 
large Calc files but maybe large documents too, although improved graphic 
hardware and software may matter more than we might thing.  There is also a 
benefit in using later Microsoft tooling at the same time, achieving possible 
entry into the Windows Store and using modern installer practices.

 2. I have seen justification of staying with x86 based on the fact that 
Microsoft recommends that Microsoft Office x86 still be used in preference over 
the x64 release to assure maximum compatibility with *existing* plug-ins and 
extensions.  I wonder if this is a red herring.  I have to assume that, since 
OpenOffice on Linux (including MacOS?) must match the bitness of those systems, 
that there has been no terrible difficulty around extensions and plug-ins being 
available/usable between x86 and x64 for those OpenOffice adopters.  Is that 
mistaken?

I also think that OpenOffice was limited in the past because there was no 
freely-available building of x64 applications with free versions of Visual 
Studio (i.e., the earliest Express editions and SDKs).  As far as I can tell, 
one can now produce x64 builds with current versions, including the free Visual 
Studio Community Edition.  Those editions don't produce x86 code for Windows XP 
very easily, but x64 is irrelevant for XP.  That might mean a different build 
for XP until one can retire XP support at some future feature release of AOO.  

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Monday, November 2, 2015 14:14
> To: dev@openoffice.apache.org
> Subject: Re: [QUESTION] Usability of Non-Optional Java Dependencies
> 
> 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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Andreas Säger]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Andrea Pescetti]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Kay Schenk]

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
>> 
>> 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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Patricia Shanahan]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: [QUESTION] Usability of Non-Optional Java Dependencies

[Dennis E. Hamilton]

Damjan,

Thanks for the great summary of the situation, below.  I have a few supporting 
comments there.
> -Original Message-
> From: Damjan Jovanovic [mailto:dam...@apache.org]
> Sent: Sunday, November 1, 2015 09:22
> To: Apache OO <dev@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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Damjan Jovanovic]

On Fri, Oct 30, 2015 at 4:14 PM, C Säger  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
> saege...@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 

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Pedro Giffuni]

Just to note some things related to a Win64 port:

- In order to support win64 builds we would have to add a win64 bridge which we 
currently don’t have. The process is similar to porting to a new architecture: 
mail archives should have a message from Tor Lillquist who did the LibreOffice 
port and had a blog post about it.
- It would also be convenient to upgrade the MSVC version we are using. 
- As a side effect, most or even all extensions would have to be recompiled.

Since about 80% of our users depend on Microsoft Windows, and 32 bit hardware 
is not exactly easy to find anymore, we would think that a win64 port is 
essential but the truth is up to MS-Office 2013, Microsoft was recommending 
people should use 32 bit versions of their office suite for compatibility 
issues.
We should work on it, but for now I think the priority should updating MSVC as 
a step for that goal. Not sure up to which point we may be able to update it 
without getting into trouble for some dependencies.

For now, perhaps we should point people to the openjdk unofficial builds:
https://github.com/alexkasko/openjdk-unofficial-builds 


Cheers,

Pedro.

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Damjan Jovanovic]

On Sun, Nov 1, 2015 at 7:47 PM, Dennis E. Hamilton <orc...@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:dam...@apache.org]
> > Sent: Sunday, November 1, 2015 09:22
> > To: Apache OO <dev@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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Damjan Jovanovic]

On Mon, Nov 2, 2015 at 2:34 AM, Pedro Giffuni  wrote:

> Just to note some things related to a Win64 port:
>
> - In order to support win64 builds we would have to add a win64 bridge
> which we currently don’t have. The process is similar to porting to a new
> architecture: mail archives should have a message from Tor Lillquist who
> did the LibreOffice port and had a blog post about it.
> - It would also be convenient to upgrade the MSVC version we are using.
> - As a side effect, most or even all extensions would have to be
> recompiled.
>
> Since about 80% of our users depend on Microsoft Windows, and 32 bit
> hardware is not exactly easy to find anymore, we would think that a win64
> port is essential but the truth is up to MS-Office 2013, Microsoft was
> recommending people should use 32 bit versions of their office suite for
> compatibility issues.
> We should work on it, but for now I think the priority should updating
> MSVC as a step for that goal. Not sure up to which point we may be able to
> update it without getting into trouble for some dependencies.
>
> For now, perhaps we should point people to the openjdk unofficial builds:
> https://github.com/alexkasko/openjdk-unofficial-builds <
> https://github.com/alexkasko/openjdk-unofficial-builds>
>
> Cheers,
>
> Pedro.
>
>
>
>

Oh, I didn't realize AOO still needs porting to Win64. The irony is, we'd
be porting to Win64 to interoperate with Java better, yet the entire port
would be wasted effort if or when we port AOO to Java.

I love those unofficial OpenJDK builds ;-). Do they auto-update?

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Damjan Jovanovic]

On Thu, Oct 29, 2015 at 11: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 
>> 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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Rory O'Farrell]

On Thu, 29 Oct 2015 10:44:52 -0700
"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.

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:p...@apache.org]
> > Sent: Thursday, October 29, 2015 08:07
> > To: Apache OO 
> > 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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 
> 


-- 
Rory O'Farrell 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Simon Phipps]

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 
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:p...@apache.org]
> > Sent: Thursday, October 29, 2015 08:07
> > To: Apache OO 
> > 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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@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 *

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Greg Bullock]

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 
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:p...@apache.org]
Sent: Thursday, October 29, 2015 08:07
To: Apache OO 
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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org






--
Greg Bullock
NorthWest Research Associates
301 Webster St.
Monterey, CA  93940
(831) 582-4907
g...@nwra.com

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Patricia Shanahan]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Patricia Shanahan]

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 
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:p...@apache.org]
Sent: Thursday, October 29, 2015 08:07
To: Apache OO 
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.

[ ... ]

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Patricia Shanahan]

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:p...@apache.org] Sent: Thursday, October 29, 2015 08:07 To:
Apache OO  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-unsubscr...@openoffice.apache.org

For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Damjan Jovanovic]

On Thu, Oct 29, 2015 at 7:44 PM, 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.
>

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:p...@apache.org]
> > Sent: Thursday, October 29, 2015 08:07
> > To: Apache OO 
> > 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

[Patricia Shanahan]

On 10/29/2015 12:20 PM, Damjan Jovanovic wrote:

On Thu, Oct 29, 2015 at 7:44 PM, Dennis E. Hamilton 
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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[toki]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Patricia Shanahan]

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 
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:p...@apache.org]
Sent: Thursday, October 29, 2015 08:07
To: Apache OO 
Subject: Re: 

Re: [QUESTION] Usability of Non-Optional Java Dependencies

[Greg Bullock]

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  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 
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