On Thu, Oct 29, 2015 at 7:44 PM, Dennis E. Hamilton <orc...@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:p...@apache.org] > > Sent: Thursday, October 29, 2015 08:07 > > To: Apache OO <dev@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
