Apache OpenOffice (AOO) Bugzilla – Issue 128508
Installing the correct 64 bit version of java runtime onto Windows 10 64 renders Base unable to connect to a database.
Last modified: 2022-10-28 12:40:23 UTC
Installing the correct 64 bit version of java runtime onto Windows 10 64 renders Base unable to connect to a database. In my present case, that's MySQL (installed by mysql-installer-community-8.0.29.0.msi), but because Base requires 32 bit java runtime to connect, I expect the same problem would probably exist for ALL databases. Base depends on the 32 JRE, but the latest 32 bit JRE, by Oracle (installed by jre-8u333-windows-i586.exe), deletes the latest 64 bit Java JDK runtime engine (installed by jdk-18_windows-x64_bin.msi), which comes with the 64 bit JDK. As a result, installing Base, and the 32 bit JRE it demands, breaks java development tools on the host system... specifically tools such as Netbeans and its database connectivity, which require the 64 bit JDK java runtime engine to function. The inverse is also true. Installing the latest 64 bit JDK onto Windows 10 64 pro AFTER installing Apache Openoffice Base also breaks Openoffice Base's capacity to connect to a MySQL database, because the 64 bit JDK removes the 32 bit JRE required by base, to connect to a database (such as MySQL, in this case). The 64 bit Windows 10 64 pro JDK installer does not present the option to let the existing JRE remain on the system. It doesn't ask, and it always clobbers it. The 32 bit Windows JRE installer offers the option not to delete the existing java runtime engine, but it does delete it, regardless, even if you select the 32 bit installer's option to leave the existing runtime engine on the system... This means Base, which DEMANDS a 32 bit JRE installation to connect to a database, can not coexist on a Windows 64 bit development machine which uses programs like Netbeans... because these tools require the 64 bit version of java. Furthermore, even a standard 64 bit JRE would probably also break Base, by the very same token. The java runtime engines simply don't leave each other be. Bear in mind, 64 bit java is EXPECTED for 64 bit Windows operating systems. For that reason, I hate to say it, but Base is essentially "broken" for 64 bit Windows, unless the user simply desires base so much that they are willing to break everything else java-related, on the whole computer, just to make base work. I believe it is time that Open Office for Windows start including a 64 bit installer, and that installer should accept 64 bit java runtime, instead of depending on legacy 32 bit java runtime. I believe that would fix these problems right up. Thanks for reading. PS: Please understand that I am not prepared to dig into various installation tests, to follow this up. Installation tests would destabilizes my current development environment (Netbeans+JDK+MySQL-database), which took days to prepare. Sorry about that, but that's how it has to be.
Nothing we can do about the Oracle installer... But why not try one of the other excellent Java runtimes available? E.g.: https://adoptopenjdk.net/
(In reply to Matthias Seidel from comment #1) > Nothing we can do about the Oracle installer... > > But why not try one of the other excellent Java runtimes available? > > E.g.: https://adoptopenjdk.net/ I was under the impression that Oracle's implementation is the gold standard, in light of their acquisition of Sun's implementation... no? And... sorry, but wouldn't it be best to move forward to a 64 bit version, regardless?
So what is this "bug" about?! If you really want a 64bit version of AOO you are welcome to help the project like all the other volunteers. But maybe it would be better to open a bug at Oracle?
(In reply to Matthias Seidel from comment #3) > So what is this "bug" about?! > > > But maybe it would be better to open a bug at Oracle? I already submitted it to them, first. I'm simply figuring that it is best that Open Office also know about it, and adapt as they see fit. > If you really want a 64bit version of AOO you are welcome to help the > project like all the other volunteers. Sure, and maybe one day I will. :) I just figure there is someone on the team who's already deeply intimate with the related code, and build process... while it would take me a long time, and lots of pesky questions, to get to that level.
(In reply to Matthias Seidel from comment #3) > So what is this "bug" about?! > Basically, the "bug" is that the current system requirements of Base push the user to use a 32 bit version of java, which is ill advised, because most other things on the system will want the 64 bit version. I recall it used to be pretty easy to have many different installations of java, and to edit classpath/etc to pick one for runtime, but Oracle seems to have made that hard to do. Maybe I could trick their installer, by renaming the java_home directory, while running the new installer, but that is a bit of a hack. I'd be willing to try it, but ofc I prefer a more elegant solution.
(In reply to Matthias Seidel from comment #3) > If you really want a 64bit version of AOO you are welcome to help the > project like all the other volunteers. Also, I'm helping the project by reporting it, as well. SQA is still a valid level of support. I've worked on both sides of that fence. :)
We really need the Win64 port https://wiki.openoffice.org/wiki/Win64_port
(In reply to Sam Jennings from comment #5) > (In reply to Matthias Seidel from comment #3) > > So what is this "bug" about?! > > > I recall it used to be pretty easy to have many different installations of > java, and to edit classpath/etc to pick one for runtime, but Oracle seems to > have made that hard to do. Maybe I could trick their installer, by renaming > the java_home directory, while running the new installer, but that is a bit > of a hack. I'd be willing to try it, but ofc I prefer a more elegant > solution. I don't think there is a need to edit the classpath, just install the 32bit version of e.g. AdoptOpenJDK 8 and point AOO to it.
(In reply to Matthias Seidel from comment #8) > (In reply to Sam Jennings from comment #5) > > (In reply to Matthias Seidel from comment #3) > > > So what is this "bug" about?! > > > > > I recall it used to be pretty easy to have many different installations of > > java, and to edit classpath/etc to pick one for runtime, but Oracle seems to > > have made that hard to do. Maybe I could trick their installer, by renaming > > the java_home directory, while running the new installer, but that is a bit > > of a hack. I'd be willing to try it, but ofc I prefer a more elegant > > solution. > > I don't think there is a need to edit the classpath, just install the 32bit > version of e.g. AdoptOpenJDK 8 and point AOO to it. I've never used this implementation of java, before... nor even heard of it. Have you? You vouch for it? And which JVM would you pick with that download? HotSpot or OpenJ9? Have you used one of them, before? I feel leery and protective of my development / etc machine... no offense. Oracle has standing... Openoffice is established... but this other org is unknown to me... which makes me feel almost as uncomfortable as downloading something from one of those drivers updater websites. lol
As it is OpenJDK it is based on exactly the same code as Oracle Java. In fact Adoptium OpenJDK is what I use to build my AOO Test builds with. https://adoptium.net/de/temurin/releases/ (This is their new location at the Eclipse Foundation, i posted an old link before) Just give it a try. You can always decide which JRE AOO should use. Personally, I have Oracle Java 7 and 8 as well as Adoptium OpenJDK 8 and 11 installed and use them for testing. My hope is that Adoptium (32-bit) and Oracle Java (64-bit) will not interfere.
(In reply to Sam Jennings from comment #9) > I've never used this implementation of java, before... nor even heard of it. > Have you? > You vouch for it? And which JVM would you pick with that download? > HotSpot or OpenJ9? Have you used one of them, before? I feel leery and > protective of my development / etc machine... no offense. Oracle has > standing... Openoffice is established... but this other org is unknown to > me... which makes me feel almost as uncomfortable as downloading something > from one of those drivers updater websites. lol AdoptOpenJDK goes back many years and is pretty well established. We officially added support for it in bug 128157, back in 2019, first released in version 4.1.7.
(In reply to Sam Jennings from comment #0) > Base depends on the 32 JRE, but the latest 32 bit JRE, by Oracle (installed > by jre-8u333-windows-i586.exe), deletes the latest 64 bit Java JDK runtime > engine > <snip> > The inverse is also true. JRE is not part of AOO core. So please report directly this issue to Oracle.
(In reply to oooforum (fr) from comment #12) > (In reply to Sam Jennings from comment #0) > > Base depends on the 32 JRE, but the latest 32 bit JRE, by Oracle (installed > > by jre-8u333-windows-i586.exe), deletes the latest 64 bit Java JDK runtime > > engine > > <snip> > > The inverse is also true. > JRE is not part of AOO core. > So please report directly this issue to Oracle. I did report it to Oracle, as I mentioned above. Meanwhile, Open Office still has the issue, and closing the bug, here, would amount to a 32 bit cop out. Admit it: Open Office requires a 64 bit migration for windows, regardless, just to remain current... and this particular development is arguably the first of many kicks in the compatibility pants that it will get, and keep getting, until it does. So it is better to take the 64 bit challenge, sooner, instead of putting it even further off, waiting to see how many other things start to break, first. That being said, I must disagree with the new status, for this bug. The issue might come from Oracle, but it also comes from a conscious decision (whether forced by manpower availability, or not) about OO... OO will need to move forward to 64 bit, either way, and this issue is a symptom of failure to do so.
(In reply to Sam Jennings from comment #13) >Open Office requires a 64 bit migration for windows, See https://wiki.openoffice.org/wiki/Win64_port If you have skills in C++ you can help too
@Sam Jennings: I have a Java 1.8.0_12 in "Program files (x86)" which is used by AOO and a Java 9.0.1 in "Program files", which is used by LO.
(In reply to oooforum (fr) from comment #14) > (In reply to Sam Jennings from comment #13) > >Open Office requires a 64 bit migration for windows, > See https://wiki.openoffice.org/wiki/Win64_port > If you have skills in C++ you can help too I wrote some interesting C/C++, but I can't say I was ever a C++ "guru" in those languages. I worked in them for maybe a year or less, on primarily self guided projects... and that was a couple decades ago. Very rusty... I'm also mired in a java framework / database / application server project restoration. My hard drive crashed, 2 years ago, and I've recently been laboring to restore the codebase, recombine it, and migrate it forward from java 5... That codebase includes my implementation of an application server / database framework / client-server framework, and some functioning projects which used them in those roles... I want to get my home brew application server back online, and database code working again. That port is like maybe 1/10 - 1-8 of the way done. It is like a life priority for me to see that through. When I have that online, I also need to make sure all the web applications that I developed on it can run, again... and also want to make a new subclass of this database application, to import from jOpenDocument files, with stock data, and crunch numbers, fast, to pick good stocks. I suspect all that will take me anywhere from 2 weeks to 2 months. I might shift gears, and put the stock picking program before the other parts... but it is best to upgrade the application server / database app framework first, so that the stock picker program can use the new, improved database application superclass, rather than entrench less object oriented "quick and dirty trash code" that doesn't use them, and is not as reusable. So I won't say I "couldn't", but I know there are much better people for it, who are current in C++, and I can't afford to change my immediate priorities, at this time, either. I'm in full project mode, at the moment. I can't fly with the 64 bit CPP owl coders at night, and soar with my java / mysql database / application server / jOD eagles in the morning. lol
Currently the Windows 64 bit version is stuck with the Assembler code that needs transformation. We are not exactly sure what needs to be done.