Same problem in 3.4.2 rc2, both in Windows7 and Linux

Is It Java 1.7.0, 32 or 64 bits?
With Java 64 bit LibreOffice or Ooo don't work.

(In reply to comment #2)
> Is It Java 1.7.0, 32 or 64 bits?
> With Java 64 bit LibreOffice or Ooo don't work.

@mariosv
My test was with a 32 bit system, but the issue seems to be the way LO/OOo detects Java, so it's likely to affect all versions on any Win or Linux box, possibly Mac also, but we don't have a report from that platform yet.

Better not install java7, they have some more bugs to sort out.
http://www.infoworld.com/t/java-programming/apache-and-oracle-warn-serious-java-7-compiler-bugs-168516
Oracle and Apache, not a good team.....

Some problem on Windows 7 SP1 Home Premium 64bit with LibreOffice 3.4.2 final. I have installed Java 7 32bit and 64bit. Now I'm back at Java 6 update 26 and libreoffice found JRE.

Problem reproduced with Java 7 (32bit) on Windows 7 (64bit) Ultimate.
LibreOffice 3.4.2 applications crash while opening.

corrrection: Windows 7 SP1+patches (64bit) Ultimate

*** Bug 39810 has been marked as a duplicate of this bug. ***

*** Bug 39885 has been marked as a duplicate of this bug. ***

On  java.com you can read:

'The new release of Java is first made available to the developers to ensure no major problems are found before we make it available on the java.com website for end users to download the latest version.'

The official release is still 1.6.26

Hi :)
The 1.6.0_21 seems to be the best java to use with LibreOffice.  The 1.6.0_20 & 1.6.0_22 seem to be in a fairly good 2nd place place.  The 1.6.0_24 was really bad and the 1.6.0_26 was even worse apparently.  So, i guess you need one version for your web-browsers and a different one for LibreOffice.

I thought LibreOffice devs were trying to get rid of any dependence on java anyway.  Perhaps moving to python instead?  I think it's mostly only Base that needs java now isn't it?
Regards from
Tom :)

I had Java 7 installed on my machine, and it worked fine for some weeks now. Yes, I DO use BASE regularly ;-) Now I wondered, that on install of 3.4.3 RC2 Java 7 wasn't recognized anymore. Then I remembered, that I might have installed Java 7 after Libo 3.4.2. So, what I want to say is, that Java 7 works fine for me in LibO, when its recognized somehow ;-)

I agree that there might remain some serious bugs in Java 7, nevertheless I hope that LibO will recognize v7 very soon. This will make life much easier for early-adopters, that doesn't have much experience on the other hand.

(In reply to comment #12)
> So, what I want to say is, that Java 7 works
> fine for me in LibO, when its recognized somehow ;-)

Are you sure? Unless you have uninstalled all previous Java versions, it's probably one of those that is being used. Check which version of Java is in use at:
Tools > Options > Java
If you can't see Java 7 in the list, it's not being recognised. If you can, then please identify the LO in use and your platform.

