![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
I have been using various versions of LO for some time now and have just
upgraded from V4.0.4 to V4.1.
All seems OK apart from base which does not find Java Runtime SE 7u25;
however it is shown OK in the advanced Options - LibreOffice - Advanced
setting as "Oracle Corporation 1.7.0_25".
Is this a bug or is there a workaround?
Using Win7 64bit
Hi Rogman
I think I can help you with this. LO is currently a 32bit app set, that you, like me, are running on a 64bit O/S. No issue with this as Windows 7 64bit know hows to work with both 32bit and 64bit apps, hence the two "Program Files" (64bit default app store) and "Program files (x86)" (32bit default app store).
So with that bit of tech-ed above out of the way, what this means is it looks like you have only installed the 64bit version of JRE (Java Runtime Edition). LO Base cannot see or use it, hence it showing up in the settings but Base not able to use it. My advice is install both the 32bit version and 64 bit version of JRE 1.7.0_27, problem solved. LO will sort out which version to use as each app is run.
As a matter of interest for Linux users, this behaviour is the same with 64bit version as well, so the advice can be applied the same way.
Regards
Why install a 64 bit version of Java if you don't need it?
Just install the 32 bit version...
Hi 
My guess is that the default is 64bit or else other apps might need the 64bit version. It's generally not a good idea to have more than 1 version of Java although even 1 might well be more than you need now.
Accessibility and Base (using the internal back-end) still need it. Fewer and fewer wizards and extensions need it.
Regards from
Tom
Tom Davies wrote:
My guess is that the default is 64bit or else other apps might need the 64bit version. It's generally not a good idea to have more than 1 version of Java although even 1 might well be more than you need now.
The big question is why are the Windows version of LibreOffice and OpenOffice still 32 bit only. They've both been available in 64 bit versions on Linux for years.
Because there is basically no good reason to use a 64bit version of an Office application - unless you really need to work with a spreadsheet or text document that approaches 4GB in size (shudder)...
Even Microsoft recommends installing the 32bit version of Office on 64bit machines.
The 4GB limit causes problems with databases moreso than a text document or spreadsheet.
Personally I can't see using LibO for managing/working with databases that big...
Hi Tanstaafl
Agreed for the current case of LO, but I have also found other issues with now emerging 64 bit apps that rely on 64bit Java, hence my suggestion. It was just to alleviate other issues going forward, even to the release we see of a 64bit LO one day.
Regards
Andrew Brown
I think the Java dev's are aware of this with systems needing two version of bitness in their add-ons or apps, hence the separate installations into two separate folders, as I explained earlier "two "Program Files" (64bit default app store) and "Program files (x86)" (32bit default app store)". Plus there are separate entries in the Windows registry for Java. To date I have never experienced any issues of Jave 32bit and 64bit side by side on my systems.
As an example, how many know that MS IE has two versions of bitness installed since Vista and Windows 7 and 8, and were the first Internet browser programmers to do this, or for that matter Windows Media Player 12. So I simply offer advice going forward as our O/S world is changing.
Even the 64bit distros (the first O/S to offer 64bit even before Windows XP 64bit and Windows Vista) of Linux are seamlessly working with 32bit and 64bit apps, and the general populous of Linux users are not aware of what bitness an app is, as long as it works. The world does not even remember our transition from 8bit to 16bit in our hardware and software, and it's happening the same now.
Regards
Andrew Brown
Hi James
Umm!!! factually no, LO is still 32bit on Linux, it just works as seamlessly as I explained in my previous email / post, on a Linux 64bit system, as it does on a Windows 64bit system. I code in my spare time, and I can tell you to change from 32bits of coding to 64bits of coding is a monumental uphill learning curve.
In the simplest terms imagine managing 32 horses of a high spirit, and you just get it right, now add another like 32, and you can see just the tip of the iceberg what is involved in offering apps in 64bit mode.
Regards
Andrew Brown
Andrew Brown wrote:
Umm!!! factually no, LO is still 32bit on Linux
Then why is there an x86_64 version, when the 32 bit version should also work well?
Agreed, just look at what happens to Outlook, or Thunderbird when the email store starts approaching 4GB on a 32bit system. This was an ongoing support issue in my days of corporate IT support, in trying to get users to purge their old emails and garbage and backup that which they wanted and create a new store.
The human race (those that have access to IT technology) has become hoarders of digital garbage in the most part of instances.
Regards
Andrew Brown
This is a structure from the devs in a file naming convention, indicating its a 32bit app (x86_), that can be installed on a 64bit operating system (_64), not necessarily a 64bit app. And in the case of LO, it's definitely not yet a 64bit app. They still have to code 32bit apps to be functional on 64bit O/S's, unlike a naitve 32bit app for a 32bit O/S.
Hope this explains it better.
Regards
Andrew Brown
Not really:
/opt/libreoffice4.0/program/soffice.bin: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, not stripped
HTH.
MR
Ah!, but we have to have everything!!!! digital wroking in 64bit before the year 2036 and 2038.
As we of us that went through and were involved in the raw IT support of the Y2K issue will know, which is a pimple on the back of a blue whale, compared to the coming ultimate Y2K. From 2036 onwards (non-Unix/Linux will be affected from 2036 and Unix/Linux from 2038), this is a finite and and absolute wall dominated by the laws of the universe in science and math, and cannot be fixed at all, unlike the original Y2K date issue. Bottom line is ALL IT type of hardware and software, down to calculators, mobile phones, tablets PC, aircraft computer, whatever we use a computer to control and mange, has to be changed to 64bit in it's entirety.
So LO and other like Office suites all will have to move to 64bit. We live in a universe bigger than man's current state, and we expose it incredibly in the digital world of ours today.
To help those understand what's coming and not letting me fill up an email, here are some links of good reading explaining this. There is plenty more about this out there.
http://en.wikipedia.org/wiki/Year_2038_problem
Regards
Andrew Brown
Fine, but that only explains the executable as a 64bit under Linux Standard Base (LSB part in the given reference for those wishing to understand, meaning a standard function through all 'nixes). It's still not the entire LO code base that is 64bit.
Regards
Andrew Brown
Technically, the x86 indicates the architecture, the 64 indicates the
instruction set width. So x86_64 is a 64 bit chip, and the x86_32 is a
32 bit chip. Obviously, when apps (like LO) are marked as x86_64, they
mean that it is intended for a 64 bit OS running on a 64 bit chip, as
opposed to a 32 bit OS running on a 32 bit (if any still exist that are
modern enough to be supported) or 64 bit chip. It does (should) not
indicate a 32 bit app capable of running on a 64 bit OS, simple an app
(32 or 64 bit) capable of running on a 64 bit OS. It would, infact,
_suggest_ a 64 bit app, or at least that *something* had been done to
differentiate it from the 32 bit version, otherwise why the distinction.
https://en.wikipedia.org/wiki/X86
Just, you know, FYI.... er... sorry... to bother anyone...
Paul
Good point.
However, if I run find on the LO "program" directory, filter all the
files through 'file' and grep out everything with "64" in it, all that
remains is ASCII, shell scripts, data files and a few PE32 (and PE32+)
python executables that happen to be Windows .exe files that don't run
on Linux.
I have not seen any of the problems mentioned in this thread, but I
have not upgraded to 4.1 yet (waiting for 4.1.1).
YMMV.
MR
Not quite.
this is a finite and and absolute wall dominated by the laws of the
universe in science and math, and cannot be fixed at all, unlike the
original Y2K date issue
Well... not really. See, the original issue was that years were only
stored as two digits, instead of the complete four. Those two digits
were added to 1900 to get the year. So after 1999, the two digits
didn't hold enough information to continue counting, and "wrapped
around". With this it's the same thing. A 32 bit number is used to hold
a number of seconds, and this number is added to a base
"epoch" (00:00:00 UTC on Thursday, 1 January 1970). After 03:14:07 UTC
on Tuesday, 19 January 2038, a 32 bit number won't be able to hold
enough information to continue counting.
Bottom line is ALL IT type of hardware and software, down to
calculators...
Well, practically, probably about right. Theoretically some systems
either won't care about the date (like, well, calculators), or will use
alternate methods of storing a date (many software systems use a
date string, such as the ISO 8601 standard). But yes, lots of stuff
*will* be affected.
has to be changed to 64bit in it's entirety
Again, in practice, probably right. This is not the only solution,
there are others, such as date strings (which could be a solution for
many software systems), but for most systems (and especially hardware
systems) the only really practical solution is moving to 64-bit.
Sorry to bother, I'm sure you all already knew this, and Andrew was
just simplifying.
Paul