Page 1 of 1

OpenOffice on JVM platform

Posted: Thu Apr 15, 2021 2:36 pm
by EvanaShankar
I would like to know that is it possible to switch current OpenOffice suit to pure JVM platform and do the OpenOffice development in any language that JVM supports like Java, Jython, Scala, Groovy etc. Apache Software Foundation can ship a platform native JRE with OpenOffice suit to make OpenOffice feel and behave like any other native applications. Switching to JVM will have some benefits like there will be only one release for every platform, current operating systems like Windows and Linux are supporting multiple processor architectures(x86-64, ARM64). OpenOffice suit will be more robust as there will be almost no memory leaks and developers who are working on OpenOffice project will be able to choose any language that JVM support which means that more developers will be able to contribute to OpenOffice project. Migration to the JVM platform might not be easy but I think that Apache Software Foundation should seriously consider this because of several benefits. Also OpenOffice should be more cloud friendly supporting multiple major cloud drive solutions like Google Drive, Dropbox, OneDrive etc.

Re: OpenOffice on JVM platform

Posted: Thu Apr 15, 2021 4:58 pm
by Villeroy
OpenOffice is (was) a typical desktop application from the 90ies written in C++. Meanwhile OpenOffice has become a zombie project. In 2011 https://libreoffice.org/ was forked from OpenOffice. The vast majority of developers switched over to LibreOffice. OpenOffice does not even have a 64-bit version for MS WIndows so I doubt that anybody is able to manage another port.

https://www.libreoffice.org/discover/li ... penoffice/
https://www.libreoffice.org/download/li ... ce-online/
and it provides a file picker dialog for various cloud drives.

This forum is the most active part of the project still well known as "OpenOffice". It is a user forum. The remaining OpenOffice developers ignore it completely.

Re: OpenOffice on JVM platform

Posted: Sat Apr 24, 2021 1:25 pm
by sveld
To add to that: this approach has been tried in the past and most projects I've seen -miserably- failed, it's (generally) just is not going to work. There are too many side cases, exceptions, and there are always platform specifics that need to be adressed, not in the last place cause users expect the app to look and respond like a platform native application. Then you need integrations with the platform and other apps there and on mobile think runtimes are a no-go. The amount of work, guess you need a few hundred dev's and a decade of spare time to get done where OO/LO is today. The LibreOffice team spend the first few years after the fork just cleaning up the largest part of the mess still in OpenOffice code today and getting the code in shape to build new stuff on. Philosophy: It's easier to make the code better then to rewrite all, as new mistakes are going to be there for sure. Also dev's can't change the language they are used to overnight, that would mean a new dev team, and in the end just another document editor. If something does not work the way you like most of the time it isn't the best idea to create another project with the similar result, you'll end up with two half solutions and it's a wast of resources.