(In reply to comment #13)
> Are you sure? Unless you have uninstalled all previous Java versions, it's
> probably one of those that is being used. Check which version of Java is in use
> at:

Yes, I am sure about this. I didn't had any v6 Versions installed with 3.4.2.

Now I have recreated the Situation. I had 6.0.26 installed, so that LibO 3.4.3 was able to detect the path Java 32Bit is installed to. I then closed LibO and uninstalled the v6 version. Then I copied the v7 version to the path that v6 used before. And voila, LibO works with Java 7. I was able to use Base, Duden Korrektor and Languagtool. To be sure it really uses THIS version of Java, I changed the foldername of the previous v6 (now v7) installation, and then LanguageTool crashes LibO (as it cant use Java anymore). So, in my opinion, this test demonstrates, that LibO really uses the Java 7 in the former Java 6 Directory.

As for the Options Dialog: NO, there is no Java Installation displayed. Nevertheless, in some config-file the path is still stored, and its still working.

(In reply to comment #13)
> If you can't see Java 7 in the list, it's not being recognised. If you can,
> then please identify the LO in use and your platform.

Ohh, forgotten something ;-)
I'm using LibO 3.4.3 RC2 now, on Windows 7 x64, with Java 7 32Bit installed.

(In reply to comment #14)
> (In reply to comment #13)
> > Are you sure? Unless you have uninstalled all previous Java versions, it's
> > probably one of those that is being used. Check which version of Java is in use
> > at:
> 
> I then closed LibO and
> uninstalled the v6 version. Then I copied the v7 version to the path that v6
> used before. And voila, LibO works with Java 7. 
OK, thanks, that's good information and a possible work-around. It also implies that the problem will probably be easy to fix.

Your method of deploying Java isn't the standard one. If you install 1.7.0 and uninstall 1.6.xx, as most are likely to do, LO doesn't find the new version.

(In reply to comment #16)
> Your method of deploying Java isn't the standard one. If you install 1.7.0 and
> uninstall 1.6.xx, as most are likely to do, LO doesn't find the new version.

Well, normally I don't just copy the binaries of course, this was just for the test ;-)

But I always use my own custom paths for installations, so yes, normal users (with their standard-installations) will not see Java 7 working for them.

All I wanted to show off is, that the problem is only the recognition of Java 7, not Java 7 itself.

Hello @ll,
I can confirm this problem with
LibreOffice 3.4.3 OOO340m1 (Build:302)
under Debian Testing AMD64 ... :( Is there any possibility to get it fixed, without that workaround from comment #14?
HTH
Thomas.

I confirm this bug for LibreOffice 3.4.3 and Windows XP SP3 x86.

> I agree that there might remain some serious bugs in Java 7, nevertheless I
> hope that LibO will recognize v7 very soon. This will make life much easier for
> early-adopters, that doesn't have much experience on the other hand.

Don't forget to update to JRE 7u1.

I can confirm this bug in linux x64 with the JRE 7u1 and LibO 3.4.4 RC1

@Germán Ríos
Why you changed platform and version? I don't understand this behavior...

It looks like the bug STILL exists in LO3.4.4; it is very hard for me to understand why this is not fixed.

I have uninstalled LO today and installed Microsoft Office 2010; it works fine with Java 1.7 - in fact it works fine even without JRE.

Same problem here; LO 3.4.4 won't recognize the 7u2b11 jre. Considering that bugzilla2@cb-computerservice.at was able to get LO working with Java 7 by copying the jre7 into the usual jre6 location, I thought I might be able to get LO to use jre7 by putzing around with the javasettings_$PLATFORM.xml file in the profile config directory. No such luck; it still wouldn't use the jre.

The much-hyped bugs in the original Java 7 release (which mattered a lot to Lucene and Solr but don't affect most people and were avoidable via a command-line switch) were already fixed in 7u1 on Oct 19. The only other fixes in 7u1 were security fixes; 7u2 has a lot more fixes and improvements, and I've been using the 7u2 prereleases for two months now without any issues.

When 7u2 goes final (within a couple weeks) you'll start to see a lot of people switching away from Java 6. Oracle may even start offering 7u2 as the default java download. Since this bug isn't a real incompatibility but just an inability to recognize java 7 properly, I think it's pretty unfortunate that it doesn't look like it'll be fixed before you start getting tons of users running into the bug rather than just a few early adopters.

@Daniel Jensen
Yes, I agree entirely with your sentiments. I have raised the importance to high, but given that the bug was already in the 'most annoying' list I'm not sure that will make any difference. When Oracle make 1.7.x into the default it would immediately become a blocker and it might then cause so much irritation that a new LO version would have to be rushed out. IMHO it ought to have been fixed in 3.4.4.

.

I have had the unfortunate experience of not being able to run LO 3.4.4 without re-installing Java version 6 on my machine.

I was nosing about in C:\Users\<user>\AppData\Roaming\LibreOffice\3\user\config when I saw this file.. javasettings_Windows_x86.xml it is a pregenerated file that hard wires LO to look for Java6

Copy from file lines 10 & 11....
<location>file:///C:/Program%20Files%20(x86)/Java/jre6</location>
<version>1.6.0_23</version>

It appears to me that LO is hardwired to look for J6.... can or should this be changed, so LO is looking for any version of Java, not just a particular version?

Am I wrong in assuming this?

Please stop playing with the Platform/OS and version fields all the time. This bug is reproducible on all platforms, so All/All is definitely the right values for Platform/OS. Also, this bug has been reported against 3.4.1. It's obviously not fixed in 3.4.4 or any other new releases, else this bug would be marked RESOLVED FIXED, so there is no need to touch this field at all either.

Can confirm.  Continuing inability of LibreOffice 3.4.4 (build 402) to detect presence of JRE when only Java 1.7u01 32-bit is present on Windows 7 sp1 64-bit.

On a working installation of LibreOffce 3.4.4, removal of JRE 1.6uXX, deletion of javaSettings_Windows_x86.xml configuration, and installation of JRE 1.7u01

Creation of javaSettings_Windows_x86.xml (and presumably javaSettings_Linux_x86.xml) is NOT being populated with Java instance details for JRE 1.7u01

In Windows, the %APPDATA%\Roaming\LibreOffice\3\user\config\javaSettings_Windows_x86.xml is created when a Tools > LibreOffice > Java check box is made to "Use a Java Runtime Environment".

However, it contains an empyt template:

<?xml version="1.0" encoding="UTF-8"?>
<!--This is a generated file. Do not alter this file!-->
<java xmlns="http://openoffice.org/2004/java/framework/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<enabled xsi:nil="true"></enabled>
<userClassPath xsi:nil="true"></userClassPath>
<vmParameters xsi:nil="true"></vmParameters>
<jreLocations xsi:nil="true"></jreLocations>
<javaInfo xsi:nil="true"></javaInfo>
</java>

Using the Add... button of the Java Options GUI and manually selecting the java\jre7\bin installation directory returns error:

LibreOffice 3.4--The folder you selected does not contain a Java runtime environment. Please select a different folder.

Yet if JRE 1.6uXX is present, when Java Options GUI is open and the  a fully populated javaSettings_Windows_x86.xml is created as soon as the check box to use a Java JRE is made.  Here is an example of the generated XML:

<?xml version="1.0" encoding="UTF-8"?>
<!--This is a generated file. Do not alter this file!-->
<java xmlns="http://openoffice.org/2004/java/framework/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<enabled xsi:nil="true"/>
<userClassPath xsi:nil="true"/>
<vmParameters xsi:nil="true"/>
<jreLocations xsi:nil="true"/>
<javaInfo xsi:nil="false" vendorUpdate="2004-01-30" autoSelect="true">
<vendor>Sun Microsystems Inc.</vendor>
<location>file:///C:/Program%20Files%20(x86)/Java/jre6</location>
<version>1.6.0_29</version>
<features>0</features>
<requirements>0</requirements>
<vendorData>660069006C0065003A002F002F002F0043003A002F00500072006F006700720061006D00250032003000460069006C0065007300250032003000280078003800360029002F004A006100760061002F006A007200650036002F00620069006E002F0063006C00690065006E0074002F006A0076006D002E0064006C006C00</vendorData>
</javaInfo>
</java>

This was with a working LibreOffice 3.4.4 installation made with a 1.6u29 JRE that had been updated. Others on user forum have reported inability to install when JRE 1.7u01 present.

*** Bug 42754 has been marked as a duplicate of this bug. ***

Can someone double check this. UNO Runtime Environment URE/jvmfwk looks to have Java vendor dependencies for each OS distribution.

The appropriate javavendors_[freebsd|linux|macosx|os2|unx|wnt].xml template gets copied from libreoffice-ureRELEASE/jvmfwk javavendors.xml for build.

String match against list of JRE vendorInfos and release level performed in URE/core/jvmfwk/source/fwkbase.cxx

So question?  Was vendor info for JRE 7 changed from "Sun Micrsystems Inc."? Is fix as simple as adding new <vendorInfos> stanzas for "Oracle America, Inc." or "Oracle Corporation"

OpenGrok review shows "Oracle Corporation" and version 1.7.0 in the javavendors_linux.xml; but it is missing in all the other distributions/OpenOfficeorg, including the javaendors_wnt.xml for Windows.

Unable to build and test--could someone have a go.

Thanks.

vsf

I am raising the priority to blocker for 3.5 because it is probable that Oracle will make V7 the default Java version before 3.5 is released. When that happens, a large number of users will quickly run into problems, causing the most extreme irritation and a lot of bad publicity. In fact, one might predict that if V7 is made the default before 3.5 is released, TDF might well have to quickly release a 3.4.5 version with this bug fixed.

There is two things to take care of:

First, LO needs to be able to detect a given JRE.  That is mostly just about adding some string stuff in the jvmfwk module.  <http://cgit.freedesktop.org/libreoffice/core/commit/?id=549e54fb2f8113502743c443d6deadfe648dede1> "add Oracle Java 1.7.0 recognition" made the necessary additions---but for Linux only---on the master branch towards LO 3.5

Second, it needs to be verified that LO indeed works fine with the given JRE.  (And given the above commit, my assumption would be that Oracle's Java 7 on Linux indeed works fine with LO.)

This leaves adapting the JRE detection and verifying that it works open for other platforms, and potentially open for LO 3.4.5.

The most relevant platform here will likely be Windows.  Somebody working on Windows would need to adapt jvmfwk/distributions/OpenOfficeorg/javavendors_wnt.xml accordingly and verify that the result is good.

There appears to be no official Java 7 for Mac OS X yet.  I do not know for any other remaining platforms.

Whether to backport this to LO 3.4.5 is another question.  Anybody seeing any demand?

I would think you could just copy the stuff from the Linux file to the Windows file.

It would be good to backport to the latest stable version of LibO, because any user who downloads the latest LibO is likely to also download the latest JRE.

It seems like altering the xml-file doesn't do it alone.
I changed the javavendors.xml of my LibO 3.4.4 Installation to this:

~~~~~~
<?xml version="1.0" encoding="UTF-8"?>

<javaSelection xmlns="http://openoffice.org/2004/java/framework/1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 
 <updated>2011-11-24</updated>
 
 <vendorInfos> 
  <vendor name="Sun Microsystems Inc.">
    <minVersion>1.5.0</minVersion>
  </vendor>
  <vendor name="Oracle Corporation">
    <minVersion>1.7.0</minVersion>
  </vendor>
  <vendor name="IBM Corporation">
    <minVersion>1.5.0</minVersion>
  </vendor>
 </vendorInfos>

 <plugins>
  <library vendor="Sun Microsystems Inc.">vnd.sun.star.expand:$URE_INTERNAL_LIB_DIR/sunjavaplugin.dll</library>
  <library vendor="Oracle Corporation">vnd.sun.star.expand:$URE_INTERNAL_LIB_DIR/sunjavaplugin.dll</library>
  <library vendor="IBM Corporation">vnd.sun.star.expand:$URE_INTERNAL_LIB_DIR/sunjavaplugin.dll</library>
 </plugins>
</javaSelection>
~~~~~~

Of course quickstart was off while doing so. After a restart of LibO, it still wasn't able to detect Java 1.7.1. The patch linked from Stephan Bergmann includes more code changes then only in the "javavendors_%OS%.xml", so I guess all the changes are necessary, to have LibO detect Java 7.

Ohh, forgotten something.

Stephan asked, if it makes sense to roll this in 3.4.5. I would say definitely! I think its better to have this out while only early adopters have Java 7, instead of bring this later, when Oracle decides to make Java 7 the default Java Version.

Even though there are quiet some followers of this bug now, it are still too little, to check for any possible regression, that Java 7 could bring.

So, even if it seems to not make sense for a "stable" Version, I would start with Java 7 Support as soon as possible.

<http://cgit.freedesktop.org/libreoffice/core/commit/?id=f95052c29b076995a54b1d3f7c0becf35ebcd23f> should let current LO Windows builds (towards LO 3.5) detect Oracle's Java 7, too.

It is unclear how well LO works with that Java 7, so I'll ask QA to give this a thorough test on Windows and Linux.

At <http://lists.freedesktop.org/archives/libreoffice/2011-November/021284.html> we decided to wait with a backport to LO 3.4.5 until after QA has looked at it for LO 3.5 (although that item appears to be missing from the minutes).

(In reply to comment #37)
> <http://cgit.freedesktop.org/libreoffice/core/commit/?id=f95052c29b076995a54b1d3f7c0becf35ebcd23f>
> should let current LO Windows builds (towards LO 3.5) detect Oracle's Java 7,
> too.

As I wrote before, changing only the "javavendors_wnt.xml" ("javavendors.xml" when installed) does NOT make LibO detect Java 7. See my comment #35.

re Comment 38: but the other necessary changes are already in (on master towards LO 3.5)

Sorry, I didn't send the comment on status change.

In http://www.java.com/en/download/faq/java7.xml

"
Why is Java SE 7 not yet available on java.com?

The new release of Java is first made available to the developers to ensure no major problems are found before we make it available on the java.com website for end users to download the latest version. If you are interested in trying Java SE 7 it can be downloaded from Oracle.com
"

Also http://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Definition

Why then can be a blocker and critical?

You can have several version of Java in your system, and select in LibreOffice the best (but not any Java 64 bits), as is mentioned in some places the best version of Java for Libo is the 1.6.21.

(In reply to comment #39)
> re Comment 38: but the other necessary changes are already in (on master
> towards LO 3.5)

OK, I already thought that could be that way, but it wasn't really clear. Now we know, that your patch, PLUS the one you linked earlier in conjunction will (hopefully) bring recognition of Java 7.

(In repply to Comment 37 https://bugs.freedesktop.org/show_bug.cgi?id=39659#c37 )

Java JRE performance with OO/LO Base has been degraded since the 1.6u22 release (Bug 35023). JRE 1.6u21 remains the most functional JRE for use of Base native HSQLDB 1.8

Unclear if the HSQLDB 2.x version can ever be incorporated, and LO Dev interest seems to be to move LO to SQLite. In truth though, neither an SQLite adoption (Bug 38811) nor an upstream move to HSQLDB2.x is likely to happen in time for LO 3.5 so we will retain performance issues with HSQLDB 1.8 and any JRE in use.

No reason to expect improvements in Base native HSQLDB 1.8 performance with JRE 7. So the QA question should be otherwise focused on LO installation and UNO/URE user interface stability.  And support for JRE 7 should probably be backported for a LO 3.4.5 release.

vsf

I have just downloaded and installed LibO 3.5.0 Beta 2.

I can confirm that this beta release correctly identifies and uses Java 7 RTE.

Created attachment 54778 [details]
LibO 3.5.0 Beta2 using Java 7 RTE

LibreOffice 3.5.0 Beta 2 correctly identifies the installed Java 7 RTE.

*** Bug 40297 has been marked as a duplicate of this bug. ***

IIRC Stephan committed this to libreoffice-3-4 for 3.4.5 - so marking fixed again :-)

Windows 7 Professional SP1 64bit
LibreOffice 3.4.4
Java JRE 7u2 x86 and x86-64 both installed

After discovering that LibreOffice 3.4.4 didn't like JRE 7u2 and learning about this bug report, I downloaded and upgraded to 3.4.5.  When I opened 3.4.5, it did the same thing 3.4.4 did and displayed several identical error messages about Java before finishing to load.  The error message was:   

Title bar "JRE is Defective".  Body "LibreOffice requires a Java runtime environment (JRE) to perform this task. The selected JRE is defective. Please select another version or install a new JRE and select it under Tools - Options - LibreOffice - Java."

This is slightly different wording than in 3.4.4, but is roughly equivalent.

I clicked through all the error messages and navigated to the Java settings, which were empty.  However, LibreOffice displayed the installed JRE after a few seconds.  After closing the dialog and reopening, LibreOffice didn't give me any more errors.

This appears to be resolved, but a non-geek might choke on this scenario and rush out to Staples to pick up M$ Office.

Sorry for having changed this folks! I need to RTFbugzillaM, apparently!

Sean

From http://ask.libreoffice.org/en/question/5857/libreoffice-361-base-java-7/
"32-bit applications, such as LibreOffice, Internet Explorer 32-bit, and Firefox, CANNOT use the 64-bit version of Java JRE."

Makes sense, right? So, it's okay to use jre7, but if you need jre for LibO, you'll have to install the 32-bit (a.k.a. i586) version. (You can install other versions too though.) That's my experience.

@Kumāra,

(In reply to comment #49)

> Makes sense, right? So, it's okay to use jre7, but if you need jre for LibO,
> you'll have to install the 32-bit (a.k.a. i586) version. (You can install
> other versions too though.) That's my experience.

Guidance in Ask LibreOffice is complete, LibreOffice on Windows still requires a 32-bit JRE.

However, this BZ issue was Resolved Fixed 20 months ago--2012-01-04; absolutely no reason to comment here. Bugzilla is an issue tracking and reporting channel for development and QA, not general comment.  Please respect that and avoid spurious postings.